У меня есть эта проблема в моем приложении для ретрансляции электронной почты через порт 587 нашего Exchange 2010: сообщение об ошибке было 4.4.2. Скорость отправки сообщений для этого клиента превысила настроенный предел.
Я понимаю, что это связано с MessageRateLimit моего разъема приемника. Я проверил, что лимит 5 и лимит пользователя (MessageRateSource), и я думаю, что проблема, вероятно, будет решена путем увеличения лимита до 50 или 100. Однако я хотел бы больше разобраться в этой конфигурации (как, если бы я сейчас установил его на 50 и завтра он столкнется с той же ошибкой?)
На основе Сайт MS, это регулировка, ограничивающая «максимальное количество сообщений в минуту, которое может быть отправлено одним источником». Поэтому я протестировал с использованием сценария PowerShell (не уверен, имеет ли это значение, поэтому я включил частичный код ниже):
$SMTPClient = New-Object System.Net.Mail.SmtpClient( $emailSmtpServer , $emailSmtpServerPort )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($emailSmtpUser , $emailSmtpPass );
#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
$SMTPClient.Send( $emailMessage )
В этом сценарии я сначала отправляю электронное письмо с другим идентификатором пользователя, и результат: я могу отправить электронное письмо одному и тому же получателю более 5 раз в течение минут. Так почему же в данном случае лимит не применяется?
После этого я попробовал скрипт со своим идентификатором приложения, выскочила та же ошибка (4.4.2). Затем я проверил проводник журнала отслеживания и обнаружил, что другого электронного письма с этим идентификатором приложения не было. Так это Exchange хранит количество пользователей где-то, где мне нужно его сбросить? И как я могу отследить отправку электронного письма? Кажется, это не отображается в проводнике журнала отслеживания, поэтому, как я раньше беспокоился, он может вызвать ту же ошибку, даже если я изменю ее на 50, я не могу устранять неполадки, не имея возможности их отслеживать.
Извините, вопрос слишком длинный.
Благодарю, если кто-нибудь может дать мне несколько подсказок.
Я собираюсь перевернуть этот вопрос с ног на голову. Когда ко мне приходит клиент с этой проблемой, я в первую очередь спрашиваю, почему сообщения передаются через Exchange? Exchange - очень плохая рассылка для массовых рассылок, и есть варианты получше. Почему приложение не отправляет электронное письмо само или через свой собственный сервер, а не через Exchange?
Если у вас есть приложение, отправляющее так много электронной почты внешним получателям, что оно выходит за пределы дросселирования, я бы не хотел, чтобы это было где-то рядом с Exchange. Попадание его в черный список - лишь вопрос времени. Собственный IP-адрес, собственный PTR и DNS и отправка электронной почты.
Я признаю, что это не тот ответ, который вы ищете, но если вы часто думаете о проблеме по-другому, это дает вам лучший способ ее решения.
Дросселирование при обмене довольно мощное средство, но его трудно отследить.
По моему опыту, установка ограничений на соединители довольно проблематична, так как у вас может быть только очень небольшая группа пользователей, которые отправляют большие объемы. Ограничение соединителей для нескольких пользователей подвергает повышенному риску злоупотребления со стороны взломанной учетной записи.
Политики регулирования
При работе с большими объемами вы должны определить максимальную скорость передачи сообщений и установить их для вашего коннектора приема. Это ваша Глобальный предел.
Затем вы должны сначала установить политику регулирования, которая уменьшает лимит до умеренного значения (например, 5 msg / min) как организационная политика.
Наконец, вы можете добавить дополнительные политики, которые увеличивают лимит отправки для определенных пользователей.
Это не раскрывает ограничения «массовой рассылки» для всех пользователей, которые могут получить доступ к данному соединителю, и обеспечивает более детальный контроль.
Вы можете получить более подробную информацию о политиках в документация.
Определение пределов
Хотя это хороший момент для диагностики, я бы не стал пытаться справиться с достижением ограничений на стороне сервера.
Вероятно, существует больше результатов, указывающих на неудачу, чем на успех при отправке почты. Достижение предела скорости - лишь одна из них. И ваше приложение должно обрабатывать их, а также сценарии, когда весь почтовый сервер может быть недоступен из-за некоторого простоя.
Поэтому я настоятельно рекомендую сосредоточиться на правильной обработке ошибок и механизме очередей в вашем приложении. Ознакомьтесь с способами получения диалоговых сообщений SMTP и их регистрации в случае сбоя. Это позволит быстро и легко диагностировать производственные процессы - не только в этом конкретном случае.
Как сказал @seembee, отправка больших объемов увеличивает риск попадания в черный список. Этот риск по-прежнему возникает при обходе обмена и использовании выделенных узлов массовой рассылки. Отправляя такие вещи, как информационные бюллетени, я полностью согласен. Но когда вы отправляете важные письма, такие как счета-фактуры, которые могут даже иметь юридические ограничения на почтовый поток, я бы не рекомендовал обходить инфраструктуру обмена.