Современная процедура отправки писем с сайта.

Современная процедура отправки писем с сайта.

Все мы прекрасно знаем, что простой и понятный функционал, работающий без предъявления паспорта, жив ровно до тех пор, пока на нём не начнут массово паразитировать. Как только это случается в эпических масштабах, так сразу жди беды. Функционал будет прикрыт. Либо ограничен так, что пользоваться им станет сложно.

Владельцы сайтов уже в курсе, что ровно это самое как раз и происходит прямо сейчас. Разнообразные публичные почтовые сервисы (Гугла, Майла.ру и Яндекса как наиболее важные для нас) более-менее синхронно вдруг стали спускать в унитаз письма, отправленные не через SMTP, либо web-интерфейс их сайтов. Теперь это данность.

Что же произошло? Истоки проблемы.

Сайты обычно написаны на PHP (либо ином скриптовом языке), а в этих языках не очень-то и удобно слать письма через SMTP. Процесс медленный (иногда занимает секунд 10 на одно письмо со всеми межсерверными приветствиями и обменами заголовками), и не факт, что завершится успехом. Скрипт может банально крашануться по таймауту. Так что гораздо правильнее отдавать письмо для доставки хостеру через специальный примитив языка, и слать то письмо асинхронно уже силами хостера. Что все всегда и делают.

Но вдруг оказалось, что в технологию, 20 лет всех устраивающую, пришёл поручик Ржевский, и всё опошлил. Вездесущие спамеры, генерирующие от 50 до 75 процентов всего почтового трафика, буквально заваливают почтовые сервисы своим спамом, сгенерированным ровно так же, как и письма наших сайтов. С подстановкой в поля писем всего, чего угодно.

Поскольку письма спамеров абсолютно ничем не отличимы от посланий сайтов, почтовому сервису сложно правильно их детектировать. Да, есть эвристические механизмы анализа текста и хедеров писем, всякие чёрные и белые списки, плюс много чего ещё навыдумано на базе концепции Big Data. Всевозможные рейтинги спамности и прочее вуду.

Однако все мы прекрасно знаем на практике, что чем выше уровень абстракции, тем больше шансов тупо засунуть важное письмо в спам, или вообще его убить. И абсолютно никто потом не скажет, почему именно это произошло, и что конкретно не так. А спам всё равно прорвётся. Он жив только благодаря мимикрии, вкладывается в неё, а потому обманет любые алгоритмы.

Ровно с тех пор, как алгоритмы отсева спама потеряли эффективность, и это было осознано почтовыми сервисами, все они внедрили простой подход.

Что хотят почтовые сервисы?

Письмо, отправленное через примитив PHP, своим возвратным адресом из поля «From» может ссылаться на любой email на любом сервисе. Например, владельцу сайта удобно получать фидбэк через сервис Гугла. Хорошо, нет проблем.

Но в таком случае почтовые сервисы настаивают на добавлении в письмо ещё одного поля «Return-Path», где следует указать e-mail в домене сайта, посылающего письмо. А также дополнить DNS запись этого домена специальной подписью SPF.

Либо можно не мудрить так сильно, а прямо писать в поле «From» e-mail в домене сайта, не забывая при этом про SPF запись в DNS. Что не потребует переписывания скрипта, шлющего письмо - ведь никаких необязательных дополнительных полей у письма в этом случае не создаётся.

Кстати, это единственный выход, когда хостинг либо не даёт устанавливать «Return-Path», либо переопределяет его (такое встречается).

Смысл всех этих действий прост - возвратным адресом (истинным из поля «Return-Path», или формальным из поля «From») указывается e-mail, сопоставляемый через айпишник, прописанный в SPF DNS, реальному айпишнику почтового шлюза хостера, через который письма и отправляются во внешний мир. Если внешний почтовый сервис видит совпадение этих двух айпишников, всё в порядке. Нет такого совпадения - значит, хедеры письма подделаны, и это спам.

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

Что делать нам?

Нам, владельцам сайтов, посылающих письма, в настройках всех скриптов следует указать e-mail в домене своего сайта, который и станет потом подставляться в поле «From».

Если в аккаунте у хостера живут несколько сайтов в разных доменах, то абсолютно всё равно, e-mail в чьём домене для всех этих сайтов Вы будете использовать. Почтовый шлюз у хостера для этих сайтов один и тот же, поэтому и SPF подпись в DNS всех этих сайтов тоже получится одинаковой.

Многие боятся организовывать почту в собственном домене, так как она не обучена бороться со спамом, и всем понятно, к чему это приведёт. Но Вас никто и не заставляет пользоваться этим ящиком через web-интерфейс хостера, либо посредством почтового клиента. Любой публичный почтовый сервис умеет забирать почту по POP3.

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

SPF запись (Sender Policy Framework).

Всякий, кого не забанили в Гугле, может поначитаться справочных материалов по этой записи до потери пульсации. Синтаксис записи предельно простой, параметров у неё не много.

Те, кому нужен пример, могут пойти в просмотрщик DNS записей, вбить для изучения домен lasto.com, и потаращиться на последнюю, так называемую текстовую запись. Это она и будет:

lasto.com. 14400 IN TXT "v=spf1 +a +mx +ip4:185.15.208.45 ~all"

Обратите внимание, что айпишник в SPF не совпадает с айпишником самого сайта:

lasto.com. 14400 IN A 185.15.208.212

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

Сразу встаёт парочка вопросов. Рассмотрим их отдельно.

1. Где узнать айпишник почтового шлюза своего хостера?

С айпишником почтового шлюза хостера всё просто - создайте скриптом на сайте письмо самому себе, и по получении посмотрите его исходник. Там обязательно встретится хедер «Received» (далее на примере сайта lasto.com - у Вас выделенное красным будет иным):

Received: from userlogin by russia6.dnska.com

Смешной домен выступает в качестве почтового шлюза хостера, и где-то рядом даже может быть написан его айпишник, а может быть и не упомянут. Тогда вы идёте на уже знакомый Вам ресурс проверки IP-адреса сайта, и узнаёте айпишник этого «смешного домена». Он будет в точности таким, как указано для SPF записи в примере выше.

Ну или можно саппорт хостера спросить.

С айпишником мы разобрались.
Теперь понять бы, куда писать саму SPF запись.

2. Каким образом дополнить DNS домена записью SPF?

Проблема поначалу кажется страшной. Потому что обычно у регистратора доменов вместо полноценного редактора DNS записей пользователю даётся лишь дырка для вписывания неймсерверов, а ко всему остальному доступа либо нет вообще, либо за деньги, либо там всё настолько сложное, что боязно трогать руками.

Можно, конечно, смело броситься в бой, вооружившись идеологией научного метода тыка. Правда, у разных регистраторов процедура выглядит не одинаково, и рисовать про то картинки бесполезно. Но есть способ лучше.

В той же самой cPanel, где Вы создавали e-mail в одном из своих доменов, обязательно есть раздел «проверка подлинности», а в нём кнопка включения SPF. Надо просто её нажать. После чего через проверяльщик DNS записей, ссылка на каковой приводилась выше, убедиться в появлении соответствующей текстовой записи в DNS. И это всё.

Ну и раз Вы зашли в этот раздел cPanel хостера, нажмите там заодно кнопку DKIM. Что это такое и с чем его едят, хорошо описано в Вики.

Дрессировщикам Почтовых Выхухолей.

Как видите, кроме смены произвольного адреса электронной почты на адрес в домене сайта, в настройках скриптов ничего больше делать не нужно. Всё остальное достигается либо силами хостера, либо, если хостер убогий, и не даёт доступа к модификации DNS, придётся сходить в гости ещё и к регистратору домена.

Полезные ссылки.

Официальный сайт Sender Policy Framework.
Валидатор SPF.

Хостинг судного дня (мы в ответе за тех...)

Каждый вебмастер с регулярной периодичностью и чуть ли не ежегодно сталкивается с одной и той же проблемой - где ему теперь хостить свои сайты. Ибо рынок услуг хостинга низкомаржинальный и весьма капиталоёмкий. Оборудование приходится покупать по ту сторону полосатых столбиков, причём за тамошние же деньги.

Троянская свинья и хедер Content Security Policy.

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

Дорвейные технологии в 2015 году.

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

№ 1А как же почта для доменов?

А как же почта для доменов от всяких мейлов и прочих яндексов?
Не проще чем поднимать у хостера?

Не проще.
Попробуйте.
Только не понятно, зачем.

С точки зрения здравого смысла, в сегодняшних реалиях нет никакого резона держать свою почту на бесплатных почтовых сервисах. Хотя бы из чувства брезгливости - мейлы и прочие яндексы машинно читают все письма подряд, а потом ещё и хранят их копии минимум три года. Вам это зачем нужно?

Особо мудрые люди, понимая сей тренд, потихонечку размышляют об отказе от концепции email в пользу системы тикетов. В ней, кстати, и спаму неоткуда взяться, если концепцию тщательно продумать.

Но это для работы с пользователями и клиентами. Для всякого маркетинга без email не обойтись. По сути любой маркетинг и является спамом, так что сами понимаете :)

Олег

№ 2Тема DKIM и DMARC не раскрыта

Тема DKIM и DMARC с ключем reject не раскрыта от слова "совсем"

Для того, чтобы письмо не отвергалось сходу почтовыми сервисами, всё это не нужно. Тоже от слова "совсем".

На текущем этапе борьбы с ветряными мельницами написанного в статье вполне достаточно. Ибо всякие там DMARC абсолютно вторичны по отношению к SPF, и, более того, ещё и избыточны - у SPF вполне хватает собственных ключей выбора действий.

Dmitry Pall

№ 4При всем уважении к автору

habr.com
Это 60% почтового трафика рунета

Вслед за ними подтянутся и остальные, буквально в течении полугода
Посему dkim и dmarc нужны
Другое дело, что на виртуальном хостинге силами пользователя это не настраивается.

Вот именно.
На хостинге 90% сайтов это не настраивается.
Стало быть, в массы это не пойдёт.

И да, я бы попросил всё-таки отделять рекомендацию "шлём почту с сайта от имени адреса в своём домене, плюс пишем настройку SPF в DNS этого сайта, ибо иначе почта этого сайта не будет доходить никуда, кроме как самому себе" от всевозможных хренек сортировки заведомо поддельных писем, которым в рамках выданной выше рекомендации физически неоткуда взяться.

Если кому-то до смерти хочется подобные хреньки внедрять и настраивать, это его право. По факту же они не облигатуарны, а потому и думать про них незачем. У тех хренек была масса прототипов, и все они в итоге не взлетели.

Dmitry Pall

№ 5Что то я ни как не пойму этот майл.ру...

Несколько дней назад возникла проблема: перестали доходить до админских "емайлов" (которые, кстати, настроены в домене сайта) письма отправленные через контактную форму на сайте если в поле контактной формы "Ваш email" указать email на любом почтовом сервисе принадлежащем mail.ru, с адресами в других бесплатных почтовых сервисах типа Яндекс, gmail.com или в домене сайта контактная форма доставляет письма на админские емайлы без проблем.

Делаю запрос в техподдержку своего хостера, они в ответ пишут:
"Как видно из нижеуказанного лога, Вам необходимо выполнить настройку SPF-записи, DKIM-подписи и DMARC (https://help.mail.ru/mail-help/postmaster/dmarc) для почтовых доменов."

Спрашиваю в ответ:
"Причем здесь DMARC-политика Mail.ru. SPF-записи, DKIM-подписи мной включены стандартно на хостинге в разделе Я же не email рассылку делаю с хостинга указывая обратный адрес в сервисах Mail.ru, теряются письма отправленные через контактную форму на админсикй email настроенный в этом же домене или в gmail.com".

Техподдержка хостера опять ссылается на mail.ru. Ладно, настроили SPF-записи, DKIM-подписи и DMARC на хостинге как указано на странице mail.ru - проблема осталась, письма через контактную форму с обратным email на сервисах mail.ru до админских адресов не доходят. Снова терзаю техподдержку...

Техподдержка отвечает:
"Проблема заключается в том что если вы указываете отправителя *@list.ru, и отправляете письмо с нашего сервера - то вы как бы подделываете отправителя. А т.к. у mail.ru введена политика DMARC - они публично завляют с каких адресов почта с их доменов является легитимной. Почтовые сервисы которые проверяют DMARC записи - срезают почту которая получена не из тех адресов которые заявлены в ней.
Данная "фишка" в нашем любимом Mail.ru появилась недавно собственно потому проблема появилась сейчас."

Вот, сижу сейчас перед монитором, как баран перед новыми воротами и думаю... или я идиот и что-то не так понимаю ... или идиот не я, а кто-то другой и из за этого другого идиота на всех сайтах рунета умрут контактные формы? Да, для определенных вопросов можно наладить систему тикетов. А как же платежные формы? Для юзера который укажет в качестве своего электронного адреса емайл расположенный на сервисах Mail.ru платежные формы тоже станут не доступны? Или это все таки я что-то не так понимаю... или техподдержка хостера?

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

Именно поэтому хочется в поле From подставить email пользователя. Который может быть произвольным. То есть каким угодно. Только в этом случае ответ пользователю производится через естественное действие - нажатие кнопки ответа в почтовой программе (просто не хочется лезть в ПО сайта, и втыкать в письма дополнительные хедеры email-протокола).

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

Теперь письмо может посылаться только в адрес почты в собственном домене, который не проверяет поддельность письма. То есть полностью в силе совет, данный в посте - админский емайл у формы обратной связи должен быть в собственном домене. С пропиской тому домену соответствующей SPF в DNS.

Вы НЕ БУДЕТЕ проверять "поддельность" этого письма, поэтому оно до Вас дойдёт. Никакие DKIM-подписи и DMARC Вам не нужны. Вы ничего не меняете в ПО сайта, только заменяете емайл админа с какого угодно (что практиковалась ранее) на адрес в собственном домене. Всё.

Это то простейшее действие, которое восстанавливает работоспособность сайта. Это то, чего хотят майловцы. Больше никаких хитрых телодвижений делать не нужно. Вам полностью наплевать на то, что для Вашего админского емайла письмо будет выглядеть "поддельным". Вам просто нужна естественная логика действий при ответе на него, а не катавасия со всякой высокотехнологичной IT-хренью, понимать которую администратор сайта совершенно не обязан. Понавыдумывали тут...

При этом вот в упор не понимаю, каким образом письмо, созданное сайтом, и попадающее в папку входящих этого же сайта, касается Майла. Это письмо к Майлу вообще не ходит, ни транзитом, ни напрямую. Объясните мне это.

По сути вопрос с таким же содержанием в разных интерпретациях я задавал в техподдержку хостинга, но вменяемого ответа так и не получил... В итоге проблема решилась проще простого и самым проверенным способом - "методом тыка". Удалил все фильтры-перенаправления в почте домена на хостинге и подключил почтовый клиент напрямую - все заработало. Поставил систему тиккетов. Что уж там вдруг случилось с фильтрами-перенаправлениями, которые до этого исправно работали, и почему так избирательно только к адресам Майла, осталось не ведомо...

Возможно, была задействована концепция почты в собственном домене, но через сторонний сервис (Майл, Яндекс и Гугл такой предоставляют), и тогда всё понятно. Кстати, это хороший вариант для отсева спама - тут особенно хорош Гугл. Спам через него прорывается особенно редко.

Олег

№ 6Reply to вместе с From.

Насколько я понял, чтобы правильно перенаправлялся ответ от админа, достаточно указать мыло комментатора в поле Reply to.

Тогда кнопка "Ответить" в веб интерфейсе почтовика будет работать корректно, подставляя в поле "Кому" тот самый ящик. При том, что в поле From стоит e-mail адрес блоговладельца в домене.

Ведь записи SPF на Reply to не распространяются.

По всей видимости, так и придётся делать.

airsound

№ 8Письма можно не отправлять напрямуюпрямсразу

1. Приняли данные из формы;
2. После валидации - через API внесли их в таблицу Гугла (spreadsheet)
3. В таблице на событие изменения стоит уведомление на gmail.

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

4. Profit!

(и мне не хватило длинны заголовка)

Для рядового юзера скрипта, наверное, всё это будет чуток сложновато понять и настроить, потому как не всем удаётся даже подключить по готовой инструкции гугловую авторизацию, к примеру говоря. Но да, тоже вариант.

Однако уже чётко видна и осознаваема глобальная тенденция: со всеми этими законами яровых, всесторонним контролем интернета на всех уровнях его иерархии, уже и не сильно хочется физически слать письмо от сайта к админу (от всяких там форм обратной связи, с извещениями о комментах, и прочая). Логичнее это копить внутри сайта, и ознакамливаться путём визита в админку.

Взбрыки почтовых сервисов по поводу "поддельных" писем, кстати говоря, тоже всецело обусловлены примерно теми же соображениями, что лежат в основе законов яровых - всё, что непонятно, кем написано, тупо не доставляется. Тут ещё возможна эскалация. И она будет, куда ж денется.

judgefog