Как отправлять чистые сообщения электронной почты из вашего приложения? - PullRequest
4 голосов
/ 20 сентября 2008

При разработке приложения, которое отправляет уведомления по электронной почте, каковы оптимальные методы для

  1. ваша хостинговая компания не помечает как спамер. (Покройте любой из :)
    • лучший способ не залить почтовый сервер
    • лучшие продукты почтового сервера, если вы настроите свой собственный
    • отправка сообщений, как будто от конкретного пользователя, но по-прежнему ясно из вашего приложения (для обеспечения возврата жалоб и т. Д.) Без нарушения хорошего этикета электронной почты
    • любые другие извлеченные уроки
  2. клиентом получателя не помечен как спам? (Покройте любой из :)
    • настройка и использование идентификатора отправителя, ключей домена, SPF, обратного днс и т. Д. Для обеспечения правильной идентификации ваших электронных писем
    • лучшие методы SMTP-заголовков, позволяющие избежать пометки в качестве спама при отправке электронных писем пользователям (например, совместное использование заголовков Sender и From)
    • любые другие извлеченные уроки

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

Ответы [ 3 ]

5 голосов
/ 22 сентября 2008

лучший способ не залить почтовый сервер

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

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

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

Вы можете сделать это, используя заголовок «Reply-To», в котором клиенты будут использовать этот адрес вместо адреса «От» при создании сообщения электронной почты.

Вы также должны установить заголовок «Return-Path» любого электронного письма, так как электронное письмо без этого часто отфильтровывается.

ех.

From: me@me.com
Return-Path: me@me.com
Reply-To: auto@myapp.com

настройка и использование идентификатора отправителя, ключей домена, SPF, обратного днс и т. Д., Чтобы убедиться, что ваши электронные письма правильно идентифицированы

все это в значительной степени зависит от того, насколько вы владеете своими почтовыми и DNS-серверами. spf / sender-id и т. д. - все это проблемы DNS, поэтому вам потребуется доступ к DNS.

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

Что касается обратного DNS и тому подобного, это действительно зависит. большинство интернет-провайдеров и т. д. просто проверят, установлен ли обратный DNS. (то есть 1.2.3.4 преобразуется в host.here.domain.com, даже если host.here.domain.com не преобразуется обратно в 1.2.3.4). это связано с количеством общего хостинга (где почтовые серверы часто сообщают о себе как доменное имя клиента, а не как реальный почтовый сервер).

Есть несколько строгих сетей, которые требуют сопоставления с обратным DNS, но для этого необходимо иметь контроль над почтовым сервером, если он не совпадает с самого начала.

если вы можете быть немного более конкретным, я могу дать немного больше советов, но, как правило, для людей, которым нужно отправлять почту приложения и у которых нет контроля над своей средой, я бы предложить следующее:

  • убедитесь, что установлен «Return-Path»
  • приятно добавить ваше приложение и информацию о нарушении также в заголовках, например: "X-Mailer" и "X-Abuse-To" (это пользовательские заголовки, только для информационных целей)
  • убедитесь, что для IP-адреса сервера исходящей почты установлен обратный DNS
0 голосов
/ 29 января 2009

теперь для других полезных битов

IP-адреса упомянуты ваши почтовые серверы

a ptr вашего ip указывает на имя, которое также разрешается на тот же ip FQDNs

b ваш сервер helo / ehlo с what.domain.com, где domain.com совпадает с доменом имени на шаге A {не то же самое имя для резонаторов ниже}

может иметь, что имя сервера helo / ehlo также разрешается по ip вашего сервера

d добавить следующую запись spf к этому имени helo / ehlo "v = spf1 a -all" {то есть разрешить helo / ehlo с этим именем из ip, на которое указывает только это имя}

e добавить следующие строки идентификатора отправителя в имя helo / ehlo {чисто для полноты "spf2.0 / mfrom, pra -all" {т.е. нет пользователей @ this-domain}

f добавить следующий spf к FQDNS-имени и любым другим именам хостов для вашего сервера "v = spf1 -all" {то есть никакие машины никогда не будут helo / ehlo в качестве этого имени и никакие пользователи @ this-domain}

{так как имя fqdns может быть определено ботами / заражениями, лучше никогда не разрешать использовать это имя непосредственно в приветствиях helo / ehlo, достаточно, чтобы оно было из того же домена, что и удостоверение личности helo / ehlo, чтобы доказать срок действия обоих}

0 голосов
/ 29 января 2009

первая быстрая коррекция к предыдущему

return-path: заголовок, добавленный системой приема на основе отправителя конверта входящего сообщения

для работы spf обратный путь / конверт-отправитель должен быть yourapp@yourdomain.com

и убедитесь, что spf-запись для yourdomain.com {или, если spf для пользователя spf} для yourapp@yourdomain.com, позволяет отправлять письма на сервер, на котором размещено приложение / отправляет электронное письмо

этот конверт-отправитель - это адрес, на который будут отправляться все ошибки / отказов

теперь идентификатор отправителя полностью отличается, он проверяет путь возврата / конверт-отправитель и from: address {хранится внутри сообщения} если отправка от: его имя yourapp@yourdomain.com ответ: его имя hisaddres@hisdomain.com

это будет не проблема если отправка от: его имя hisaddres@hisdomain.com

это будет, и вы должны добавить Resent-From: его имя yourapp@yourdomain.com поскольку это указывает на игнорирование запроса from: для проверки идентификатора отправителя используйте его вместо того, как оно было отправлено вами от его имени

...