Comments 98
Вам стоит приложить скриншот переписки с техподдержкой, раз уж такая реакция у представителей.
E-mail создавалось по образу и подобию аналога из реального мира. Вы так же можете подписать реальное письмо, от лица сбербанка например. Из-за того что Яндекс не принимает подобные письма вообще случаются проблемы. Например их почта для домена: при настраивании spf записи DNS необходимо указать ip-адрес хостинга, иначе яндекс не будет принимать письма с данного домена. Но этот параметр вынесен отдельно и в базовой инструкции не указан, в связи с чем бывали такие проблемы у некоторых клиентов.
Привет, я процитирую свой на этот репорт с HackerOne:
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
к сожалению, электронная почта действительно изначально не защищена от подделки адреса. Существует стандарт DMARC который позволяет защититься от подделки, но работает только на письмах соответствующих стандарту RFC 5322 и только для отправителей, настроивших политику DMARC. В настоящее время достаточно много писем не соответствует этому стандарту и проверить на них DMARC невозможно. Постепенно мы «закручиваем гайки» для нестандартных писем. Сейчас на таких письмах (и в некоторых других ситуациях) показывается уведомление о возможной подделке адреса, что видно на скриншоте, поэтому пользователь предупрежден и мы не считаем данную ситуацию ошибкой.
P.S. duma.gov.ru в принципе не публикует политику DMARC, поэтому защитить письма от этого домена от подделки стандартными средствами невозможно.
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
Вы грамотный человек, и всё правильно пишете. Однако (много раз уже это повторяю) у Яндекса таких проблем нет. Почему-то вышеописанные причины им не мешают.
Это вам так кажется. Яндекс запрещает конкретную комбинацию символов ">>", что никак не связано с безопасностью и не мешает обойти DMARC через другие варианты «неправильного» From, вот в таком случае, например, даже сообщения о подделке нет:
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.
А почему Яндекс исправил ошибку ">>", а вы нет?
Начинает складываться впечатление, что в этом месте (подделка отправителей) «дыра на дыре»…
Узнать бы мнение самого Яндекса :)
Начинает складываться впечатление, что в этом месте (подделка отправителей) «дыра на дыре»…
Узнать бы мнение самого Яндекса :)
Потому что это — не ошибка.
Угу, уровни компетенции на низком уровне падают. Люди уже не знают, как работает протокол SMTP, и, наверное, ни разу в жизни не отправляли почту telnet/openssl s_client.
Для современных разработчиков SMTP too low layer :(
И читать rfc по нему им не нужно. И правда — в том же питоне достаточно тыц-тыц, и вызвать одной строчкой из того или другого модуля, и не думать ни о чём.
Для современных разработчиков SMTP too low layer :(
И читать rfc по нему им не нужно. И правда — в том же питоне достаточно тыц-тыц, и вызвать одной строчкой из того или другого модуля, и не думать ни о чём.
Начали придираться к словам… :) Суть моего сообщения в том, что у одного сервиса эта «дыра» (подберите наиболее подходящее слово) закрыта (z3apa3a написал: «Яндекс запрещает конкретную комбинацию символов „>>“), а у другого — нет. Как выясняется дальше, у того же Яндекса есть другие уязвимости. А что мешает Мэйлу сделать „костыли“ пока невозможно решить проблему глобально и закрыть „конкретные комбинации символов“? Яндекс же, как мы видим, конкретно этот случай „запретил“.
И в результате куча народу с ящиками на яндексе получили головную боль, потому что им могут не прийти уведомления с сайтов о сделанном заказе и т.п.
Комбинация ">>" — это ведь явная ошибка в скрипте. По-моему, сервис (почтовый протокол, др.) и не должен обрабатывать «глючный» код. Это проблема автора скрипта, «пиши код правильно», «недопустимые символы».
Да, но, к сожалению, очень много скриптов имеют те или иные ошибки, даже у очень крупных компаний. Например, нам приходилось связываться с разработчиками iCloud по поводу некорректного формирования писем в их сервисе. Так что строгого соответствия стандартам сразу начать требовать нельзя. Правильно сформировать письмо не так просто, как кажется. А вот многие спамеры наоборот о почте знают больше чем большинство разработчиков приложений, решивших написать генерацию письма. Пока с такой сигнатурой идет нормальный трафик и не идет спам — он пропускается. Если с такой сигнатурой пойдет спам — она будет может быть блокирована или отправлена в спам.
Нет никаких придирок. Какой пункт RFC нарушен при отправке такого письма?
Ну вот опять… :) Комбинация ">>" у Яндекса «запрещена», у Мэйла нет. С другой стороны (как люди уже написали), у Яндекса есть другие «дыры», которые у Мэйла закрыты. Я не знаю, почему у одних сделано так, а других вот так. Может прямо сейчас исправляют, может недоглядели, а может ещё чего. На самом деле, я ещё в самом начале Владимиру Дубровину (@z3apa3a) написал, что возможно проблема в «почтовом протоколе», но когда увидел, что Яндекс такую подделку отправителя не пропускает, то начал задавать вопросы Мэйлу, мол, «а почему вы пропускаете?». И мне, честно, до сих пор непонятно, почему у один, а у других эдак. Может, это и не моё дело.
А зачем запрещать именно ">>"?
Допустим, запретили. Дальше:
— у пользователей начались внезапные нестыковки с интернет-магазинами
— отправитель фишинговых писем заметил, что они не приходят на тестовый ящик, и изменил ">>" на "<<".
Силы (деньги?) потрачены, обратная совместимость нарушена, негатив клиентам создан, дырка осталась. А в чем профит?
Допустим, запретили. Дальше:
— у пользователей начались внезапные нестыковки с интернет-магазинами
— отправитель фишинговых писем заметил, что они не приходят на тестовый ящик, и изменил ">>" на "<<".
Силы (деньги?) потрачены, обратная совместимость нарушена, негатив клиентам создан, дырка осталась. А в чем профит?
бегом спамить пользователей mail от имени банка))
А так бы конечно да, ответ mail'а бы выложить.
А так бы конечно да, ответ mail'а бы выложить.
В начале 2000ых помню была некая программа в интерфейсе которой в поле «от кого» можно было вписать все что угодно, при этом smtp сервер одного из популярных ныне почтовых сервисов был вообще без авторизации, то есть можно было слать что угодно и кому угодно. Столько лет прошло а воз и ныне там…
Это было на mail.ru. По smtp авторизация вообще не применялась, поэтому даже в outlook express можно было в адрес о правителя вписать кого угодно (с домена mail.ru). При этом письмо не "подделывалось" а действительно отправлялось с с аккаунта, подписанного в поле from.
Вообще-то, изначально, поле From != адресу отправителя, по стандарту (я могу путать детали, читал RFC давно).
Например, секретарша записывает письмо со слов начальника. В таком случае ей следует указать в поле From адрес начальника, тогда как она отправляет письмо со своего аккаунта, не имея доступа к аккаунту начальника. А вот адрес её аккаунта следует указывать в поле Sender.
Как уже упомянули не раз выше — проблема E-Mail в том, что он создавался очень давно (если не ошибаюсь, он старше того, что мы сейчас называем интернетом). Печатные письма в те времена тоже можно было легко подделать, особенно если их печатала секретарша на печатной машинке. Просто проблемы спама, а тем более массовой подделки в те времена не существовало.
Не совсем точно выразился. Сейчас если в поле «от кого» вписать какой-то адрес то в теле письма всё равно можно увидеть параметры оригинального отправителя т.к. сервер отправки сообщений требует авторизацию а раньше там максимум был виден IP адрес а вот т.к. авторизации не требовалось то изобличить реального отправителя было сложновато. Первое время мы с друзьями прикалывались так друг над другом, отправляя письма из военкомата\мвд и проч. :)
Можно. Но позволяет сейчас это далеко не каждый. Да и кто смотрит в исходник письма, если это обычная бухгалтерша?
Вполне точно, я говорил про заголовки самого письма, а не про то, что каждый SMTP сервер в цепочке добавляет свой заголовок к пакету, а не к самому письму (могу путать термины, но суть такая).
Ну а в современных условиях GMail суёт в мои письма адрес моего аккаунта в Sender принудительно, если он не равен From — вот это вот не по стандарту. (Или делал так какое-то время назад. Адреса в From, естественно, верифицированы для моего аккаунта.)
Впрочем, в большинстве клиентов отображение поля Sender даже отключено и почти никто не знает что это и зачем.
UPD: Похоже это я запутался в ответах, ну да и ладно.
Интересно, как они заговорят, если кто-то станет рассылать письма от имени mail.ru?
Еще у меня некоторые письма из приложения gmail на андроиде с ящика mail.ru не удаляются, всеми техподдержками был послан нафиг…
+ за выкладывание переписки с техподдержкой. Т.к. вполне себе повод переехать с мыла.ру
а вы еще задумываетесь?
Нет. С января 10-го года полет был нормальный, без проблем + интерфейс для моего восприятия предельно прост.
А куда? Серьезно спрашиваю.
На свои сервера
+1
Но требует квалификации.
это не самый хороший совет, точнее он хороший, но не для всех, именно из-за этого потом начинаются проблемы с доставкой писем от поставщиков/клиентов, потому что косорукие эникеи даже не подозревают о существовании SPF, DKIM и DMARC, ставят локалхост везде где можно, обратный адес не резолвится, и даже встречался с тем что msgid одинаковый во всех письмах от них и любой нормальный сервер это просто зарезает как дублированное письмо
protonmail,
свой сервер
свой сервер
2 месяца назад тоже экспериментировал с такими подделываниями. Но mail.ru не пропустил ни одного письма. Тут пишут что пропустил. Кому верить?
Была статья с похожей ситуацией на Хабре: Подделываем письма от крупнейших российских банков. Правда, там не про Mail.ru, а про банки.
Выскажусь как автор той статьи. Защита от подделки писем должна происходить с двух сторон: владельца сервиса и получателя письма (в большинстве случаев это почтовый провайдер, например Mail.ru).
К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.
Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса.
В тему писем: хотелось бы спросить z3apa3a, почему нужно использовать DMARC (за исключением защиты поддоменов). Часто получаю ответы от разных сервисов вида «Мы публикуем SPF-запись, почтовые провайдеры должны сами проверять запись и отправлять в спам письмо с „~“ и не принимать с „-“, этого достаточно». Буду благодарен за ответ.
К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.
Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса.
В тему писем: хотелось бы спросить z3apa3a, почему нужно использовать DMARC (за исключением защиты поддоменов). Часто получаю ответы от разных сервисов вида «Мы публикуем SPF-запись, почтовые провайдеры должны сами проверять запись и отправлять в спам письмо с „~“ и не принимать с „-“, этого достаточно». Буду благодарен за ответ.
SPF изначально предназначался для другого: чтобы забыть про репутации IP-адресов, черные списки, проверки PTR-записей и т.д. и т.п. и вместо них авторизовать по SPF домен почтового сервера и хранить репутацию по почтовым доменам вместо IP, а от всяких странных IP-адресов почту не принимать в принципе, и соответственно избавиться от спама. Этого не случилось, т.к. для этого необходимо чтобы SPF реализовали все.
Соответственно, SPF не защищает письма от подделки. Совсем. SPF это протокол аутентификации почтового сервера на уровне транспорта (SMTP), он вобще не смотрит в содержимое письма и в поле From: в частности. Например, домен bob.com имеет строгую SPF-политику. У атакующего есть домен alice.org, который он контролирует. Атакующий может отправить письмо
и письмо успешно пройдет SPF-аутентификацию, т.к. SPF проверяет адрес конверта (m@alice.org), но получатель увидит содержимое From:, т.е. g@bob.com.
Соответственно, SPF не защищает письма от подделки. Совсем. SPF это протокол аутентификации почтового сервера на уровне транспорта (SMTP), он вобще не смотрит в содержимое письма и в поле From: в частности. Например, домен bob.com имеет строгую SPF-политику. У атакующего есть домен alice.org, который он контролирует. Атакующий может отправить письмо
EHLO alice.org
MAIL FROM: <m@alice.org>
RCPT TO: <some@example.com>
DATA
From: <g@bob.com>
Subject: hello
hello
.
и письмо успешно пройдет SPF-аутентификацию, т.к. SPF проверяет адрес конверта (m@alice.org), но получатель увидит содержимое From:, т.е. g@bob.com.
Дополню — аналогичная проблема у DKIM.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
Соглашусь.
На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.
Различие адреса конверта и From не является чем-то запрещенным, тем более нарушением стандарта. А вот такая блокировка это не просто нарушение стандарта, она зарежет все не личные письма, т.к. во всех автоматических письмах (включая письма о восстановлениях эккаунтах и т.п.) адрес конверта устанавливается как правило в какой-нибудь специальный обработчик, т.к. на него падают сообщения о невозможности доставки, и адрес конверта и From не просто отличается, но зачастую вообще из другого домена.
Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.
Проверил, работает. Кажется, кто-то лишится премии, как минимум )
А почему бы не брать From из текущей сессии, из текущего авторизованного пользователя, и вообще не обрабатывать его через хидеры? Ибо он попросту не нужен будет? Или я что-то не понял?..
Проблема есть и у Яндекса. И она намного хуже. https://geektimes.ru/post/291939/
Это мелочи жизни.
Меня больше напрягает, что майл позволяет отправлять со своей почты опасные вложения, exe com js и прочие.
Эти вложения давно считаются опасными и блокируются гуглом и яндексом, а вот майл почему то принципиально не хотят блокировать эти вложения.
Опишу суть проблемы:
майл говорит что вся почта (и облако) проверяется на вирусы, однако все прекрасно понимают, прежде чем запустить новый вирус его проверяют, проверяют в том числе и антивирусником который проверяет почту на майл ру.
На моем почтовом сервере настроена блокировка подобных вложений, с отчетами о блокировках. По моей личной статистике 90% всех почтовых вирусов отправляются именно с майл.ру. Вот это действительно проблема.
По этим же соображениям приходится выдавать доступ к облаку майл.ру «по талонам», с предварительной ручной проверкой скачиваемых файлов (благо таких запросов в месяц не более 5).
Меня больше напрягает, что майл позволяет отправлять со своей почты опасные вложения, exe com js и прочие.
Эти вложения давно считаются опасными и блокируются гуглом и яндексом, а вот майл почему то принципиально не хотят блокировать эти вложения.
Опишу суть проблемы:
майл говорит что вся почта (и облако) проверяется на вирусы, однако все прекрасно понимают, прежде чем запустить новый вирус его проверяют, проверяют в том числе и антивирусником который проверяет почту на майл ру.
На моем почтовом сервере настроена блокировка подобных вложений, с отчетами о блокировках. По моей личной статистике 90% всех почтовых вирусов отправляются именно с майл.ру. Вот это действительно проблема.
По этим же соображениям приходится выдавать доступ к облаку майл.ру «по талонам», с предварительной ручной проверкой скачиваемых файлов (благо таких запросов в месяц не более 5).
А меня например напрягает, что я не могу отправить некоторые файлы без плясок с архиватором.
Хочешь защитить пользователя — запрети ему получать *.exe и прочие исполняемые файлы.
Хочешь защитить пользователя — запрети ему получать *.exe и прочие исполняемые файлы.
а ещё Office документы надо запретить — там есть макросы!
и прочие обычные данные (картинки, тексты и т. д.) — вики
и прочие обычные данные (картинки, тексты и т. д.) — вики
Еще один все понял.
А раньше еще была такая дичь как открытые релеи.
http://www.antispam.ru/sh?act=msg&id=1033474961
https://en.wikipedia.org/wiki/Open_mail_relay
А раньше еще была такая дичь как открытые релеи.
http://www.antispam.ru/sh?act=msg&id=1033474961
https://en.wikipedia.org/wiki/Open_mail_relay
Господи, неужели каждый узнавший, как работает электронная почта, будет сюда про это писать???
Господи, неужели каждый, узнавший что это хабр, будет этим возмущаться?
Да, такой вот он сейчас /sarcazm
Да, такой вот он сейчас /sarcazm
Господи, неужели каждый, кто получил доступ к комментированию не через песочницу (внес хоть какой-то полезный вклад сообщество Хабра), будет так говорить? Безусловно, у Хабра есть свои проблемы, но он создается сообществом. Человеку нашел ошибку, да, это не стандарт, да не критично (хотя спорно), да, очевидно. Но это может привнести хоть какой-то вклад в безопасность, т.к. это обратит еще раз внимание к проблеме замене стандартов на более безопасные.
Взгляд привлечен уже очень давно. Проблема с безопасностью почты в том, что значимое количество почтовых серверов (в смысле инстансов, а не программ) стандартов безопасности не поддерживают и не собираются в силу различных причин. И у остальных остается только один вариант — следовать стандартам. Я вас уверяю, 15 лет назад, когда подход в массе был другим: «Я буду делать так, пускай это не по RFC, но на мой взгляд так секурнее и пошли все остальные нафиг» было намного хуже. Админ почтового сервиса никогда не знал заранее дойдет ли e-mail в конкретный домен и чего именно там решили проверять и без чего молча дропать сессии…
Поэтому рассказывать про проблемы безопасности mail.ru, следующей RFC, на мой взгляд, несколько желтушно, мягко говоря.
Поэтому рассказывать про проблемы безопасности mail.ru, следующей RFC, на мой взгляд, несколько желтушно, мягко говоря.
Сообществом авторов статей в стиле «как я включил компьютер и что из этого получилось»?
Ну — вариант.
А стандарты — как вам сказать… Ну настроил какой-то студент в своем первом в жизни постфиксе проверку обратной зоны DNS домена отправителя (по стандартам и/или книгам начала 70-х) — и потом жалуется в хабр, что к нему почта не ходит.
Такой вот вклад в безопасность, ага.
Ну — вариант.
А стандарты — как вам сказать… Ну настроил какой-то студент в своем первом в жизни постфиксе проверку обратной зоны DNS домена отправителя (по стандартам и/или книгам начала 70-х) — и потом жалуется в хабр, что к нему почта не ходит.
Такой вот вклад в безопасность, ага.
Здесь я проверил совсем свежую статью про Яндекс, там автор, вероятно использовал дебаг шлюз Яндекса, с доступом по карточкам. Интересно, стоит ли регистрироваться в мейле и проверить правдивость статьи?
Для проверки авторизация проходила по публичному яндексовскому smtp.yandex.ru.
Проблема актуальная. Воспроизведение через thunderbird работает.
Проблема актуальная. Воспроизведение через thunderbird работает.
Вот зачем пользоваться унылым сервисом от мыла, если есть адекватные google и yandex? Мэйл ведь ничего внутри для улучшения работы своей почты не делает, только морду слизывает с конкурентов.
Основная почта на gmail. Не хватает:
— адекватных фильтров
— правил
— папок
У мейла, в свою очередь, безумно очевидные вещи в фильтрах вроде «удалить и послать сообщение о несуществующем адресе», чтоб с большей вероятностью убраться из списка рассылки.
По теме статьи: очень грустно, что некоторые люди пишут про «кто-то лишится премии», имея в виду особенность, обсуждаемую с момента распространения smtp.
— адекватных фильтров
— правил
— папок
У мейла, в свою очередь, безумно очевидные вещи в фильтрах вроде «удалить и послать сообщение о несуществующем адресе», чтоб с большей вероятностью убраться из списка рассылки.
По теме статьи: очень грустно, что некоторые люди пишут про «кто-то лишится премии», имея в виду особенность, обсуждаемую с момента распространения smtp.
Папок нет, но есть ярлыки, при умелом расставлении суть та же самая. Тоже самое касается и фильтров, и правил. Тут в общем-то, если умеете пользоваться gmail, то проблем нет, если нет, то, конечно, можно пользоваться унылым мылом.
У ярлыков суть не та же самая, потому что я привык следовать правилу 0 inbox и в нормально огранизованной почте у меня под 40 папок, некоторые вложены друг в друга. Ярлыки, насколько я помню, друг в друга не вкладываются, но даже если и да — в Inbox всё равно показываются все письма, включая те, что с ярлыками.
Ей-Богу, намеренно баг этот юзаю уже несколько лет, неужели о нём никто не знал?
Это не баг, это стандартная работа электронной почты.
Протокол позволяет что угодно писать в обратный адрес и в имя отправителя.
А проверять и доверять это уже надо на стороне получателя.
Много лет уже работает у меня рассылка по договорам от имени ответственных инженеров. И вот как раз проблемы с теми кто свой сервер настроил проверять обратный адрес и адрес реального отправителя.
Это не добавляет оптимизма.
А вы обратили внимание что у них пропал крестик для закрытия письма!
Тех поддержка заявила что **** и что там его никогда не было!
Я им посоветовал воспользоваться поиском, и посмотреть как закрывать письмо, не потеряв поиск.
Меня просто послали…
Тех поддержка заявила что **** и что там его никогда не было!
Я им посоветовал воспользоваться поиском, и посмотреть как закрывать письмо, не потеряв поиск.
Меня просто послали…
UFO just landed and posted this here
Ну вот серые списки — это то, что точно нужно искоренять. Особенно если оно сделаны по-рамблеровски, т.е. когда от тебя с первого раза не примут почту, даже если ты ее с этого IP этому же получателю уже не первый год шлешь.
Особенно вера то, что в интернете есть стандарты, и все почтовики им следуют, напрягает, когда очередной горе-админ настроит у себя серый список, не напишет в возвращаемом сообщении логику его работы, а тебе срочно на тот домен нужно важное письмо отправить. Способа нет, кроме как отказаться от отправки письма, и отправить человеку на нормальный сервис (тот же, да, mail или gmail). Хотя кто мешает написать в возвращаемом тексте «Your message is graylisted, please be back in 5 minutes to try again»?
Со стандартами вот какая история: RFC — это requests, это просьбы написать замечания. Да, их считают стандартами, но за их нарушения крайне трудно наказать, так что назовем их «рекомендациями». В частности, хотя коды 4xx говорят почтовикам попробовать через некоторое время, никто не гарантирует отправку через это время. Более того, если у меня на отправку стоит правило пробовать отправить через полчаса, затем с увеличением интервала в 3 раза, но не более 5 часов, то мой почтовик попробует: 0.5 часа, 1.5 часа, 4.5 часа, все — три раза. Это нормально, и это та логика, которую я на своем конце запрограммировал.
Если на стороне приемапионер мудрый админ, не ценящий время доставки (меньше будут слать — мне меньше работы) настроит, что после отпинывания первого сообщения нужно ждать 62 минуты, а каждая новая попытка сбрасывает таймер опять на 59 минут, то получаем: 0 (отказ), 0.5 (отказ, сброс), 1.5 часа (отказ, сброс), 4.5 часа (может примет, если оно у меня не отправляется через другой сервер из пула MX-ов) — бинго, важное письмо через 5 часов отдается отправителю со словами «получатель не смог принять его».
Что там у mail, не знаю. У них кластер на отправку, вероятно, велик, и очередь разгребается хитрее, чем можно подумать. Какие-то сроки перепопыток гарантировать они не будут, да и незачем им (в RFC ничего такого не написано), а как mail подстроиться к каждому админу страны?
Черные списки, кстати, та еще штука — они ни за что не отвечают, просто отвечают, кого они считают редиской. Это уже вопрос к принимающему серверу, смотреть ли в них, верить ли им, и насколько верить. И крупные игроки вполне могут сказать: раз адрес сервера у нас ресолвится в *.google.com (грубо), или в *.mail.ru, то вы уж сами решайте, будете вы такие IP проверять по вашим спискам.
Я к тому, что крупные почтовые провайдеры предпринимают разумные меры к доставке почты, но они скорее нужны мелким почтовикам, что мелкие почтовики — им.
Особенно вера то, что в интернете есть стандарты, и все почтовики им следуют, напрягает, когда очередной горе-админ настроит у себя серый список, не напишет в возвращаемом сообщении логику его работы, а тебе срочно на тот домен нужно важное письмо отправить. Способа нет, кроме как отказаться от отправки письма, и отправить человеку на нормальный сервис (тот же, да, mail или gmail). Хотя кто мешает написать в возвращаемом тексте «Your message is graylisted, please be back in 5 minutes to try again»?
Со стандартами вот какая история: RFC — это requests, это просьбы написать замечания. Да, их считают стандартами, но за их нарушения крайне трудно наказать, так что назовем их «рекомендациями». В частности, хотя коды 4xx говорят почтовикам попробовать через некоторое время, никто не гарантирует отправку через это время. Более того, если у меня на отправку стоит правило пробовать отправить через полчаса, затем с увеличением интервала в 3 раза, но не более 5 часов, то мой почтовик попробует: 0.5 часа, 1.5 часа, 4.5 часа, все — три раза. Это нормально, и это та логика, которую я на своем конце запрограммировал.
Если на стороне приема
Что там у mail, не знаю. У них кластер на отправку, вероятно, велик, и очередь разгребается хитрее, чем можно подумать. Какие-то сроки перепопыток гарантировать они не будут, да и незачем им (в RFC ничего такого не написано), а как mail подстроиться к каждому админу страны?
Черные списки, кстати, та еще штука — они ни за что не отвечают, просто отвечают, кого они считают редиской. Это уже вопрос к принимающему серверу, смотреть ли в них, верить ли им, и насколько верить. И крупные игроки вполне могут сказать: раз адрес сервера у нас ресолвится в *.google.com (грубо), или в *.mail.ru, то вы уж сами решайте, будете вы такие IP проверять по вашим спискам.
Я к тому, что крупные почтовые провайдеры предпринимают разумные меры к доставке почты, но они скорее нужны мелким почтовикам, что мелкие почтовики — им.
UFO just landed and posted this here
Ага. Щаз. Искореню.
У mail.ru логика топорно проста «не нравится — не пользуйся». Именно поэтому они на RFC кладут такой преогромный железобетонный.
Так чем Вы лучше их? Их система работает так, как работает (мы бы с Вами, подозреваю, не факт что построили бы лучше, с учетом масштаба), и — работает. Вы ссылаетесь на RFC, которые сделаны для доставки почты, а не для ее отбивания, не выполняете их дух (потому что доставку постоянно обеспечиваете не с первого раза), но недовольны, что кто-то еще что-то там нарушает?
Напоминает "- Смотри, чувак идет, пойдем его побьем? — Да он здоровый, еще нас поколотит! — А нас-то за что?"
Я понимаю смысл от greylisting, если он изучает переписку человека, и не задерживает почту от того же человека, с того же IP-адреса больше одного раза. Тогда и задержка для «своих» не видна, и спам вроде как бьется.
Кстати, если про черные списки, вы видели у них такое поведение: если с одного адреса много спама, то в список добавляется /24 вокруг адреса, если продолжается, то /23 и так далее, до размера route-object порой. Все алгоритмически хорошо, но это как «в вашей школе учится драчун, постоянно колотит окрестных ребят, мы посадили в тюрьму всех учеников школы, а заодно и всех детей района проживания драчуна». На все вопрос ответ один — «мы ни за что не отвечаем, хотите — пользуйтесь».
Эти всякие почты нужны только для активации аккаунтов.
Sign up to leave a comment.
Проблемы безопасности почты Mail.ru