На Windows Server 2003 и Windows XP диапазон по умолчанию эфемерных портов, используемых клиентскими приложениями, от 1 025 до 5 000. При определенных условиях возможно, что доступные порты в диапазоне по умолчанию будут исчерпаны.
netstat -n
или netstat -b
видеть активные соединения
Увеличьте верхний диапазон эфемерных портов, которые динамично выделяются клиенту сокетные соединения TCP/IP.
Примечание: Необходимо перезапустить компьютер для этого изменения для вступления в силу.
Примечание: Увеличение диапазона эфемерных портов, используемых для клиента соединения TCP/IP, использует память ядра Windows. Не увеличивайте верхний предел для этой установки на значение выше, чем требуется, чтобы размещать сокетные соединения клиентского приложения, чтобы минимизировать ненужное потребление памяти ядра Windows.
Ian,
Итак, сначала позвольте мне поделиться некоторой информацией о том, как Exchange обрабатывает BCC информацию, здесь есть хорошая статья: http://gsexdev.blogspot.com/2011/06/processing-bccs-in-exchange-transport.html
Вы также можете найти информацию, которая ссылается на то, как Exchange-процессы BCC здесь: https://superuser.com/questions/476620/finding-bcc-in-internet-mail-headers
Далее, я просто скопирую/вставьте ответ этого сотрудника РС, так как он достаточно хорошо объясняет это: http://social.technet.microsoft.com/Forums/exchange/en-US/faa6a8f4-7192-406f-bf7c-f41b52473e37/exchange-or-outlook-rule?forum=exchangesvrsecuremessaging
Поля поля , показанные в пользовательском интерфейсе клиента outlook, не имеют ничего общего с Доставка почты. Они есть для удобства пользователей. Когда у вас есть клиент outlook посылает сообщение, он составляет сводный список всех получатели, указанные в полях (To, Cc и Bcc) , которые отображаются в его пользовательский интерфейс. Используя этот список получателей, outlook, а затем выдает RCPT-TO. команду почтовому серверу для каждого получателя. Как только это будет сделано, outlook выпускает одну (всего одну) команду DATA, которая содержит ваше сообщение (заголовки, пустая разделительная линия и тело). Почтовый сервер не имеет понятия какой получатель был указан в каком поле и ему все равно. Это было сказано, кто является получателями по списку команд RCPT-TO. который он получил. Получатели никогда не смогут увидеть оригинальный список RCPT-TO команды, которые отправитель выдает своему почтовому серверу отправки.
Заголовки в сообщении (то, что отправляется во время команды DATA) следующие что бы там ни было. Электронные клиенты НЕ должны включать поле Bcc в их заголовочной секции в сообщении, но некоторое наследие клиенты так и сделали. Outlook должен вставлять только те заголовки To и Cc, которые соответствуют на значения, указанные в полях "К" и "Cc" в пользовательском интерфейсе. Начиная с Bcc поле никогда не было скопировано в заголовок Bcc в сообщении, есть в заголовках сообщений нет ничего, что указывало бы на то, кто был БКМ. реципиенты. А так как получатели никогда не смогут увидеть список RCPT-TO... команды, выдаваемые отправителем своему почтовому серверу, никак не могут чтобы получатель знал, кто получил Bcc'ed.
Даже для старых почтовых клиентов, которые раньше включали Bcc заголовок в сообщение, основанное на значении поля Bcc в их пользовательском интерфейсе (как, скажем, a вариант), многие почтовые хосты, принимающие почту, удаляют то, что Заголовок. Он не должен был передаваться, чтобы его сняли. если присутствует. Весь смысл поля Bcc НЕ в том, чтобы создать заголовок со списком получателей.
Так что давайте перейдем к сути дела. Exchange обрабатывает его иначе, чем то, к чему вы привыкли на вашем почтовом сервере Linux.
Что вы можете сделать, если Insightly не изменит их программирование?
Вот несколько идей, которые могут сработать:
1) Продолжайте с идеей BCC, но сделайте 2 прыжка. Под этим я подразумеваю создание ресурсных почтовых ящиков или подобных им в Exchange для почтовых адресов Insightly проектов. Затем создайте BCC эти адреса и заставьте эти почтовые ящики автоматически пересылать всю почту на "реальный" адрес электронной почты Insightly проекта. В этот момент Insightly должен рассматривать его как действительный адрес TO. Не уверен, что информация FW: будет обработана им, но стоит попробовать.
2) Рассмотрим вариант простого CCing the Insightly address (CCing the Insightly адрес). Я понимаю, почему вы хотите сделать BCC, но, может быть, это опция?
3) То же самое, что и #1 выше, но поместите адреса электронной почты на почтовый сервер Linux. Затем попросите этот сервер включить BCC Insightly после получения BCC от Exchange. Вам нужно будет использовать другой почтовый домен на сервере Linux, и пользователи Outlook будут отправлять BCC сообщения этому домену (например, Project1@insightly.internal). Затем Exchange-сервер доставит почту, предназначенную для внутреннего домена insightly.internal, на сервер Linux. Затем сервер Linux запускал бы BCC по адресу Project1@realdomain.com. Обидно и глупо, но это тоже должно работать.
Надеюсь, это немного поможет. Это непростая ситуация, и вы не можете просто исправить программное обеспечение CRM из-за этого, я полагаю
.Скрытая копия не должна добавлять поле Кому: в заголовки электронной почты. Если бы это было так, получатели сообщения могли бы видеть, кому было отправлено сообщение, в отличие от того, для чего предназначена скрытая копия. Вместо этого bcc добавляет к заголовку строку Bcc :, которая отключается конечным принимающим почтовым сервером. Заголовок «Кому:» никогда не удаляется и передается в почтовый ящик получателя.
Обычно вы добавляете один обычный Кому: от себя или какой-либо общедоступный адрес или адрес без ответа. Это адрес, который увидят получатели. Затем вы добавляете свои скрытые копии. Получатель их не видит.