Gmail сейчас нещадно режет любую почту, которая кажется ему подозрительной, в спам. Ладно ещё когда рассылки не доходили, но тут в спам стали попадать одноразовые адресные письма. Решаем эту проблему... Google прямо указывает на 3 настройки для отправителя, с помощью которых он может подтвердить что он не спамер а честный владелец домена с которого пришло письмо... Три настройки — это SPF, DKIM и DMARC. Разберём их по порядку: – SPF – Sender Policy Framework. Это посто запись в DNS’ке домена, в которой мы прописываем какие исходящие IP-адреса проходящих через наш домен сообщений считать корректными, а какие спамом... Нам просто нужно указать там свои IPшки, которые нужно считать корректными, и указать, что остальные IPшки сообщений, которые маскируются под наш домен и у которых даже исходящий мейл может иметь название нашего домена — следует считать спамом. Почтовый сервер принимает сообщения от какой-то домена, и сверяется с его DNS’кой на предмет, соответствует ли этому домену IPшка отправителя. После проверки решает, доставлять ли сообщение получателю, или зарезать сообщение как spam. С SPF всё проще простого. Просто берём и прописываем всё что гугл хочет в DNS. Создаём следующую TXT-запись: v=spf1 a mx include:mydomain.com ~all Кстати, некоторые DNS-редакторы имеют user-friendly интерфейс, и уже имеют поле SPF, в котором можно указать эту же самую запись: v=spf1 a mx include:mydomain.com ~all. Но дублировать её не надо. SPF это тот же TXT, и нет необходимости прописывать одну и ту же запись дважды. Параметры записи: v — это версия SPF, в данном случае spf1 означает первую версию. a и mx указывают что IPшки перчисленные в A и MX-записях домена автоматически считать хорошими. include:... перечисляем IPшки и хосты которые сервер получателя должен считать хорошими. -all или ~all или ?all — определяет, что сервер получателя должен делать с письмом. ?all (безотказная доставка) означает что желательно доставлять все письма домена отправленные с любой IPшки независимо ни от чего. -all (жёсткий отказ) означает что сервер получателя должен однозначно резать все письма от IPшек, которые не соответствуют домену как спам. (Но тут могут возникнуть проблемы с автоматическим форвардингом почтовых сообщений. К примеру, кто-то отправляет письмо на ваш почтовый адрес, с которого письмо немедленно форвардится дальше, например на ваш @gmail’овский ящик. -all по идее должен рубить такие сообщения, но в реальности тесты показали что гугл принимает такие отфорварженые сообщения, считая их, однако, немного подозрительными, помечая статус проверки SPF’ки как softfail (Received-SPF: softfail...) ~all (мягкий отказ) означает что решение о доставке или о зарубывании письма остаётся на усмотрение сервера. Такие письма помечаются в заголовке письма отметкой (Received-SPF: pass...) при успешной проверке, и (Received-SPF: softfail...) при неуспешной. Решение об отправке письма в спам или о доставке отстаётся за алгоритмом сортировки письмем на сервере получателя. Я у себя прописал именно мягкий отказ, с тильдой (~all), поскольку я форваржу некоторую свою почту (публичные адреса, на которые валит куча спама) на свой gmail-аккаунт. Просто на моём сервере у меня нет своего спам-фильтра, и я хочу чтобы работу по сортировке спама за меня сделал google/gmail. – DKIM. Тут чуток посложнее. Здесь нам нужно сгенерить электронный ключ, состоящий из приватной и 1024-байтной публичной части. Приватную часть подвязываем к EXIM’у на нашем сервере, а публичную, опять таки, суём в DNS. Пошагово: – Идём куда-то, и генерим себе RSA-ключ для домена. Сгенерить ключ для DKIM’a себе можно например здесь: https://luxsci.com/extranet/dkim.html или здесь: https://www.socketlabs.com/domainkey-dkim-generation-wizard/ или тут: http://www.port25.com/support/domainkeysdkim-wizard/. (Только, помним, что он должен быть как минимум 1024-байтным. Гугл не считается с ключами меньшей длины. считая их ненадёжными.) При генерации ключа нам нужно указать своё домен и какой-то идентификатор ключа, selector. Пусть будет key1, для этого примера, но он может называться как угодно, например dkim. – Публичную часть ключа прописываем себе в DNS’ку. Создаём две новых TXT-записи и пишем в первую: _domainkey.mydomain.com TXT o=~; Кстати, некоторые генераторы пытаются подсунуть ещё параметр t=y, но это параметр для теста. Тест нам не нужен, поэтому пишем только o=~; во вторую: key1._domainkey.mydomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0G.....IDAQAB (Вместо mydomain.com конечно подставляем имя своего домена, вместо key1 выбранный селектор, а в параметре p= указываем собственно публичную часть RSA-ключа.) Ещё, важно!, чтобы в публичном ключе не было пробелов, символов переноса строки, табуляций и т.д.. Публичный ключ — это одна строка, пишущаяся слитно. Тестировать DKIM-запись прописанную в DNS’ке можно тут http://dkimcore.org/c/keycheck (но возможно придётся подождать до 48 часов до обновления DNS’ок. – Приватную часть ключа сохраняем в какой-то файлик, который записываем в секретное место на сервере, а в конфиге EXIM’a (exim.conf) прописываем следующее: Где-то вначале так: # DKIM DKIM_ENABLE = yes # если мы захотим отключить DKIM в будущем, можно будет закомментировать эту строку DKIM_DOMAIN = ${lc:${domain:$h_from:}} DKIM_FILE = /etc/exim/dkim/${lc:${domain:$h_from:}}.key DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} а в блоке описания транспортов пишем как-то так: begin transports remote_smtp: driver = smtp.ifdef DKIM_ENABLE dkim_domain = DKIM_DOMAIN dkim_selector = key1 dkim_private_key = DKIM_PRIVATE_KEY.endif Домен здесь подставится автоматически, вместо key1 нужно будет указать выбранный нами селектор, а файлик с приватной частью ключа положить по адресу, указанному в переменной DKIM_FILE. Это будет что-то вроде /etc/exim/dkim/mydomain.com.key – Это всё. Для начала подписывания — перезапускаем EXIM: /etc/init.d/exim restart Ещё возможно потребуется подождать до 48 часов для обновления DNSок, чтобы сервер получателя увидел публичную часть ключа. – DMARC. Настройка DMARC описана тут (https://support.google.com/a/answer/2466563?hl=ru), но повторяться лень, просто создаём парочку новых TXT-записей у себя в DNS’ках и прописываем правила: _adsp._domainkey.mydomain.com TXT dkim=all _dmarc.mydomain.com TXT v=DMARC1; p=quarantine; adkim=s; aspf=s; Популярно о параметрах-тэгах DMARC’a — описано на http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags (тестировать DMARC-запись можно тут: http://mxtoolbox.com/SuperTool.aspx). Параметры: – v — version (версия DMARC) – p — policy (политика, может быть none, quarantine или reject). – none — никаких активных действий со стороны принимающего сервера не будет, кроме записи в логе (или отчёта к отправителю, если у того настроен параметр rua, в котором можно указать мейл, на который будут поступать отзывы от принимающих серверов. Подробно можно изучить в доках DMARC’a, я этот параметр не использую, логи получать и читать не хочу). – quarantine — сообщение будет доставлено, но помечено как спам (получатель сам будет выуживать его из спама/карантина). – reject — письмо получателю не доходит, происходить отлуп отправителю, указанному в поле From. (Примерный вид отлупа — ниже.) – adkim и aspf — режим сверки (alignment mode) подписей DKIM и SPF. Последние два параметра могут иметь значения r (relaxed) или s (strict). Если вы используете почту в поддоменах, типа @news.domain.com, то ставьте r (совпадение по организации, по главному домену). Если все почтовые ящики находятся в пределах одного домена @domain.com — ставьте s (будет строгая проверка по полному названию домена). – ...больше параметров в описании на https://support.google.com/a/answer/2466563?hl=ru. Нам здесь важен лишь один параметр, параметр p (Policy). Это даёт указание почтовику адресата, что делать с письмами, которые поступили НЕ с домена указанного в mydomain.com. У этого p[olicy] возможны три значения: none, quarantine или reject. Скажу лишь о reject’е (который, на первый взгляд, кажется самой правильной политикой. Это типа указание отклонять все письма от @mydomain.com в поле From, которые реально поступают от другого сервера, не mydomain.com)... Я тестировал все три настройки, пересылая письма через @hotmail.com на @gmail.com. Дальнейший текст — мой личный опыт, без претензии на объективность. | REJECT. По идее reject — самая правильная настройка. Письма, которые идут не с вашего домена, но в полях From указывают ваш домен, должны быть отклонены. Однако, люди зачастую пользуются форвардерами. Например, адресат, имея почтовый ящик на @hotmail.com в реальности не пользуются им, настраивая редирект на свой @gmail.com. И вот при политике такой reject-политике, вместо благополучной доставки письма на имя@hotmail.com, вы получите отлуп. Из-за того, что SPF-тест будет провален, письмо пришло с IP-шки отличающейся от домена. DKIM-тест, который содержит публичный ключ, будет пройеден, но отлуп произойдёт даже из-за заваленного SPF. Так происходит, например, при отправке письма на @hotmail.com, когда адресат настроил перенаправление на @gmail. Получается такой вот отлуп: Delivery Status Notification (Failure) -------------------------------------- This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. someemail@gmail.com -------------------------------------- Reporting-MTA: dns;COL004-OMC4S7.hotmail.com Received-From-MTA: dns;EUR02-AM5-obe.outbound.protection.outlook.com Arrival-Date: Fri, 9 Dec 2016 05:34:01 -0800 Final-Recipient: rfc822;someemail@gmail.com<\/span> Action: failed Status: 5.5.0 Diagnostic-Code: smtp;550-5.7.1 Unauthenticated email from yourdomain.com is not accepted due to 550-5.7.1 domain’s DMARC policy. Please contact the administrator of 550-5.7.1 yourdomain.com domain if this was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initiative. f16si33975676pli.56 – gsmtp NONE. Я поставил none, для гарантии того, что письма не будут отвергнуты. Однако, мне кажется, что gmail не воспринимает политику none и игнорирует её. По меньшей мере при пересылке почты с hotmail. Именно с hotmail, потому что при пересылке через yandex всё прошло. Детальнее не углублялся, мне для моей задачи важна именно пересылка через hotmail/outlook. Я даже указал параметр rua, так что моя запись выглядела следующим образом: v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:postmaster@mydomain.com Однако в приходящих отчётах видел следующее: mydomain.com s s

reject

reject 100
То есть, очевидно, политика none не срабатывала, преобразуясь в reject. QUARANTINE. Внезапно с p=quarantine всё заработало. Письма через hotmail проходят, и даже не попадают в спам. (Но в моём случае меня бы устраивало даже если бы и попадало в спам, я бы обращал на это внимание адресата.) Таким образом, лично я для себя решил, что безопаснее всего сделать политику quarantine (для большей гарантии получения письма адресатом, в случае, если он пользуется форвардерами). Тестирование всего: – DKIM-запись с публичным RSA-ключём тестируем тут: http://dkimcore.org/c/keycheck. Отличная тулза, которая укажет на ошибки синтаксиса. Альтернативно — тут: https://www.mail-tester.com/spf-dkim-check. Эта тулза заодно проверит и SPF, но на ошибки не укажет. – Проверка доставки писем (тестирует ВСЁ, и SPF, и DKIM и DMARC): https://www.port25.com/authentication-checker/. Вкратце... Чтобы потестить результаты по IPшке отпрпавителя — отправьте тестовое письмо на check-auth@verifier.port25.com. – Ещё DMARC и кучу других записей DNS: http://mxtoolbox.com/SuperTool.aspx И ещё: Если что-то не получается, не переживайте. Всё получится. Настройка всех этих записей для неопытного человека — задача не на один день. Здесь проблема в том, что обновления DNS-записей можно ожидать до 2 суток. Пока DNS не обновится, нет повода нервничать о том, что что-то всё ещё не работает. Если настройки правильные, то через некоторое время заработают сами собой. Однако, даже когда всё будет настроено и заработает при прямой доставке на gmail, обязательно тестируйте доставку письма при пересылке. Например, через hotmail.com. Там легко настраивается форвардер. ———————————— This document has been copied from FAVOR.com.ua (https://favor.com.ua/en/blogs/23394.html). All rights reserved by author of the material. In case of re-publication, the link to the source of the material is strongly required! Document date: April 27, 2015