Исходный код:
$email = $_POST['email'];
$headers .= "From: " . $email . "\r\n";А не так давно заметил, что заявки перестали приходить… Проверил форму — не работает. Вызвало недоумение, ибо никто ничего не трогал, и два года всё работало нормально. По ходу экспериментов выяснилось, что если использовать такой код:
$email = "Сбербанк <help@sberbank.ru";
$headers .= "From: " . $email . ">>\r\n";то можно совершенно спокойно подделывать любого отправителя (в данном случае Сбербанк).
Письма приходят во входящие. Как спам определяются не с первого раза. В интерфейсе Mail.ru пишется «Мы не можем проверить подлинность отправителя», однако если вы собираете почту с помощью программы (например, Outlook), то там никакой надписи, естественно, нет.
Ключевое место — дополнительный символ ">". Без этого символа письма с подделанным отправителем, как и положено, НЕ приходят. Очевидно, у почты Mail.ru ошибка в обработке заголовков «headers».
Проверял этот баг на Яндексе. У Яндекса такой проблемы нет (письма с подделанным отправителем не пропускает даже в папку «спам»).
P.S. Представитель Mail.ru сказал «мы не считаем данную ситуацияю ошибкой» (цитата точная), поэтому выкладываю эту информацию с чистой совестью.
Комментарии (99)
mironoffe
10.08.2017 15:09+4E-mail создавалось по образу и подобию аналога из реального мира. Вы так же можете подписать реальное письмо, от лица сбербанка например. Из-за того что Яндекс не принимает подобные письма вообще случаются проблемы. Например их почта для домена: при настраивании spf записи DNS необходимо указать ip-адрес хостинга, иначе яндекс не будет принимать письма с данного домена. Но этот параметр вынесен отдельно и в базовой инструкции не указан, в связи с чем бывали такие проблемы у некоторых клиентов.
Scorry
11.08.2017 10:19+1Из-за того что Яндекс не принимает подобные письма...
Не «из-за того что», а «потому что». Яндекс хоть стандарты соблюдает, в отличие от.
z3apa3a
10.08.2017 15:17+13Привет, я процитирую свой на этот репорт с HackerOne:
к сожалению, электронная почта действительно изначально не защищена от подделки адреса. Существует стандарт DMARC который позволяет защититься от подделки, но работает только на письмах соответствующих стандарту RFC 5322 и только для отправителей, настроивших политику DMARC. В настоящее время достаточно много писем не соответствует этому стандарту и проверить на них DMARC невозможно. Постепенно мы «закручиваем гайки» для нестандартных писем. Сейчас на таких письмах (и в некоторых других ситуациях) показывается уведомление о возможной подделке адреса, что видно на скриншоте, поэтому пользователь предупрежден и мы не считаем данную ситуацию ошибкой.
P.S. duma.gov.ru в принципе не публикует политику DMARC, поэтому защитить письма от этого домена от подделки стандартными средствами невозможно.
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.MikhailNsk Автор
10.08.2017 16:40-1Вы грамотный человек, и всё правильно пишете. Однако (много раз уже это повторяю) у Яндекса таких проблем нет. Почему-то вышеописанные причины им не мешают.
z3apa3a
10.08.2017 17:17+14Это вам так кажется. Яндекс запрещает конкретную комбинацию символов ">>", что никак не связано с безопасностью и не мешает обойти DMARC через другие варианты «неправильного» From, вот в таком случае, например, даже сообщения о подделке нет:
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.MikhailNsk Автор
10.08.2017 17:33-16А почему Яндекс исправил ошибку ">>", а вы нет?
Начинает складываться впечатление, что в этом месте (подделка отправителей) «дыра на дыре»…
Узнать бы мнение самого Яндекса :)buglife
10.08.2017 21:19+8Потому что это — не ошибка.
sHaggY_caT
10.08.2017 21:43+9Угу, уровни компетенции на низком уровне падают. Люди уже не знают, как работает протокол SMTP, и, наверное, ни разу в жизни не отправляли почту telnet/openssl s_client.
Для современных разработчиков SMTP too low layer :(
И читать rfc по нему им не нужно. И правда — в том же питоне достаточно тыц-тыц, и вызвать одной строчкой из того или другого модуля, и не думать ни о чём.buglife
10.08.2017 22:02Вот эти 3 строчки в exim стоили 3 часа времени.
# Deny all Mailer-Daemon messages not for us:
deny message = We didn't send the message
senders =:
domains = !+relay_domains
я просто не мог допустить, что такое «емкое сообщение» может выдавать exim.
MikhailNsk Автор
11.08.2017 07:01-1Начали придираться к словам… :) Суть моего сообщения в том, что у одного сервиса эта «дыра» (подберите наиболее подходящее слово) закрыта (z3apa3a написал: «Яндекс запрещает конкретную комбинацию символов „>>“), а у другого — нет. Как выясняется дальше, у того же Яндекса есть другие уязвимости. А что мешает Мэйлу сделать „костыли“ пока невозможно решить проблему глобально и закрыть „конкретные комбинации символов“? Яндекс же, как мы видим, конкретно этот случай „запретил“.
hssergey
11.08.2017 08:42-1И в результате куча народу с ящиками на яндексе получили головную боль, потому что им могут не прийти уведомления с сайтов о сделанном заказе и т.п.
MikhailNsk Автор
11.08.2017 09:22+2Комбинация ">>" — это ведь явная ошибка в скрипте. По-моему, сервис (почтовый протокол, др.) и не должен обрабатывать «глючный» код. Это проблема автора скрипта, «пиши код правильно», «недопустимые символы».
z3apa3a
11.08.2017 14:44Да, но, к сожалению, очень много скриптов имеют те или иные ошибки, даже у очень крупных компаний. Например, нам приходилось связываться с разработчиками iCloud по поводу некорректного формирования писем в их сервисе. Так что строгого соответствия стандартам сразу начать требовать нельзя. Правильно сформировать письмо не так просто, как кажется. А вот многие спамеры наоборот о почте знают больше чем большинство разработчиков приложений, решивших написать генерацию письма. Пока с такой сигнатурой идет нормальный трафик и не идет спам — он пропускается. Если с такой сигнатурой пойдет спам — она будет может быть блокирована или отправлена в спам.
buglife
11.08.2017 10:00Нет никаких придирок. Какой пункт RFC нарушен при отправке такого письма?
MikhailNsk Автор
11.08.2017 10:18-1Ну вот опять… :) Комбинация ">>" у Яндекса «запрещена», у Мэйла нет. С другой стороны (как люди уже написали), у Яндекса есть другие «дыры», которые у Мэйла закрыты. Я не знаю, почему у одних сделано так, а других вот так. Может прямо сейчас исправляют, может недоглядели, а может ещё чего. На самом деле, я ещё в самом начале Владимиру Дубровину (@z3apa3a) написал, что возможно проблема в «почтовом протоколе», но когда увидел, что Яндекс такую подделку отправителя не пропускает, то начал задавать вопросы Мэйлу, мол, «а почему вы пропускаете?». И мне, честно, до сих пор непонятно, почему у один, а у других эдак. Может, это и не моё дело.
buglife
11.08.2017 10:30+4В данной ситуации, значит дыра у яндекса, так как они работают не по стандарту почты.
4eyes
11.08.2017 14:46А зачем запрещать именно ">>"?
Допустим, запретили. Дальше:
— у пользователей начались внезапные нестыковки с интернет-магазинами
— отправитель фишинговых писем заметил, что они не приходят на тестовый ящик, и изменил ">>" на "<<".
Силы (деньги?) потрачены, обратная совместимость нарушена, негатив клиентам создан, дырка осталась. А в чем профит?
ragermes
10.08.2017 16:07-2бегом спамить пользователей mail от имени банка))
А так бы конечно да, ответ mail'а бы выложить.
plastilinko
10.08.2017 16:07В начале 2000ых помню была некая программа в интерфейсе которой в поле «от кого» можно было вписать все что угодно, при этом smtp сервер одного из популярных ныне почтовых сервисов был вообще без авторизации, то есть можно было слать что угодно и кому угодно. Столько лет прошло а воз и ныне там…
Vellenkrat
10.08.2017 16:20+1Это было на mail.ru. По smtp авторизация вообще не применялась, поэтому даже в outlook express можно было в адрес о правителя вписать кого угодно (с домена mail.ru). При этом письмо не "подделывалось" а действительно отправлялось с с аккаунта, подписанного в поле from.
ikle
11.08.2017 09:13+1Вообще-то, изначально, поле From != адресу отправителя, по стандарту (я могу путать детали, читал RFC давно).
Например, секретарша записывает письмо со слов начальника. В таком случае ей следует указать в поле From адрес начальника, тогда как она отправляет письмо со своего аккаунта, не имея доступа к аккаунту начальника. А вот адрес её аккаунта следует указывать в поле Sender.
Как уже упомянули не раз выше — проблема E-Mail в том, что он создавался очень давно (если не ошибаюсь, он старше того, что мы сейчас называем интернетом). Печатные письма в те времена тоже можно было легко подделать, особенно если их печатала секретарша на печатной машинке. Просто проблемы спама, а тем более массовой подделки в те времена не существовало.
plastilinko
11.08.2017 09:22Не совсем точно выразился. Сейчас если в поле «от кого» вписать какой-то адрес то в теле письма всё равно можно увидеть параметры оригинального отправителя т.к. сервер отправки сообщений требует авторизацию а раньше там максимум был виден IP адрес а вот т.к. авторизации не требовалось то изобличить реального отправителя было сложновато. Первое время мы с друзьями прикалывались так друг над другом, отправляя письма из военкомата\мвд и проч. :)
tech42
11.08.2017 09:24Можно. Но позволяет сейчас это далеко не каждый. Да и кто смотрит в исходник письма, если это обычная бухгалтерша?
plastilinko
11.08.2017 10:02Вот с этого все и начинается обычно. Сначала не смотрят а потом приходит злобный петя и пожирает все годы наработок :)
ikle
11.08.2017 09:44Вполне точно, я говорил про заголовки самого письма, а не про то, что каждый SMTP сервер в цепочке добавляет свой заголовок к пакету, а не к самому письму (могу путать термины, но суть такая).
Ну а в современных условиях GMail суёт в мои письма адрес моего аккаунта в Sender принудительно, если он не равен From — вот это вот не по стандарту. (Или делал так какое-то время назад. Адреса в From, естественно, верифицированы для моего аккаунта.)
Впрочем, в большинстве клиентов отображение поля Sender даже отключено и почти никто не знает что это и зачем.
UPD: Похоже это я запутался в ответах, ну да и ладно.
Alozar
10.08.2017 16:07-7Интересно, как они заговорят, если кто-то станет рассылать письма от имени mail.ru?
Fragster
10.08.2017 16:30Еще у меня некоторые письма из приложения gmail на андроиде с ящика mail.ru не удаляются, всеми техподдержками был послан нафиг…
murzik_a
10.08.2017 16:41+1+ за выкладывание переписки с техподдержкой. Т.к. вполне себе повод переехать с мыла.ру
krimtsev
10.08.2017 17:00-4а вы еще задумываетесь?
murzik_a
10.08.2017 18:04Нет. С января 10-го года полет был нормальный, без проблем + интерфейс для моего восприятия предельно прост.
yoshitoshi
11.08.2017 02:03+5Я перестал пользоваться мейлру, когда в далеком 2006-м однажды утром обнаружил в папке "входящие" письма, которые я удалил 1-2 года назад. Вот просто так, взяли и появились.
Gmail тогда ещё был по приглашениям, счастливым обладателем которого я тогда и стал.
dmitry_ch
11.08.2017 01:05А куда? Серьезно спрашиваю.
krimtsev
11.08.2017 01:08На свои сервера
MegaShIzoID
11.08.2017 06:49+2это не самый хороший совет, точнее он хороший, но не для всех, именно из-за этого потом начинаются проблемы с доставкой писем от поставщиков/клиентов, потому что косорукие эникеи даже не подозревают о существовании SPF, DKIM и DMARC, ставят локалхост везде где можно, обратный адес не резолвится, и даже встречался с тем что msgid одинаковый во всех письмах от них и любой нормальный сервер это просто зарезает как дублированное письмо
Scorry
15.08.2017 09:52Криво- и косорукость админа — повод не нанимать его на работу, но никак не повод отказываться от хостинга своей почты на своих же мощностях.
iVNEi
10.08.2017 17:092 месяца назад тоже экспериментировал с такими подделываниями. Но mail.ru не пропустил ни одного письма. Тут пишут что пропустил. Кому верить?
MikhailNsk Автор
10.08.2017 17:12-3Можешь проверить лично. Ключевое место указал. Скрипт самый обычный. Но если нужно, могу скинуть исходники (php-скрипт + html-форма).
izzholtik
10.08.2017 20:04+12Пропускают все, даже гугл, но до первой жалобы на спам.
Статья — чистой воды спекуляция на неграмотности читателя. Проблема не на стороне mail.ru, это нормальное (хоть и несколько спорное) поведение любого почтового сервера.
Gorodnya
10.08.2017 17:10+1Была статья с похожей ситуацией на Хабре: Подделываем письма от крупнейших российских банков. Правда, там не про Mail.ru, а про банки.
pyrk2142
10.08.2017 19:42Выскажусь как автор той статьи. Защита от подделки писем должна происходить с двух сторон: владельца сервиса и получателя письма (в большинстве случаев это почтовый провайдер, например Mail.ru).
К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.
Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса.
В тему писем: хотелось бы спросить z3apa3a, почему нужно использовать DMARC (за исключением защиты поддоменов). Часто получаю ответы от разных сервисов вида «Мы публикуем SPF-запись, почтовые провайдеры должны сами проверять запись и отправлять в спам письмо с „~“ и не принимать с „-“, этого достаточно». Буду благодарен за ответ.z3apa3a
10.08.2017 22:42+2SPF изначально предназначался для другого: чтобы забыть про репутации IP-адресов, черные списки, проверки PTR-записей и т.д. и т.п. и вместо них авторизовать по SPF домен почтового сервера и хранить репутацию по почтовым доменам вместо IP, а от всяких странных IP-адресов почту не принимать в принципе, и соответственно избавиться от спама. Этого не случилось, т.к. для этого необходимо чтобы SPF реализовали все.
Соответственно, 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.
z3apa3a
10.08.2017 22:54+2Дополню — аналогичная проблема у DKIM.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
mxms
11.08.2017 01:36Соглашусь.
На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.z3apa3a
11.08.2017 01:50Различие адреса конверта и From не является чем-то запрещенным, тем более нарушением стандарта. А вот такая блокировка это не просто нарушение стандарта, она зарежет все не личные письма, т.к. во всех автоматических письмах (включая письма о восстановлениях эккаунтах и т.п.) адрес конверта устанавливается как правило в какой-нибудь специальный обработчик, т.к. на него падают сообщения о невозможности доставки, и адрес конверта и From не просто отличается, но зачастую вообще из другого домена.
mxms
11.08.2017 10:37Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.z3apa3a
11.08.2017 11:56если для авторизованных пользователей — то да, проверка соответствия и адреса From и адреса конверта авторизации это практически must have.
mxms
11.08.2017 12:48Но, я забыл добавить, что для злонамеренных отправителей, которые, обычно, используют специальные скрипты и особым образом сконфигурированные SMTP-серверы это не поможет.
echipachenko
10.08.2017 19:00-8А почему бы не брать From из текущей сессии, из текущего авторизованного пользователя, и вообще не обрабатывать его через хидеры? Ибо он попросту не нужен будет? Или я что-то не понял?..
echipachenko
10.08.2017 20:47-5А, всё, понял. речь идёт непосредственно о SMTP протоколе… Тем ни менее в нём все равно есть авторизация. Это реально больше выглядит как баг…
П. С. Перед тем как минусовать, лучше объяснить, почему вы ставите тот же минус.z3apa3a
10.08.2017 22:46+5в SMTP нет аутентификации и соответственно авторизации. Совсем. Есть расширение SMTP для аутентификаци (RFC 4954), SMTP с аутентификацией обычно называется Submission. Но между двумя почтовыми серверами (например Yandex и Mail.Ru) почта по SMTP ходит по обычному SMTP без аутентификации.
tech42
10.08.2017 20:52Проблема есть и у Яндекса. И она намного хуже. https://geektimes.ru/post/291939/
sHaggY_caT
11.08.2017 00:01+3У Яндекса проблема есть, а у mail.ru проблемы нет. Просто автор статьи не знает, как работают почтовые протоколы
Endru9
11.08.2017 06:43-2Это мелочи жизни.
Меня больше напрягает, что майл позволяет отправлять со своей почты опасные вложения, exe com js и прочие.
Эти вложения давно считаются опасными и блокируются гуглом и яндексом, а вот майл почему то принципиально не хотят блокировать эти вложения.
Опишу суть проблемы:
майл говорит что вся почта (и облако) проверяется на вирусы, однако все прекрасно понимают, прежде чем запустить новый вирус его проверяют, проверяют в том числе и антивирусником который проверяет почту на майл ру.
На моем почтовом сервере настроена блокировка подобных вложений, с отчетами о блокировках. По моей личной статистике 90% всех почтовых вирусов отправляются именно с майл.ру. Вот это действительно проблема.
По этим же соображениям приходится выдавать доступ к облаку майл.ру «по талонам», с предварительной ручной проверкой скачиваемых файлов (благо таких запросов в месяц не более 5).
konst90
11.08.2017 09:23+3А меня например напрягает, что я не могу отправить некоторые файлы без плясок с архиватором.
Хочешь защитить пользователя — запрети ему получать *.exe и прочие исполняемые файлы.hungry_ewok
11.08.2017 14:49Тащемта через гугль и с плясками с архиватором отправить проблемно — не раз получал сообщение «отправлять архивированные с паролем файлы вам запрещено», у вас не должно быть секретов от гугла, да…
Так что майлру по этой части претензий нет, молодцы что пока еще не присоединились к мейнстриму.
Igor_34_rus
11.08.2017 09:29а ещё Office документы надо запретить — там есть макросы!
и прочие обычные данные (картинки, тексты и т. д.) — викиtech42
11.08.2017 09:33У Office есть безопасный режим + есть Office Online
Igor_34_rus
11.08.2017 13:30Тогда "*.exe" тоже есть безопасный режим, встроенный в Win + запускать на виртуальной машине.
)))
Gordon01
11.08.2017 08:55+1Еще один все понял.
А раньше еще была такая дичь как открытые релеи.
http://www.antispam.ru/sh?act=msg&id=1033474961
https://en.wikipedia.org/wiki/Open_mail_relay
Tufed
11.08.2017 11:14Эта дичь до сих пор функциональна. Некоторые почтовики поддерживают открытые relay сервера, за что вполне заслуженно часто улетают в черные списки антиспамеров.
kaichou
11.08.2017 10:52+5Господи, неужели каждый узнавший, как работает электронная почта, будет сюда про это писать???
justhabrauser
11.08.2017 11:46-2Господи, неужели каждый, узнавший что это хабр, будет этим возмущаться?
Да, такой вот он сейчас /sarcazmtech42
11.08.2017 11:59Господи, неужели каждый, кто получил доступ к комментированию не через песочницу (внес хоть какой-то полезный вклад сообщество Хабра), будет так говорить? Безусловно, у Хабра есть свои проблемы, но он создается сообществом. Человеку нашел ошибку, да, это не стандарт, да не критично (хотя спорно), да, очевидно. Но это может привнести хоть какой-то вклад в безопасность, т.к. это обратит еще раз внимание к проблеме замене стандартов на более безопасные.
vvatest
11.08.2017 12:20Взгляд привлечен уже очень давно. Проблема с безопасностью почты в том, что значимое количество почтовых серверов (в смысле инстансов, а не программ) стандартов безопасности не поддерживают и не собираются в силу различных причин. И у остальных остается только один вариант — следовать стандартам. Я вас уверяю, 15 лет назад, когда подход в массе был другим: «Я буду делать так, пускай это не по RFC, но на мой взгляд так секурнее и пошли все остальные нафиг» было намного хуже. Админ почтового сервиса никогда не знал заранее дойдет ли e-mail в конкретный домен и чего именно там решили проверять и без чего молча дропать сессии…
Поэтому рассказывать про проблемы безопасности mail.ru, следующей RFC, на мой взгляд, несколько желтушно, мягко говоря.
justhabrauser
11.08.2017 12:50-1Сообществом авторов статей в стиле «как я включил компьютер и что из этого получилось»?
Ну — вариант.
А стандарты — как вам сказать… Ну настроил какой-то студент в своем первом в жизни постфиксе проверку обратной зоны DNS домена отправителя (по стандартам и/или книгам начала 70-х) — и потом жалуется в хабр, что к нему почта не ходит.
Такой вот вклад в безопасность, ага.
snovazabilparol
11.08.2017 13:36Здесь я проверил совсем свежую статью про Яндекс, там автор, вероятно использовал дебаг шлюз Яндекса, с доступом по карточкам. Интересно, стоит ли регистрироваться в мейле и проверить правдивость статьи?
tech42
11.08.2017 13:56Для проверки авторизация проходила по публичному яндексовскому smtp.yandex.ru.
Проблема актуальная. Воспроизведение через thunderbird работает.
swood
11.08.2017 14:11Вот зачем пользоваться унылым сервисом от мыла, если есть адекватные google и yandex? Мэйл ведь ничего внутри для улучшения работы своей почты не делает, только морду слизывает с конкурентов.
Yolkin-RU
11.08.2017 15:27Основная почта на gmail. Не хватает:
— адекватных фильтров
— правил
— папок
У мейла, в свою очередь, безумно очевидные вещи в фильтрах вроде «удалить и послать сообщение о несуществующем адресе», чтоб с большей вероятностью убраться из списка рассылки.
По теме статьи: очень грустно, что некоторые люди пишут про «кто-то лишится премии», имея в виду особенность, обсуждаемую с момента распространения smtp.swood
11.08.2017 16:48Папок нет, но есть ярлыки, при умелом расставлении суть та же самая. Тоже самое касается и фильтров, и правил. Тут в общем-то, если умеете пользоваться gmail, то проблем нет, если нет, то, конечно, можно пользоваться унылым мылом.
Yolkin-RU
11.08.2017 16:53У ярлыков суть не та же самая, потому что я привык следовать правилу 0 inbox и в нормально огранизованной почте у меня под 40 папок, некоторые вложены друг в друга. Ярлыки, насколько я помню, друг в друга не вкладываются, но даже если и да — в Inbox всё равно показываются все письма, включая те, что с ярлыками.
D7ILeucoH
11.08.2017 15:27Ей-Богу, намеренно баг этот юзаю уже несколько лет, неужели о нём никто не знал?
alexhott
12.08.2017 21:28-1Это не баг, это стандартная работа электронной почты.
Протокол позволяет что угодно писать в обратный адрес и в имя отправителя.
А проверять и доверять это уже надо на стороне получателя.
Много лет уже работает у меня рассылка по договорам от имени ответственных инженеров. И вот как раз проблемы с теми кто свой сервер настроил проверять обратный адрес и адрес реального отправителя.
DRDOS
13.08.2017 21:37+1А вы обратили внимание что у них пропал крестик для закрытия письма!
Тех поддержка заявила что **** и что там его никогда не было!
Я им посоветовал воспользоваться поиском, и посмотреть как закрывать письмо, не потеряв поиск.
Меня просто послали…
CityCat4
14.08.2017 08:02Эк хватились...mail.ru вообще игнорит почтовые стандарты. От слова совсем. Попробуйте-ка принять почту с него greylisting-ом. Знаете, что будет?
— Попытка 1. Greylister говорит — чувак, подожди немного
— Попытка 2 через шесть секунд. Шесть секунд, Карл! Greylister говорит — чувак, подожди немного
— Попытка 3 может произойти через час, несколько часов или вообще не произойти в зависимости от фазы Луны и сочетания звезд в гороскопе. Хорошо хоть свое наличие в черных списках отслеживают, некоторые и на это кладутdmitry_ch
14.08.2017 09:14+1Ну вот серые списки — это то, что точно нужно искоренять. Особенно если оно сделаны по-рамблеровски, т.е. когда от тебя с первого раза не примут почту, даже если ты ее с этого 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 проверять по вашим спискам.
Я к тому, что крупные почтовые провайдеры предпринимают разумные меры к доставке почты, но они скорее нужны мелким почтовикам, что мелкие почтовики — им.CityCat4
15.08.2017 05:30Ага. Щаз. Искореню. Статистику привести, сколько сотен писем в день отстреливает greylisting, сколько «черные списки»? Не, я вполне понимаю истерию вокруг них и нежелание следовать стандартам — надо же продавливать платный почтовый антивирус!
У меня во-первых, сообщение о грейлистинге отдается, время я только не указываю, но пожалуй сейчас перестрою конфиг и посмотрю — не улучшится ли ситуэйшн :)
Во-вторых, задержка пять минут — те спамеры, которые отстреливаются — они уже пролетели, а те, что разбирают ответы — все равно перепошлют.
У mail.ru логика топорно проста «не нравится — не пользуйся». Именно поэтому они на RFC кладут такой преогромный железобетонный.dmitry_ch
15.08.2017 09:24Ага. Щаз. Искореню.
У mail.ru логика топорно проста «не нравится — не пользуйся». Именно поэтому они на RFC кладут такой преогромный железобетонный.
Так чем Вы лучше их? Их система работает так, как работает (мы бы с Вами, подозреваю, не факт что построили бы лучше, с учетом масштаба), и — работает. Вы ссылаетесь на RFC, которые сделаны для доставки почты, а не для ее отбивания, не выполняете их дух (потому что доставку постоянно обеспечиваете не с первого раза), но недовольны, что кто-то еще что-то там нарушает?
Напоминает "- Смотри, чувак идет, пойдем его побьем? — Да он здоровый, еще нас поколотит! — А нас-то за что?"
Я понимаю смысл от greylisting, если он изучает переписку человека, и не задерживает почту от того же человека, с того же IP-адреса больше одного раза. Тогда и задержка для «своих» не видна, и спам вроде как бьется.
Кстати, если про черные списки, вы видели у них такое поведение: если с одного адреса много спама, то в список добавляется /24 вокруг адреса, если продолжается, то /23 и так далее, до размера route-object порой. Все алгоритмически хорошо, но это как «в вашей школе учится драчун, постоянно колотит окрестных ребят, мы посадили в тюрьму всех учеников школы, а заодно и всех детей района проживания драчуна». На все вопрос ответ один — «мы ни за что не отвечаем, хотите — пользуйтесь».
Mario_Z
Вам стоит приложить скриншот переписки с техподдержкой, раз уж такая реакция у представителей.
guai
А откуда мы узнаем, что переписка не поддельная? :)
Mario_Z
Исключительно вопрос репутации человека.