Comments 86
Ох. Если я отправляю письмо с сервера (PHP) скриптом, для домена site.ru я делаю поддомен mailer.site.ru, указываю у поддомена SPF с IP адресом сервера отправителя, A-запись с сервером отправителя, в поле From указываю noreply@mailer.site.ru. — мне надо беспокоиться, или надо для поддомена mailer тоже делать почту-на-домене?
Аналогичный вопрос, когда кроме SPF есть ещё DKIM.
Аналогичный вопрос, когда кроме SPF есть ещё DKIM.
DMARC проверяет align для организационного домена. Организационный домен это например example.org или example.or.uk (т.е. первый поддомен в домене, открытом для регистрации). Список доменов открытых для регистрации обычно берется из http://publicsuffix.org. Т.е. если в SPF сработает mailer.example.org а в From будет example.org — это нормально, т.е. организационный домен в данном случае example.org и он совпадает.
Это кроме случая, когда домен site.ru публикует DMARC-политику с полем aspf=s, s (strict) требует строгого соответствия домена из SPF и домена из From.
Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.
Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.
smtp.mail.ru, порт 465 с использованием SSL
А почему вы используете устаревший протокол SMTPS вместо STARTTLS на порте 587?
STARTTLS и SSL здесь используются не для обозначения шифрования, т.к. в обоих случаях используется TLS, а для удобства различения двух технологий.
Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.
P.S. Mail.Ru поддерживает и то и другое.
Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.
P.S. Mail.Ru поддерживает и то и другое.
Mail.Ru поддерживает и то и другое.
Вот только в справке это не отражено (как и у Яндекса), а некоторые современные приложения не поддерживают SMTPS и народ путается.
Привет, Майл.РУ.
Вашу техподдержку не дождешься, поэтому спрошу здесь. Так получилось, что оригиналы одного фотоальбома у меня лежали только на фотохостинге Мейл.ру. И вы своими очередными «прорывными» изменениями их по#ерили.
Как теперь можно скачать полноразмерное фото с «моего мира» mail.ru?
Имеется ввиду фото не с тем разрешением, в котором оно открывается, а с тем, которое было при залитии фото на фото.мэйл.ру
Возможно ли такое, если да, то как можно осуществить?
Я загружал фото в альбом с сохранением оригинала! Это было еще тогда, когда проект Фото.мейл.ру был отдельным от «моего мира». До недавнего времени эта возможность была. А теперь только пережатые фотки, оригиналов больше нет. Хотя информация в EXIF осталась.
Вашу техподдержку не дождешься, поэтому спрошу здесь. Так получилось, что оригиналы одного фотоальбома у меня лежали только на фотохостинге Мейл.ру. И вы своими очередными «прорывными» изменениями их по#ерили.
Как теперь можно скачать полноразмерное фото с «моего мира» mail.ru?
Имеется ввиду фото не с тем разрешением, в котором оно открывается, а с тем, которое было при залитии фото на фото.мэйл.ру
Возможно ли такое, если да, то как можно осуществить?
Я загружал фото в альбом с сохранением оригинала! Это было еще тогда, когда проект Фото.мейл.ру был отдельным от «моего мира». До недавнего времени эта возможность была. А теперь только пережатые фотки, оригиналов больше нет. Хотя информация в EXIF осталась.
Что я должен сделать как владелец доменного имени (скажем, site.ru), если я выбрал почтовым провайдером компанию Яндекс (то есть А- и МХ- записи указывают на яндекс), чтобы при доставке писем на mail.ru не возникало неприятных неожиданностей?
Пока вы не опубликуете DMARC-политику для site.ru каких-либо проблем, связанных с DMARC у вас не возникнет.
Чтобы правильно и без проблем внедрить DMARC вам надо сделать следующее:
1. в SPF-запись добавить IP серверов с которых вы шлете письма напрямую + включить SPF-политику яндекса через include:_spf.yandex.ru или redirect=_spf.yandex.ru.
2. на pdd сгенерировать DKIM-ключ для pdd и прописать его в своей зоне. На самом деле он уже сгенерирован и найти его можно запросом
host mail._domainkey.securityvulns.ru dns1.yandex.ru
даже если ваша зона хостится не у Яндекса.
3. Прописать сгенерировать и прописать ключи для всех остальных серверов рассылающих почту от site.ru (следует использовать другие селекторы DKIM)
4. Прописать DMARC-политику, для начала нестрогую.
Чтобы правильно и без проблем внедрить DMARC вам надо сделать следующее:
1. в SPF-запись добавить IP серверов с которых вы шлете письма напрямую + включить SPF-политику яндекса через include:_spf.yandex.ru или redirect=_spf.yandex.ru.
2. на pdd сгенерировать DKIM-ключ для pdd и прописать его в своей зоне. На самом деле он уже сгенерирован и найти его можно запросом
host mail._domainkey.securityvulns.ru dns1.yandex.ru
даже если ваша зона хостится не у Яндекса.
3. Прописать сгенерировать и прописать ключи для всех остальных серверов рассылающих почту от site.ru (следует использовать другие селекторы DKIM)
4. Прописать DMARC-политику, для начала нестрогую.
А что делать, если провайдер не хочет\не может прописать обратную запись PTR, чтобы письма проходили проверку SPF?
SPF не связан с обратной зоной и будет проходить независимо от PTR.
Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
А зачем прописывать PTR для SPF? Это разве обязательное требование?
И на какой домен должен указывать PTR, когда почтовик на этом IP обслуживает несколько доменов?
И на какой домен должен указывать PTR, когда почтовик на этом IP обслуживает несколько доменов?
PTR никак не связан с SPF, кроме случаев, когда в SPF применяется конструкция типа ptr:mail.example.com, но многие серверы проверяют PTR, поэтому он должен:
1. быть
2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.
1. быть
2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.
Понял, благодарю. Тогда в этом действительно есть логика.
В нашем случае есть клиент, у которого почта на хостинге и не ими управляется. Там есть и проверка PTR, и проверка DKIM.
Таких клиентов с серьёзным подходом к почте, к сожалению, мало.
Намного больше, которые используют mail.ru. И хорошо, если эти адреса не будут подделываться спамерами, потому что из-за таких клиентов пришлось добавить в исключения этот домен, иначе проблемы с получением писем у наших менеджеров.
Может подскажете даже, как можно грамотно разрулить настройку почты в случае двух провайдеров интернета (active\passive), и при этом проходить все проверки?
При условии, если не менять второго провайдера, где нет обратной записи PTR и не уносить почту на хостинг.
Таких клиентов с серьёзным подходом к почте, к сожалению, мало.
Намного больше, которые используют mail.ru. И хорошо, если эти адреса не будут подделываться спамерами, потому что из-за таких клиентов пришлось добавить в исключения этот домен, иначе проблемы с получением писем у наших менеджеров.
Может подскажете даже, как можно грамотно разрулить настройку почты в случае двух провайдеров интернета (active\passive), и при этом проходить все проверки?
При условии, если не менять второго провайдера, где нет обратной записи PTR и не уносить почту на хостинг.
Если у вас два подключения к двум провайдерам — заведите на почтовый сервер IP адреса от обоих провайдеров (напрямую или через проброс/трансляцию порта), опубликуйте две MX-записи, с разными приоритетами, если какой-то из провайдеров предпочтительней или с одинаковыми, если они равнозначны. В SPF запись включите все IP адреса всех серверов. Если один из провайдеров не предоставляет PTR-записи — избегайте использовать выделенный им IP адрес для отправки почты. Для этого, например, добавляйте маршрут через него на почтовом сервере с большей метрикой. Для входящей почты наличие PTR значения не имеет.
Ну сейчас так и сделано. Но поскольку я новичок в этом, то постоянно сомнения — правильно ли, может есть способы правильней.
Да и смущают EHLO\HELO.
Каждому IP не присвоить одинаковый FQDN ведь.
Да и смущают EHLO\HELO.
Каждому IP не присвоить одинаковый FQDN ведь.
Не надо присваивать одинаковый — вполне допустимо чтобы он был разный, но для каждого имени используемого в HELO надо создать дополнительную SPF-запись.
Для прохождения DMARC'а письмами от MAILER-DAEMON надо чтобы домен во From: у этих писем либо отсутствовал (что не очень хорошо) либо совпадал с точностью до организационного домена с именем из HELO. Т.е. если в HELO у вас будет relay1.mail.example.org в во From: mailer-daemon@mail.example.org или mailer-daemon@relay1.mail.example.org и для relay1.mail.example.org будет опубликована отдельная SPF-запись — SPF-DMARC пройдет.
И совсем не обязательно, чтобы HELO совпадал с PTR.
Для прохождения DMARC'а письмами от MAILER-DAEMON надо чтобы домен во From: у этих писем либо отсутствовал (что не очень хорошо) либо совпадал с точностью до организационного домена с именем из HELO. Т.е. если в HELO у вас будет relay1.mail.example.org в во From: mailer-daemon@mail.example.org или mailer-daemon@relay1.mail.example.org и для relay1.mail.example.org будет опубликована отдельная SPF-запись — SPF-DMARC пройдет.
И совсем не обязательно, чтобы HELO совпадал с PTR.
Я правильно понимаю, что вместо одной записи:
v=spf1 a:mail1.domain.ru a:mail2.domain.ru ip4:11.22.33.44 ip4:55.66.77.88 ?allДолжно быть две:
v=spf1 a:mail1.domain.ru ip4:11.22.33.44 ?all?all — требуется, чтобы наши письма доходили до того самого клиента, ибо им письма приходят уже изменёнными сервером пересылки (то есть не от имени нашего сервера).
v=spf1 a:mail2.domain.ru ip4:55.66.77.88 ?all
нет, ни в коем случае. Двух записей для одного домена быть не должно. Надо примерно так:
domain.ru. IN TXT "v=spf1 a:mail1.domain.ru a:mail2.domain.ru ip4:11.22.33.44 ip4:55.66.77.88 ?all"
mail1.domain.ru. IN TXT "v=spf1 include:domain.ru -all"
mail2.domain.ru. IN TXT "v=spf1 include:domain.ru -all"
«p=none» просто делает всю эту историю бесполезной. Так же как в SPF все пишут "~all".
Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
Отчасти да, именно поэтому мы внедряем p=reject.
Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.
Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.
При настройке, reject -all сразу ставить нежелательно.
Хороший совет от Google — последовательное развертывание DMARC.
support.google.com/a/answer/2466563?hl=ru
Хороший совет от Google — последовательное развертывание DMARC.
support.google.com/a/answer/2466563?hl=ru
…я пользуюсь перенаправлениями для сбора почты с нескольких аккаунтов на разных сервисах в общий ящик
На случай если это не будет работать, вам следует решить эту проблему с другими крупными почтовиками. В противном случае найух ваш почтовик который не принимает письма и не отправляет в спам всякие купончики от которых не отписаться и которые ежедневно помечаются как спам.
На случай если это не будет работать, вам следует решить эту проблему с другими крупными почтовиками. В противном случае найух ваш почтовик который не принимает письма и не отправляет в спам всякие купончики от которых не отписаться и которые ежедневно помечаются как спам.
Так вот в чем дело… а я то думаю, что же случилось. Раньше ящик был завален спамом, будто фильтров у вас вообще не было, а теперь, да, спама в основную папку приходит мало. НО мне приходится теперь периодически лицезреть содержимое папки «спам», потому что теперь туда попадают и нормальные письма. Да, классно, что вы внедрили что-то передовое, но может стоит протестировать на реальных пользователях, а не «у кого не доходят письма, тот сам виноват», какой мне смысл от фильтра, который зарубает нужные мне письма.
Нет, DMARC здесь непричем, он не влияет напрямую ни на объем спама в вашем ящике ни на прохождение обычных писем. Если какие-то письма попадают в папку спам — не забывайте нажимать на них «Не спам», это гарантирует, что в дальнейшем письма от данного отправителя в спам не попадут. Если проблема повторяется — обратитесь в службу поддержки, мы обязательно выявим и устраним причину.
«Пользователь <делает что-то>. К сожалению, единственное решение — так не делать.»
Это всё, что вам нужно знать о mail.ru.
Огромная головная боль администратора хостинга. Почему-то ни один из крупных игроков почтовых услуг не доставляет таких проблем, какие прилетают от mail.ru. Oh wait… никто кроме них вообще не доставляет проблем.
Это всё, что вам нужно знать о mail.ru.
Огромная головная боль администратора хостинга. Почему-то ни один из крупных игроков почтовых услуг не доставляет таких проблем, какие прилетают от mail.ru. Oh wait… никто кроме них вообще не доставляет проблем.
Расскажите с какими проблемами, связанными с внедрениями DMARC вы, как хостер столкнулись — обязательно постараемся учесть, помочь, посоветовать.
судя по всему, с проблемами, связанными с внедрениями DMARC, мы ещё только будем сталкиваться. пока остальных хватает.
btw, вы упомянули белые списки. они у вас реализованы только для DMARC или есть некие общесистемные? по этому поводу у меня недавно получился отличный диалог с вашей поддержкой, которая поведала что белых списков нет и никогда не было. только как вот при этом быть с тем, что у меня сохранилась переписка, когда нас добавляли в белые списки по запросу, я не знаю. параллельная реальность, не иначе.
btw, вы упомянули белые списки. они у вас реализованы только для DMARC или есть некие общесистемные? по этому поводу у меня недавно получился отличный диалог с вашей поддержкой, которая поведала что белых списков нет и никогда не было. только как вот при этом быть с тем, что у меня сохранилась переписка, когда нас добавляли в белые списки по запросу, я не знаю. параллельная реальность, не иначе.
DMARC не затрагивает хостеров. С трудностями могут столкнуться некоторые ваши клиенты, это может привести к обращению в службу поддержки, но обращение в данном случае легко конвертируется в продажу услуги — хостинга для почтового домена, доработки серверных скриптов.
У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.
У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.
зато хостеров отлично затрагивает блокировка по IP, в том числе за, цитата: «Дело в том, что с IP-адреса xxx.xxx.xxx.xxx отправляется большое количество писем на невалидные адреса.» WUT?!
мы устали бороться, обращение в службу поддержки, к сожалению, конвертируется теперь только в настоятельную рекомендацию не иметь с вашим сервисом дел.
мы устали бороться, обращение в службу поддержки, к сожалению, конвертируется теперь только в настоятельную рекомендацию не иметь с вашим сервисом дел.
Вы как-то ограничиваете/следите за спамом рассылаемым с хостинговых сервисов? Если у вас есть выделенная сеть, можно подписаться на FBL
http://fbl.postmaster.appsmail.ru/
и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.
http://fbl.postmaster.appsmail.ru/
и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.
перебора не было. по переписке с поддержкой я уже понял, что объяснять про shared что-то бесполезно…
просто здесь «любая почтовая служба» стоит читать как «mail.ru» =) почему-то только вам пришло в голову присвоить себе полномочия решать, что все письма с IP должны тупо режектиться на основании странных метрик о несуществующих адресах.
там судя по переписке с саппортом ещё много веселья, и судя по формулировкам, вы к ним имеете прямое отношение =) от одного только отношения к почтовым редиректам было бы очень смешно, если бы вы не были так популярны на постсоветском пространстве. вот и приходится раз за разом объяснять, что вы слишком многое на себя берёте и мы бессильны что-либо с этим сделать. раньше (лет пять назад, емнип) хоть можно было что-то обсудить, белые списки были, опять же. сейчас, видимо, уже всё, терминальная стадия.
просто здесь «любая почтовая служба» стоит читать как «mail.ru» =) почему-то только вам пришло в голову присвоить себе полномочия решать, что все письма с IP должны тупо режектиться на основании странных метрик о несуществующих адресах.
там судя по переписке с саппортом ещё много веселья, и судя по формулировкам, вы к ним имеете прямое отношение =) от одного только отношения к почтовым редиректам было бы очень смешно, если бы вы не были так популярны на постсоветском пространстве. вот и приходится раз за разом объяснять, что вы слишком многое на себя берёте и мы бессильны что-либо с этим сделать. раньше (лет пять назад, емнип) хоть можно было что-то обсудить, белые списки были, опять же. сейчас, видимо, уже всё, терминальная стадия.
Эм. А подскажите мне где вы работаете, я ваши блоки адресов тоже занесу в персональный блок лист. Правильно mail.ru делает. Если вы не хотите бороться со спамом с вашего ip, не подписаны на FBL, то чего вы жалуетесь?
Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
с наших ip не рассылается спам, у нас не совсем shared, ближе к saas
Ну, вот у меня тоже Saas и существенных проблем не было. Вообще, возможно, объемы не те (до 70 000 в день во все стороны). Процент не активных ящиков там велик, но мы стараемся такие вещи отслеживать и чистить базу от мертвяков, хотя это затруднительно с юридической точки зрения. При этом клиенты, которые с головой дружат и используют SPF на своих доменах вообще проблем не испытывают.
ну вот да, чистить базы на клиентских инсталляциях как-то не очень, не так ли? =)
что ещё более усугулбяется тем, что кое-кто удаляет ящики после какого-то периода неактивности. вот он был хороший живой ящик, а вот ты уже злостный спамер, потому что посмел отправить письмо на несуществующий адрес. неплохо, майлру, неплохо.
что ещё более усугулбяется тем, что кое-кто удаляет ящики после какого-то периода неактивности. вот он был хороший живой ящик, а вот ты уже злостный спамер, потому что посмел отправить письмо на несуществующий адрес. неплохо, майлру, неплохо.
а жалуемся мы на то, что при количестве исходящих спамных писем равном ноль целых ноль десятых долбаный mail.ru отлично блокирует серверы целиком. так не делает никто больше, ни гугл, ни яндекс. даже на параноидальный аол почта ходит без проблем. раньше майлру нас заносили в белые списки, сейчас этот функционал упразднили.
Какой установлен порядок внесения своего домена в этот белый список DMARC? Support в ответ на
[Ticket#2016052721031437] дал ссылку на эту статью и ни какой конкретики.
У нас маленький почтовый сервер на 50 человек, люди часто используют mail.ru в качестве основного ящика, а наш используют для официальных писем. И ставят редирект, который с включением DMARC на mail.ru перестал работать. Правда, вроде только в случае, если с mail.ru кто-то послал письмо на наш почтовый адрес, где стоит редирект на mail.ru же почтовый адрес респондента… Хотелось бы решить этот вопрос не нагибая пользователей. Учитывая популарность mail.ru среди пользователей — ситуация вроде должна быть довольно распространённая, но нигде внятного описания я не нашёл (довольно долго листал\искал по help.mail.ru и просто гуглил), хотя может не те поисковые запросы использовал…
Кстати, вариант со сборщиком почты не очень хорош и его хотелось бы избежать, иногда люди используют почту, как чат, с редиректом почта доходит мгновенно и за минуту может быть отправленно несколько сообщений с обоих сторон. Плюс, если человек меняет пароль — редирект продолжает работать, а сборщик — нет.
[Ticket#2016052721031437] дал ссылку на эту статью и ни какой конкретики.
У нас маленький почтовый сервер на 50 человек, люди часто используют mail.ru в качестве основного ящика, а наш используют для официальных писем. И ставят редирект, который с включением DMARC на mail.ru перестал работать. Правда, вроде только в случае, если с mail.ru кто-то послал письмо на наш почтовый адрес, где стоит редирект на mail.ru же почтовый адрес респондента… Хотелось бы решить этот вопрос не нагибая пользователей. Учитывая популарность mail.ru среди пользователей — ситуация вроде должна быть довольно распространённая, но нигде внятного описания я не нашёл (довольно долго листал\искал по help.mail.ru и просто гуглил), хотя может не те поисковые запросы использовал…
Кстати, вариант со сборщиком почты не очень хорош и его хотелось бы избежать, иногда люди используют почту, как чат, с редиректом почта доходит мгновенно и за минуту может быть отправленно несколько сообщений с обоих сторон. Плюс, если человек меняет пароль — редирект продолжает работать, а сборщик — нет.
Сейчас редирект не будет работать только в такой ситуации: есть user1@mail.ru с него письма редиректятся в user@company.ru а с него обратно на mail.ru, например в user2@mail.ru и при этом кто-то из пользователей mail.ru, например user3@mail.ru будет писать на user1@mail.ru. Попросите пользователей избегать двойных редиректов между разными сервисами.
Могу еще порекомендовать воспользоваться biz.mail.ru, это снимет большую часть проблем.
Если в какой-то другой ситуации возникают проблемы — перешлите полный текст сообщения о невозможности доставки, я разберусь.
Могу еще порекомендовать воспользоваться biz.mail.ru, это снимет большую часть проблем.
Если в какой-то другой ситуации возникают проблемы — перешлите полный текст сообщения о невозможности доставки, я разберусь.
Такая же проблема с редиректом. Двойного редиректа нет. Только user1@mail.ru -> user@company.ru — >user2@mail.ru.
Все детали есть в тикете Ticket#2016072621040891. Если у вас нет туда доступа, скажите куда прислать ответ сервера.
Все детали есть в тикете Ticket#2016072621040891. Если у вас нет туда доступа, скажите куда прислать ответ сервера.
Если редирект организован так, что меняет содержимое письма не меняя From — это приведет блокировке письма по DMARC. Необходимо либо исправить редирект так, чтобы он не менял содержимое письма, либо организовать редирект так, чтобы он подставлял авторизованный From, либо отказаться от редиректа и использовать сбор почты.
Наконец-то, не прошло и 10 лет. Может хоть теперь поменьше спама будет приходить
Если про отсутствие авторизации почты — то прошло не только 10, но и 25 лет, а если про внедрение DMARC — то работа над ним началась в 2012-2013 годах, стандартом он стал в 2015, Mail.Ru поддерживает DMARC с 2014го.
последние год-полтора спама стало приходить больше чем до этого. причем валиться именно в inbox. DMARC?
Нет, скорей это связано с «засвеченностью» ящика — чем дольше живет адрес электронной почты, тем больше спама на него идет. В целом объем спама последние годы достаточно стабилен, а объем спама доходящего до инбокса снижается. Не забывайте нажимать кнопку «Спам» — она не просто переносит письмо в соответствующую папку, она отписывает вас от рассылки, помогает категоризировать рассылку и сделать так, чтобы похожие письма не доходили вам и другим пользователям и шлет жалобы администраторам сетей / сервисов рассылок о том, что клиент нарушает правила рассылок.
Ох, офигенно.
А теперь о проблемах. Использую личную почту и отдельно заведенный ящик на mail.ru для отправки писем через php скрипт.
1. Если отправлять через специальный ящик, то у вас система не учитывает заходы по smtp (заходов по imap или pop нет, как и заходов через веб-морду) — ящик блокируется через какое-то время для отправки писем.
2. Завести почту для бизнеса — сделайте поддержку кириллических доменов сначала в почте для бизнеса.
3. Хостинг на рег.ру. Резолвится обратно в технический домен по номеру пользователя, висят несколько доменов — что делать для «чайников»?
А то я если честно просто фигею, кириллическим доменам уже около 6 лет, а никто их нормально не поддерживает. И иногда даже до смешного доходит, как в истории с Яндекс.Маркетом.
А теперь о проблемах. Использую личную почту и отдельно заведенный ящик на mail.ru для отправки писем через php скрипт.
1. Если отправлять через специальный ящик, то у вас система не учитывает заходы по smtp (заходов по imap или pop нет, как и заходов через веб-морду) — ящик блокируется через какое-то время для отправки писем.
2. Завести почту для бизнеса — сделайте поддержку кириллических доменов сначала в почте для бизнеса.
3. Хостинг на рег.ру. Резолвится обратно в технический домен по номеру пользователя, висят несколько доменов — что делать для «чайников»?
А то я если честно просто фигею, кириллическим доменам уже около 6 лет, а никто их нормально не поддерживает. И иногда даже до смешного доходит, как в истории с Яндекс.Маркетом.
В качестве feature request: можете включить отступы с переносами в своих отчётах и отправлять их с отдельного ящика (вместо noreply@corp.mail.ru)?
Даже у Yahoo это сделано нормально, а ваши отчёты нечитаемы человеком.
Даже у Yahoo это сделано нормально, а ваши отчёты нечитаемы человеком.
Про адрес знаем, поменяем.
«Человекочетамость» для XML не подразумевалась, она увеличит отчеты примерно на 15-20%, а по некоторым доменам они уже превышают 500 мегабайт. Насколько это действительно требуется? Можно открыть отчет в браузере, например FF или пользоваться
DMARC XML-to-Human Converter.
«Человекочетамость» для XML не подразумевалась, она увеличит отчеты примерно на 15-20%, а по некоторым доменам они уже превышают 500 мегабайт. Насколько это действительно требуется? Можно открыть отчет в браузере, например FF или пользоваться
DMARC XML-to-Human Converter.
Не особо, я уже подписался на сервис от Postmark, но такой формат неприятно удивил. От Google они приходят в читаемом виде, да и zip должен сжимать пробелы.
Есть ли какая-нибудь инструкция, как настроить почтовый сервер Communigate для нормальной отправки почты, чтобы письма не реджектились?
По ссылке help.mail.ru/mail-help/postaster/dmarc описана настройка DNS-сервера. Правильно ли я понял, что почтовик тут не при чем?
Отправляю из php (From: ***@list.ru) через свой communigate сервер на хостинге. Доступ к communigate через учетку smtp. DNS-сервер тоже свой. Как проще решить проблему, не меняя настройки smtp в php-скриптах? (для вебмастера изменения должны быть незаметны)
15:54:10.14 5 SMTP-129695(list.ru) inp: 550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postaster/dmarc
По ссылке help.mail.ru/mail-help/postaster/dmarc описана настройка DNS-сервера. Правильно ли я понял, что почтовик тут не при чем?
Отправляю из php (From: ***@list.ru) через свой communigate сервер на хостинге. Доступ к communigate через учетку smtp. DNS-сервер тоже свой. Как проще решить проблему, не меняя настройки smtp в php-скриптах? (для вебмастера изменения должны быть незаметны)
Правильная инструкция — не использовать From: ***@list.ru, т.к. ваш сервер не авторизован отправлять почту с этого адреса.
А неправильная? Можно ли как то реализовать такой сценарий, чтобы не было ошибки и сообщения уходили:
Пользователь отправляет данные через контактную форму сайта, указывая свой email на *mail.ru, которые подставляется в поля From и Reply-to, но данные сообщения не доходят, а возвращются пользователю обратно с ошибкой:
Отправлять пробовал через авторизованный ящик со своего домена, а также через сервер mailgun.org (SPF и DKIM прописаны). Какая существует возможность избавиться от проблем с отправкой?
Пользователь отправляет данные через контактную форму сайта, указывая свой email на *mail.ru, которые подставляется в поля From и Reply-to, но данные сообщения не доходят, а возвращются пользователю обратно с ошибкой:
SMTP error from remote mail server after end of data:
host gmail-smtp-in.l.google.com [64.233.164.26]:
550-5.7.1 Unauthenticated email from inbox.ru is not accepted due to domain's
550-5.7.1 DMARC policy. Please contact administrator of inbox.ru domain if this
550-5.7.1 was a legitimate mail. Please visit
550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC
550 5.7.1 initiative. w135si31728617lfd.40 - gsmtp
Отправлять пробовал через авторизованный ящик со своего домена, а также через сервер mailgun.org (SPF и DKIM прописаны). Какая существует возможность избавиться от проблем с отправкой?
Прошу прощения за непонятливость, но у меня проблема с этим DMARC, прошу помощи.
Суть проблемы mail.ru блокирует письма. я администрирую сервис обратной связи formm.ru, сервис подменяет поле «Reply-To».
Зачем это делать?! В этом суть сервиса, например:
— Некий web мастер хочет разместить форму обратной связи на бесплатном хостинге
— Он генерирует на нашем сайте форму и размещает у себя html код
— Посетитель его сайта отправляет сообщение через эту форму, указав при этом свой обратный email
— сервис formm.ru получает данное сообщение и отправляет web мастеру на почту
— Соответственно в поле «Reply-To» подставляется email отправителя сообщения, что бы web мастер прочитав письмо ответил на письмо нажав кнопку ответить. И письмо попадет туда куда нужно. Кроме того, web мастер в списке писем видит, что письма у него пришли от конкретных пользователей, а не от нашего сервиса.
Естественно я понимаю, что спамеры так же используют данную возможность и с этим нужно нещадно бороться.
На сколько я понимаю я нарушаю политику DMARC и письма блокируются справедливо.
Но мне то, что делать? Подскажите.
Суть проблемы mail.ru блокирует письма. я администрирую сервис обратной связи formm.ru, сервис подменяет поле «Reply-To».
Зачем это делать?! В этом суть сервиса, например:
— Некий web мастер хочет разместить форму обратной связи на бесплатном хостинге
— Он генерирует на нашем сайте форму и размещает у себя html код
— Посетитель его сайта отправляет сообщение через эту форму, указав при этом свой обратный email
— сервис formm.ru получает данное сообщение и отправляет web мастеру на почту
— Соответственно в поле «Reply-To» подставляется email отправителя сообщения, что бы web мастер прочитав письмо ответил на письмо нажав кнопку ответить. И письмо попадет туда куда нужно. Кроме того, web мастер в списке писем видит, что письма у него пришли от конкретных пользователей, а не от нашего сервиса.
Естественно я понимаю, что спамеры так же используют данную возможность и с этим нужно нещадно бороться.
На сколько я понимаю я нарушаю политику DMARC и письма блокируются справедливо.
Но мне то, что делать? Подскажите.
Да, Вы правы, «From» тоже подменяем, попробую подправить, может, что то получится.
писал на support@corp.mail.ru, там шлют ссылки на эту статью в том числе. Ни какой реальной помощи. А сервисом formm.ru пользуются более 3500 пользователей mail.ru почты.
Это не 1-2 и даже не 100 человек, можно проявить немного больше внимания, а в идиале в «белый список» внести. Или такого количества пользователей маловато для «белого списка»?
писал на support@corp.mail.ru, там шлют ссылки на эту статью в том числе. Ни какой реальной помощи. А сервисом formm.ru пользуются более 3500 пользователей mail.ru почты.
Это не 1-2 и даже не 100 человек, можно проявить немного больше внимания, а в идиале в «белый список» внести. Или такого количества пользователей маловато для «белого списка»?
Это и не форвардинг. Это услуга по пересылке сообщения от посетителя к владельцу сайта.
Услуга, кстати востребованная, есть даже платные аналоги.
Вы пишите в статье:
Вот наш сервис и есть «другие почтовые службы».
Кстати, блокировок стало меньше, но часть писем блокируется все равно:
From теперь правильный, что не так?
Услуга, кстати востребованная, есть даже платные аналоги.
Вы пишите в статье:
Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC.
Вот наш сервис и есть «другие почтовые службы».
Кстати, блокировок стало меньше, но часть писем блокируется все равно:
Action: failed
Status: 5.7.1
Remote-MTA: dns; mxs.mail.ru
Diagnostic-Code: smtp; 550 5.7.1 This message was not accepted due to domain
owner DMARC policy (RFC 7489)
From теперь правильный, что не так?
UFO just landed and posted this here
v=spf1 include:servers.mcsv.net redirect=_spf.mail.ru
Вы сломали нам рассылку. Спасибо!
Пожалуйста, но этой статье больше года и вряд ли политика DMARC домена mail.ru может влиять на вашу рассылку. Если ваша рассылка попадает под политики DMARC, значит вы ее неправильно делаете.
Что значит «врядли»? Именно она и влияет:
- с мейлру кто-то послал мейл
- мейл форварднулся мейлманом
- в нём поломались подписи
- мейл пришёл в гугл
- мейлру завещал такие емейлы с поломатыми подписями режектить
- гугл послушно мейл режектнул и послал баунс
- мейлман словил баунс, один, второй, третий…
- мейлман решил, что у гуглоюзера неверно сконфигурён сервер (перманентный режект), мейлман удалил гуглоюзера из рассылки
И так на каждый мейл из мейру.
О, да, есть решение: запретить мейлоюзеров, но хотелось бы без этого
Так запретите, только сразу запретите еще юзеров Yahoo, AOL и все крупные корпорации, т.к. у них тоже строгий DMARC, а с этого года придется запретить gmail, hotmail/outlook и Yandex, т.к. они тоже анонсировали внедрение строгого DMARC. В общем лучше вообще сразу всех запрещать, чтобы много раз в конфигурацию не лазить.
Или таки, как в mailman надо настроить dmarc_moderation_action с действием Munge From, но это как-то менее радикально, да еще и документацию читать надо.
Или таки, как в mailman надо настроить dmarc_moderation_action с действием Munge From, но это как-то менее радикально, да еще и документацию читать надо.
Sign up to leave a comment.
(Почему) Почта Mail.Ru включает строгий DMARC