Сейчас редирект не будет работать только в такой ситуации: есть user1@mail.ru с него письма редиректятся в user@company.ru а с него обратно на mail.ru, например в user2@mail.ru и при этом кто-то из пользователей mail.ru, например user3@mail.ru будет писать на user1@mail.ru. Попросите пользователей избегать двойных редиректов между разными сервисами.
Могу еще порекомендовать воспользоваться biz.mail.ru, это снимет большую часть проблем.
Если в какой-то другой ситуации возникают проблемы — перешлите полный текст сообщения о невозможности доставки, я разберусь.
Да, существует. Если не использовать адрес пользователя в поле From:, а использовать адрес вашего домена, для которого вы прописали SPF и DKIM — то письма будут уходить.
Про адрес знаем, поменяем.
«Человекочетамость» для XML не подразумевалась, она увеличит отчеты примерно на 15-20%, а по некоторым доменам они уже превышают 500 мегабайт. Насколько это действительно требуется? Можно открыть отчет в браузере, например FF или пользоваться DMARC XML-to-Human Converter.
Вы как-то ограничиваете/следите за спамом рассылаемым с хостинговых сервисов? Если у вас есть выделенная сеть, можно подписаться на FBL
http://fbl.postmaster.appsmail.ru/
и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.
DMARC не затрагивает хостеров. С трудностями могут столкнуться некоторые ваши клиенты, это может привести к обращению в службу поддержки, но обращение в данном случае легко конвертируется в продажу услуги — хостинга для почтового домена, доработки серверных скриптов.
У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.
Нет, скорей это связано с «засвеченностью» ящика — чем дольше живет адрес электронной почты, тем больше спама на него идет. В целом объем спама последние годы достаточно стабилен, а объем спама доходящего до инбокса снижается. Не забывайте нажимать кнопку «Спам» — она не просто переносит письмо в соответствующую папку, она отписывает вас от рассылки, помогает категоризировать рассылку и сделать так, чтобы похожие письма не доходили вам и другим пользователям и шлет жалобы администраторам сетей / сервисов рассылок о том, что клиент нарушает правила рассылок.
Если про отсутствие авторизации почты — то прошло не только 10, но и 25 лет, а если про внедрение DMARC — то работа над ним началась в 2012-2013 годах, стандартом он стал в 2015, Mail.Ru поддерживает DMARC с 2014го.
Не надо присваивать одинаковый — вполне допустимо чтобы он был разный, но для каждого имени используемого в 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.
Если у вас два подключения к двум провайдерам — заведите на почтовый сервер IP адреса от обоих провайдеров (напрямую или через проброс/трансляцию порта), опубликуйте две MX-записи, с разными приоритетами, если какой-то из провайдеров предпочтительней или с одинаковыми, если они равнозначны. В SPF запись включите все IP адреса всех серверов. Если один из провайдеров не предоставляет PTR-записи — избегайте использовать выделенный им IP адрес для отправки почты. Для этого, например, добавляйте маршрут через него на почтовом сервере с большей метрикой. Для входящей почты наличие PTR значения не имеет.
Нет, DMARC здесь непричем, он не влияет напрямую ни на объем спама в вашем ящике ни на прохождение обычных писем. Если какие-то письма попадают в папку спам — не забывайте нажимать на них «Не спам», это гарантирует, что в дальнейшем письма от данного отправителя в спам не попадут. Если проблема повторяется — обратитесь в службу поддержки, мы обязательно выявим и устраним причину.
PTR никак не связан с SPF, кроме случаев, когда в SPF применяется конструкция типа ptr:mail.example.com, но многие серверы проверяют PTR, поэтому он должен:
1. быть
2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.
Отчасти да, именно поэтому мы внедряем p=reject.
Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.
Могу еще порекомендовать воспользоваться biz.mail.ru, это снимет большую часть проблем.
Если в какой-то другой ситуации возникают проблемы — перешлите полный текст сообщения о невозможности доставки, я разберусь.
«Человекочетамость» для XML не подразумевалась, она увеличит отчеты примерно на 15-20%, а по некоторым доменам они уже превышают 500 мегабайт. Насколько это действительно требуется? Можно открыть отчет в браузере, например FF или пользоваться
DMARC XML-to-Human Converter.
http://fbl.postmaster.appsmail.ru/
и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.
У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.
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"
Для прохождения 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.
1. быть
2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.
Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.