Ограничения на количество получателей BCC - PullRequest
4 голосов
/ 16 марта 2009

У меня есть приложение, которое программно генерирует и отправляет электронные письма. Список получателей может превысить 1000. Я просматривал и рассылал отдельные электронные письма, но это занимало слишком много времени, примерно по 0,5 секунды. Подход, который я сейчас рассматриваю, состоит в том, чтобы удалить настройки в теле сообщения и отправить одно электронное письмо со всеми адресами в BCC. (Возможно, возможны другие решения, и я приветствую их, но в основном меня интересует сложность этого решения BCC.)

Существует ли ограничение на количество получателей, разрешенных для одного электронного письма? Это полностью зависит от конфигурации моего почтового клиента и / или SMTP-сервера? Существуют ли другие ограничения вне контроля моего домена? Кроме того, как обрабатывается BCC? Я предполагаю, что распределение BCC должно быть разбито на отдельные почтовые сообщения в какой-то момент. За это отвечает почтовый клиент (в моем случае javax.mail) или почтовый сервер делает это?

Меня также интересуют предложения о том, как я могу протестировать мою новую программу для работы с электронной почтой?

Я не думаю, что это будет действительный тест, если вы создадите 1000 аккаунтов в Google или где угодно (и не хочу). Я слышал, что есть некоторые оптимизации почтового сервера, ориентированные на нескольких получателей на одном хосте. В моем случае большинство из них будут разными хостами.

Другой способ - привлечь всех получателей, чтобы узнать, получили ли они электронное письмо. Я могу сделать это, но я хочу избежать спама, предполагая, что мне, возможно, придется тестировать несколько раз, если что-то не так с первого раза.

Или я просто предполагаю некоторое ограничение и отправляю пакеты писем с произвольным числом получателей, скажем, 50 или 100?

Ответы [ 3 ]

3 голосов
/ 16 марта 2009

BCC работает внутри вашего SMTP-сервера; ни один получатель не знает других адресов электронной почты BCC, так что это ограничение полностью зависит от вашего SMTP-сервера.

Вы должны уточнить у администратора сервера.

2 голосов
/ 18 августа 2009

, что еще более определенно, в RFC, охватывающем SMTP (2821), не упоминаются ограничения получателей, кроме определенных для почтового сервера:

"Если SMTP-сервер имеет ограничение на количество RCPT команды и этот предел исчерпан, он ДОЛЖЕН использовать код ответа 452 (но клиент ДОЛЖЕН также быть готов к 552, как отмечено выше). Если на сервере настроено ограничение политики сайта для число команд RCPT, МОЖЕТ вместо этого использовать код ответа 5XX. Это было бы наиболее целесообразно, если бы ограничение политики было предназначено применять, если общее количество получателей для конкретного тела сообщения были применены, даже если это тело сообщения было отправлено в нескольких письмах сделки ".

http://www.ietf.org/rfc/rfc2821.txt

1 голос
/ 17 марта 2009

Спасибо за ваши комментарии. Насколько я понимаю, исходящий SMTP-сервер будет отвечать за разбиение каждого сообщения. При создании новых сообщений исходящий SMTP-сервер будет отправлять только соответствующие команды RCPT TO для каждого получателя BCC. Таким образом, в случае, когда все получатели являются BCC, для каждого сообщения будет только одна команда RCPT TO.

В таком случае мне кажется, что мне действительно нужно беспокоиться о конфигурации нашего исходящего SMTP-сервера. Не нужно беспокоиться о целевых SMTP-серверах.

Я получил предложение, которое кажется хорошим способом проверить это. Я мог бы отправить свое сообщение нескольким получателям, каждый с уникальным поддельным дочерним доменом нашего действующего родительского домена. Если для ребенка не найдена запись MX, будет использоваться родитель. Исходящий SMTP-сервер не будет знать, что поддельные домены не существуют, поэтому следует избегать оптимизации SMTP для нескольких получателей с общими доменами. Вероятно, мы также можем настроить, чтобы все эти сообщения направлялись в один и тот же почтовый ящик.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...