Наше веб-приложение отправляет людям сообщения электронной почты, когда кто-то публикует новый контент. И отправитель, и получатель выбрали получение сообщений электронной почты из нашего приложения. При подготовке такого сообщения мы устанавливаем следующие заголовки SMTP:
FROM: author@example.com TO: recipient@example.com SENDER: webapp@mycompany.com
Мы решили использовать адрес электронной почты автора в заголовке FROM, чтобы обеспечить наилучшее взаимодействие с получателем; когда они видят сообщение в своем почтовом клиенте, автор ясен. Чтобы избежать появления спуфинга, мы добавили заголовок SENDER (с адресом электронной почты нашей компании), чтобы было ясно, что мы отправили сообщение от имени автора. После прочтения RFC 822 и 2822 кажется, что это предполагаемое использование заголовка отправителя.
Большинство принимающих почтовых серверов, кажется, справляются с этим хорошо; сообщение электронной почты доставляется в обычном режиме (при условии, что почтовый ящик получателя существует, квота не превышена и т. д.). Однако при отправке сообщения ОТ адреса в домене НА адрес в том же домене некоторые принимающие домены отклоняют сообщения с таким ответом:
571 incorrect IP - psmtp (in reply to RCPT TO command)
Я думаю, это означает, что принимающий сервер видел только то, что адрес заголовка FROM находился в его собственном домене, и что сообщение было отправлено с сервера, который он не считал авторизованным для отправки сообщений для этого домена. Другими словами, принимающий сервер проигнорировал заголовок SENDER.
У нас есть обходной путь: веб-приложение хранит список таких доменов, которые, похоже, игнорируют заголовок SENDER, а когда заголовки FROM и TO находятся в таком домене, вместо этого он устанавливает заголовок FROM на наш собственный адрес электронной почты. Но этот список требует уточнения.
Есть ли лучший способ достичь желаемого опыта? Мы хотим быть «хорошими гражданами» сети, и все вовлеченные стороны - отправители и получатели - хотят участвовать и получать эти сообщения. Один из альтернатив - всегда использовать адрес электронной почты нашей компании в заголовке FROM и добавлять имя / адрес автора к теме, но это кажется немного неуклюжим.
Вы смотрите не на то. Это сообщение заголовки. Вы должны смотреть на SMTP конверт. (То, как указывается конверт, зависит от того, как именно ваше приложение отправляет почту в почтовую систему. Во многих системах конверт указывается с помощью аргументов командной строки служебной программе отправки почты.) В зависимости от того, когда именно в транзакции протокола он решает выдать ответ 571, сервер ретрансляции SMTP, возможно, даже не видел заголовки сообщения.
В тексте ответа говорится, что администратор того конкретного сервера ретрансляции SMTP, с которым вы разговариваете, ограничил то, что вы можете помещать в конверт SMTP. Похоже, он жалуется на получатель конверта. Но он может откладывать проверку отправителя конверта до определения первого получателя, поэтому он может жаловаться на отправителя.
Обратите внимание, что отправитель конверта - это то место, куда отправляются сообщения о состоянии доставки, и вы не хотят, чтобы они были адресованы случайным людям по всему миру. (Помимо того факта, что многим это не нравится, сообщения о доставке для ваша почта быть возвращенным кому угодно, кроме вас.) Укажите себя в качестве отправителя конверта.
Это неправильно требовать MX ресурсные записи, кстати. Сервер ретрансляции SMTP можно найти по A и AAAA записи ресурсов при отсутствии каких-либо MX записи ресурсов. См. RFC 5321 § 5.1.
Возможно, я ошибаюсь, но наиболее вероятная причина вышеуказанной ошибки, особенно в случае Postini, заключается в том, что домены, в которых вам отказывают, имеют строгую политику SPF. Большинство почтовых серверов с проверкой SPF будут проверять только заголовок From :, им не важен заголовок Sender.
Чтобы проверить, так ли это, запустите команду «dig + short TXT domain.com», где domain.com выдает сообщение об ошибке. Вы должны получить что-то вроде:
"v = spf1 mx -all"
Важная часть - все. Это означает, что владелец домена заявил, что он будет отправлять электронную почту только с серверов, которые действуют как их почтовые серверы, вся остальная почта будет отклонена.
К счастью, если это так, вы можете активно проверить это перед отправкой электронного письма! Заставьте веб-приложение выполнять проверку SPF, когда пользователь вводит свой адрес электронной почты. Если существует строгая политика, добавьте домен в свой список. Нет недостатка в библиотеках для всех языков, которые могут выполнять проверки SPF.