Отправка электронной почты BCC с помощью SMTP-сервера?

Я это записал на некоторые из моих кодом:

/**
 * Add a BCC.
 *
 * Note that according to the conventions of the SMTP protocol all
 * addresses, including BCC addresses, are included in every email as it
 * is sent over the Internet. The BCC addresses are stripped off blind
 * copy email only at the destination email server.
 *
 * @param string $email
 * @param string $name
 * @return object Email
 */

Я не помню, откуда я его взял (источник), но это не должно иметь отношение к этому вопросу. В принципе, всякий раз, когда я пытаюсь отправить электронное письмо с BCCs через SMTP, адреса BCC не скрыты - я прочитал весь RFC для протокола SMTP (пару лет назад), и я не думаю, что я что-то пропустил.

странная вещь, если я отправлю электронное письмо с BCCs, используя встроенный mail() функции все работает правильно, и я понятия не имею, почему - я хотел бы свернуть свой собственный отправитель электронной почты, но я не понимаю этого.

может кто-нибудь, пожалуйста, пролить свет на этот темный предмет?

2 ответов


адреса BCC не удаляются на целевом почтовом сервере. Это не так работает.

как SMTP на самом деле работает

  • отправитель отправит список RCPT TO команды для SMTP-сервера, по одному для каждого адреса электронной почты получателя, и эта команда не различает, является ли получатель нормальным получателем типа To, CC или BCC.
  • достаточно скоро после вызова команды, которая сообщает SMTP-серверу, кто отправитель, кто сервер, и все остальное, только тогда отправитель будет назвать DATA команда, в которой будет содержаться содержимое электронной почты, состоящее из заголовков и тела электронной почты, полученных почтовыми клиентами. Среди этих заголовков электронной почты обычные от адреса, к адресу, CC-адрес.
  • адрес BCC не отображается получателю, просто потому, что он не распечатан под DATA команда, а не потому, что конечный SMTP-сервер лишил их. Этот конечный SMTP-сервер будет просто ссылаться на RCPT TO для списка адресов электронной почты, которые должны получать содержимое электронной почты. На самом деле ему все равно, находится ли получатель в списке To, CC или BCC.
    обновить (уточнить): адреса электронной почты BCC должны быть указаны в RCPT TO список команд, но заголовок BCC должен не быть напечатанным под

очень поздно, но принятый ответ по существу неверен.

во-первых, SMTP не имеет ничего общего с BCC. SMTP, как протокол, касается только обратного пути (MAIL запрос), список получателей (RCPT запрос), и данные, которые будут переданы (тег DATA запрос). Если вы хотите отправить кому-то электронное письмо через SMTP, вы должны указать свой адрес в RCPT запрос, срок.

содержание электронной почты -DATA, эффективно - указываются полностью отдельно, в RFC2822. Есть много широты в how BCC должны быть обработаны. Спецификация дает 3 способа обработки BCC, и только в одном из них есть BCC раздели во время подготовки электронной почты. Если я использую Thunderbird в качестве почтового клиента, например, и указать его на SMTP-сервер, а затем посмотреть на сообщение в строке, то я нахожу, что Thunderbird BCC ушел (из SMTP DATA) и SMTP-соединение вместо этого содержит стандарт RCPT запрос bcc'ed адрес. Итак, Thunderbird преобразует BCC до RCPT, но это не единственный способ сделать это.

другое место для ручки BCC находится в MTA-другими словами, на любой SMTP-сервер, на который указывает ваш почтовый клиент. Sendmail, например, ищет все To, Cc и Bcc строки в SMTP DATA, а затем создает список адресов из этих строк, а потом выводит в Bcc линии. Вы можете убедить Sendmail сохранить Bcc если вы хотите. Если sendmail не является конечным MTA, то он подключится к другому MTA через SMTP и отправит адреса получателей через RCPT. Другими словами, если sendmail is пункт назначения MTA, и он получает Bcc, это лишит его, вопреки утверждению Эмри.

в комментариях также есть некоторая путаница. Вы можете указать RCPT адреса к любому домену, не как раз список адреса в том же домене. MTA должен искать записи MX для доменов назначения, чтобы выяснить, куда отправлять все. В google.com и yahoo.com утверждения неверны.