Некоторое время я это заметил на некоторых моих кодах:
/** * 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 */ Я не помню, откуда я его получил ( возможный источник ), но это не должно иметь отношения к этому вопросу. В принципе, всякий раз, когда я пытаюсь отправить электронное письмо с помощью BCC через SMTP, адреса BCC не скрыты. Я прочитал весь RFC для протокола SMTP (пару лет назад), и я не думаю, что у меня что-то не хватает.
Странно то, что если я отправлю электронное письмо с BCC с помощью встроенной функции mail() все будет работать правильно, и я не знаю, почему, – я бы хотел отправить своего собственного отправителя электронной почты, но я не понимаю этого.
Может кто-то пролить свет на этот темный предмет?
Адреса BCC не удаляются на целевом сервере электронной почты. Это не так, как это работает.
RCPT TO на SMTP-сервер, по одному для каждого адреса электронной почты получателя, и эта команда не различает, является ли приемник обычным приемником типа To, CC или BCC. DATA , в которой будет содержаться содержимое электронной почты, состоящее из заголовков электронной почты и тело – тот, который получен почтовыми клиентами. Среди этих заголовков электронной почты обычно – адрес, адрес, адрес CC. DATA , а не потому, что целевой SMTP-сервер удалил их. Целевой SMTP-сервер будет просто ссылаться на RCPT TO для списка адресов электронной почты, которые должны получать содержимое электронной почты. На самом деле неважно, находится ли приемник в списке To, CC или BCC. RCPT TO , но заголовок BCC не следует печатать в команде DATA . Цитируя часть RFC, которая, по моему мнению, имеет отношение к вашему делу:
Обратите внимание, что почтовые данные включают элементы заголовка заметки, такие как Date, Subject, To, Cc, From [2].
Пару лет назад, я искренне думаю, довольно долго назад, чтобы предположить, что вы все еще запоминаете конец до конца RFC 821 . 🙂
Очень поздно, но принятый ответ по сути ошибочен.
Во-первых, SMTP не имеет ничего общего с BCC . SMTP в качестве протокола касается только пути возврата (запрос MAIL ), списка получателей (запрос RCPT ) и данных, которые необходимо передать (запрос DATA ). Если вы хотите отправить электронное письмо кому-либо через SMTP, вы должны указать свой адрес в запросе RCPT , периоде.
Содержимое электронной почты – DATA , эффективно – указано полностью отдельно, в RFC2822 . В том, как BCC следует обрабатывать, существует большая широта. Спецификация дает три способа обработки BCC , и только в одном из них BCC удаляется при подготовке электронной почты. Если я использую Thunderbird в качестве почтового клиента, например, и укажу его на SMTP-сервер, а затем посмотрю на сообщение в строке, то обнаруживаю, что BCC Thunderbird ушел (из SMTP DATA ) и SMTP-соединения вместо этого содержит стандартный запрос RCPT для адресного адреса Оконечного устройства. Итак, Thunderbird преобразует BCC в RCPT , но это не единственный способ сделать это.
Другое место для обработки BCC – в MTA – другими словами, на любом SMTP-сервере, на который указывает ваш почтовый клиент. Sendmail, например, ищет все строки To , Cc и Bcc в SMTP DATA , а затем строит список адресов из этих строк, а затем удаляет строку Bcc . Вы можете убедить Sendmail держать Bcc если хотите. Если sendmail не является назначенным MTA, он будет подключаться к другому MTA через SMTP и отправлять адреса получателей через RCPT . Другими словами, если sendmail является целевым MTA, и он получает Bcc , он будет лишать его, вопреки утверждению Amry.
В комментариях есть и путаница. Вы можете указать адреса RCPT для любого домена, а не только список адресов в одном домене. MTA должен искать записи MX для доменов назначения, чтобы определить, куда отправлять все. Заявления google.com и yahoo.com неверны.