Обработка неподтвержденных писем в webapp

У нас есть типичное деловое веб-приложение, которое позволяет нашим пользователям отправлять электронные письма с предложениями своим клиентам. Мы устанавливаем электронную почту пользователя в поле FROM, чтобы клиент мог напрямую ответить пользователю. Проблема в том, что из-за протокола SMTP на наш адрес электронной почты (адрес учетной записи, на которую мы отправляем электронные письма), возвращается недопустимое уведомление по электронной почте.

Знаете ли вы элегантный способ обработки этих неподтвержденных писем? Я имею в виду самый простой способ сообщить отправителю, что его почта не была доставлена.

Ответы

Ответ 1

Во-первых, важно понять разницу между заголовком "From:" (который видит получатель в своем почтовом клиенте) и адресом отправителя (который также называется обратным путем конверта или аргументом SMTP "MAIL" FROM "). Адрес отправителя - это то, где отправляются сообщения о отказе, когда сообщение не может быть доставлено, следовательно, путь возврата другого имени.

SMTP не ограничивает адрес, который вы используете в качестве адреса отправителя (за исключением того, что он должен быть синтаксически корректным), но любая используемая вами клиентская библиотека SMTP, поэтому вам нужно проверить это.

Изменение адреса отправителя - это то, где вы можете делать умные вещи, чтобы помочь обнаружить отскакивание электронной почты и сообщить об этом веб-серверу или отправителю. Наиболее распространенная вещь, которую вы увидите, - это кодирование адреса получателя в адресе отправителя, например. с адресом отправителя, подобным этому: [email protected] MTA, ответственный за senderdomain.com, должен знать, чтобы доставить все электронные письма для [email protected] на [email protected], но это довольно распространенное требование. Затем вы берете полученное электронное письмо и вместо того, чтобы пытаться работать с сообщением bounce в содержимом (которое может быть в любом формате), которое было у получателя, вы можете получить его правильно с адреса получателя.

Вы можете делать более сложные вещи, например, хешировать адрес получателя, чтобы он не отображался непосредственно в адресе отправителя, например. [email protected] И вы могли бы включить некоторый идентификатор отправленного письма, если вы отправляете несколько писем по одному адресу и хотите узнать, какой из них отскочил.

Эти трюки называются Variable Envelope Return Path или VERP и обычно реализуются программным обеспечением для рассылки.

Ответ 2

Есть 3 "заголовка", которые имеют электронные письма.

  • С.
    • Это то, что пользователь видит как "создатель"
  • Ответ к.
    • Здесь отправляется электронное письмо, если он задан.
  • Return-путь.
    • Здесь отправляется электронное письмо в случае, если адресат не существует.

Вероятно, вы хотите установить третий:)

(Обратите внимание, что некоторые серверы вообще не отвечают на эти потерянные сообщения, потому что недавно спамеры размещали там те адреса, которые не являются их собственными, делая атаку отскока третьей части, используя автоматическую систему ответов, чтобы превратить серверы электронной почты в открытое реле!)

Более подробную информацию см. в разделе 4.4 этого документа: http://www.faqs.org/rfcs/rfc822.html

Ответ 3

Какую именно рутину вы используете для отправки электронной почты? Мы отправляем электронные письма через raw SMTP с использованием HTTP put_lines, и ответы возвращаются к адресу, который мы назначаем в поле FROM:

Посмотрите, есть ли у вашей оболочки SMTP API поле Reply To:

Некоторые API-интерфейсы могут не предоставлять эту функциональность, поскольку это увеличивает возможность спама.