Проблемы безопасности почты Mail.ru

Два года назад мной был написан несложный PHP-скрипт для формы обратной связи. Письма приходили на почту mail.ru. Как выяснил позднее, в скрипте была ошибка. В «From» я вставлял емэйл-адрес клиента (по сути, подделывал отправителя), однако письма приходили, и ладно.

Исходный код:

$email = $_POST['email'];
$headers .= "From: " . $email . "\r\n";

А не так давно заметил, что заявки перестали приходить… Проверил форму — не работает. Вызвало недоумение, ибо никто ничего не трогал, и два года всё работало нормально. По ходу экспериментов выяснилось, что если использовать такой код:

$email = "Сбербанк <help@sberbank.ru";
$headers .= "From: " . $email . ">>\r\n";

то можно совершенно спокойно подделывать любого отправителя (в данном случае Сбербанк).

image

image

Письма приходят во входящие. Как спам определяются не с первого раза. В интерфейсе Mail.ru пишется «Мы не можем проверить подлинность отправителя», однако если вы собираете почту с помощью программы (например, Outlook), то там никакой надписи, естественно, нет.

Ключевое место — дополнительный символ ">". Без этого символа письма с подделанным отправителем, как и положено, НЕ приходят. Очевидно, у почты Mail.ru ошибка в обработке заголовков «headers».

Проверял этот баг на Яндексе. У Яндекса такой проблемы нет (письма с подделанным отправителем не пропускает даже в папку «спам»).

P.S. Представитель Mail.ru сказал «мы не считаем данную ситуацияю ошибкой» (цитата точная), поэтому выкладываю эту информацию с чистой совестью.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 99
  • +4

    Вам стоит приложить скриншот переписки с техподдержкой, раз уж такая реакция у представителей.

    • +1
      А откуда мы узнаем, что переписка не поддельная? :)
      • 0

        Исключительно вопрос репутации человека.

    • +4
      E-mail создавалось по образу и подобию аналога из реального мира. Вы так же можете подписать реальное письмо, от лица сбербанка например. Из-за того что Яндекс не принимает подобные письма вообще случаются проблемы. Например их почта для домена: при настраивании spf записи DNS необходимо указать ip-адрес хостинга, иначе яндекс не будет принимать письма с данного домена. Но этот параметр вынесен отдельно и в базовой инструкции не указан, в связи с чем бывали такие проблемы у некоторых клиентов.
      • НЛО прилетело и опубликовало эту надпись здесь
      • +13
        Привет, я процитирую свой на этот репорт с HackerOne:

        к сожалению, электронная почта действительно изначально не защищена от подделки адреса. Существует стандарт DMARC который позволяет защититься от подделки, но работает только на письмах соответствующих стандарту RFC 5322 и только для отправителей, настроивших политику DMARC. В настоящее время достаточно много писем не соответствует этому стандарту и проверить на них DMARC невозможно. Постепенно мы «закручиваем гайки» для нестандартных писем. Сейчас на таких письмах (и в некоторых других ситуациях) показывается уведомление о возможной подделке адреса, что видно на скриншоте, поэтому пользователь предупрежден и мы не считаем данную ситуацию ошибкой.

        P.S. duma.gov.ru в принципе не публикует политику DMARC, поэтому защитить письма от этого домена от подделки стандартными средствами невозможно.


        Т.е. существует две разные проблемы:
        1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
        2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.

        В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
        • –1
          Вы грамотный человек, и всё правильно пишете. Однако (много раз уже это повторяю) у Яндекса таких проблем нет. Почему-то вышеописанные причины им не мешают.
          • +14
            Это вам так кажется. Яндекс запрещает конкретную комбинацию символов ">>", что никак не связано с безопасностью и не мешает обойти DMARC через другие варианты «неправильного» From, вот в таком случае, например, даже сообщения о подделке нет:

            image

            Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.
            • –16
              А почему Яндекс исправил ошибку ">>", а вы нет?

              Начинает складываться впечатление, что в этом месте (подделка отправителей) «дыра на дыре»…

              Узнать бы мнение самого Яндекса :)
              • +8
                Потому что это — не ошибка.
                • +9
                  Угу, уровни компетенции на низком уровне падают. Люди уже не знают, как работает протокол SMTP, и, наверное, ни разу в жизни не отправляли почту telnet/openssl s_client.
                  Для современных разработчиков SMTP too low layer :(
                  И читать rfc по нему им не нужно. И правда — в том же питоне достаточно тыц-тыц, и вызвать одной строчкой из того или другого модуля, и не думать ни о чём.
                  • 0
                    Вот эти 3 строчки в exim стоили 3 часа времени.

                    # Deny all Mailer-Daemon messages not for us:
                    deny message = We didn't send the message
                    senders =:
                    domains = !+relay_domains

                    я просто не мог допустить, что такое «емкое сообщение» может выдавать exim.
                  • –1
                    Начали придираться к словам… :) Суть моего сообщения в том, что у одного сервиса эта «дыра» (подберите наиболее подходящее слово) закрыта (z3apa3a написал: «Яндекс запрещает конкретную комбинацию символов „>>“), а у другого — нет. Как выясняется дальше, у того же Яндекса есть другие уязвимости. А что мешает Мэйлу сделать „костыли“ пока невозможно решить проблему глобально и закрыть „конкретные комбинации символов“? Яндекс же, как мы видим, конкретно этот случай „запретил“.
                    • –1
                      И в результате куча народу с ящиками на яндексе получили головную боль, потому что им могут не прийти уведомления с сайтов о сделанном заказе и т.п.
                      • +2
                        Комбинация ">>" — это ведь явная ошибка в скрипте. По-моему, сервис (почтовый протокол, др.) и не должен обрабатывать «глючный» код. Это проблема автора скрипта, «пиши код правильно», «недопустимые символы».
                        • 0
                          Да, но, к сожалению, очень много скриптов имеют те или иные ошибки, даже у очень крупных компаний. Например, нам приходилось связываться с разработчиками iCloud по поводу некорректного формирования писем в их сервисе. Так что строгого соответствия стандартам сразу начать требовать нельзя. Правильно сформировать письмо не так просто, как кажется. А вот многие спамеры наоборот о почте знают больше чем большинство разработчиков приложений, решивших написать генерацию письма. Пока с такой сигнатурой идет нормальный трафик и не идет спам — он пропускается. Если с такой сигнатурой пойдет спам — она будет может быть блокирована или отправлена в спам.
                      • 0
                        Нет никаких придирок. Какой пункт RFC нарушен при отправке такого письма?
                        • –1
                          Ну вот опять… :) Комбинация ">>" у Яндекса «запрещена», у Мэйла нет. С другой стороны (как люди уже написали), у Яндекса есть другие «дыры», которые у Мэйла закрыты. Я не знаю, почему у одних сделано так, а других вот так. Может прямо сейчас исправляют, может недоглядели, а может ещё чего. На самом деле, я ещё в самом начале Владимиру Дубровину (@z3apa3a) написал, что возможно проблема в «почтовом протоколе», но когда увидел, что Яндекс такую подделку отправителя не пропускает, то начал задавать вопросы Мэйлу, мол, «а почему вы пропускаете?». И мне, честно, до сих пор непонятно, почему у один, а у других эдак. Может, это и не моё дело.
                          • +4
                            В данной ситуации, значит дыра у яндекса, так как они работают не по стандарту почты.
                        • 0
                          А зачем запрещать именно ">>"?

                          Допустим, запретили. Дальше:
                          — у пользователей начались внезапные нестыковки с интернет-магазинами
                          — отправитель фишинговых писем заметил, что они не приходят на тестовый ящик, и изменил ">>" на "<<".

                          Силы (деньги?) потрачены, обратная совместимость нарушена, негатив клиентам создан, дырка осталась. А в чем профит?
              • –2
                бегом спамить пользователей mail от имени банка))

                А так бы конечно да, ответ mail'а бы выложить.
                • 0
                  В начале 2000ых помню была некая программа в интерфейсе которой в поле «от кого» можно было вписать все что угодно, при этом smtp сервер одного из популярных ныне почтовых сервисов был вообще без авторизации, то есть можно было слать что угодно и кому угодно. Столько лет прошло а воз и ныне там…
                  • +1

                    Это было на mail.ru. По smtp авторизация вообще не применялась, поэтому даже в outlook express можно было в адрес о правителя вписать кого угодно (с домена mail.ru). При этом письмо не "подделывалось" а действительно отправлялось с с аккаунта, подписанного в поле from.

                    • +1

                      Вообще-то, изначально, поле From != адресу отправителя, по стандарту (я могу путать детали, читал RFC давно).


                      Например, секретарша записывает письмо со слов начальника. В таком случае ей следует указать в поле From адрес начальника, тогда как она отправляет письмо со своего аккаунта, не имея доступа к аккаунту начальника. А вот адрес её аккаунта следует указывать в поле Sender.


                      Как уже упомянули не раз выше — проблема E-Mail в том, что он создавался очень давно (если не ошибаюсь, он старше того, что мы сейчас называем интернетом). Печатные письма в те времена тоже можно было легко подделать, особенно если их печатала секретарша на печатной машинке. Просто проблемы спама, а тем более массовой подделки в те времена не существовало.

                      • 0
                        Не совсем точно выразился. Сейчас если в поле «от кого» вписать какой-то адрес то в теле письма всё равно можно увидеть параметры оригинального отправителя т.к. сервер отправки сообщений требует авторизацию а раньше там максимум был виден IP адрес а вот т.к. авторизации не требовалось то изобличить реального отправителя было сложновато. Первое время мы с друзьями прикалывались так друг над другом, отправляя письма из военкомата\мвд и проч. :)
                        • 0
                          Можно. Но позволяет сейчас это далеко не каждый. Да и кто смотрит в исходник письма, если это обычная бухгалтерша?
                          • 0
                            Вот с этого все и начинается обычно. Сначала не смотрят а потом приходит злобный петя и пожирает все годы наработок :)
                          • 0

                            Вполне точно, я говорил про заголовки самого письма, а не про то, что каждый SMTP сервер в цепочке добавляет свой заголовок к пакету, а не к самому письму (могу путать термины, но суть такая).


                            Ну а в современных условиях GMail суёт в мои письма адрес моего аккаунта в Sender принудительно, если он не равен From — вот это вот не по стандарту. (Или делал так какое-то время назад. Адреса в From, естественно, верифицированы для моего аккаунта.)


                            Впрочем, в большинстве клиентов отображение поля Sender даже отключено и почти никто не знает что это и зачем.


                            UPD: Похоже это я запутался в ответах, ну да и ладно.

                      • –7
                        Интересно, как они заговорят, если кто-то станет рассылать письма от имени mail.ru?
                        • 0
                          Еще у меня некоторые письма из приложения gmail на андроиде с ящика mail.ru не удаляются, всеми техподдержками был послан нафиг…
                          • +1
                            + за выкладывание переписки с техподдержкой. Т.к. вполне себе повод переехать с мыла.ру
                            • –4
                              а вы еще задумываетесь?
                              • 0
                                Нет. С января 10-го года полет был нормальный, без проблем + интерфейс для моего восприятия предельно прост.
                                • +5

                                  Я перестал пользоваться мейлру, когда в далеком 2006-м однажды утром обнаружил в папке "входящие" письма, которые я удалил 1-2 года назад. Вот просто так, взяли и появились.


                                  Gmail тогда ещё был по приглашениям, счастливым обладателем которого я тогда и стал.

                                  • –8
                                    Gmail это почта вероятного противника.
                                    • +6
                                      Ну, кому как.
                                      • 0
                                        А Mail.ru тогда — вероятного предателя.
                                        • 0
                                          Скорее всего невероятного
                                  • 0
                                    А куда? Серьезно спрашиваю.
                                    • 0
                                      На свои сервера
                                      • 0

                                        +1
                                        Но требует квалификации.

                                        • +2
                                          это не самый хороший совет, точнее он хороший, но не для всех, именно из-за этого потом начинаются проблемы с доставкой писем от поставщиков/клиентов, потому что косорукие эникеи даже не подозревают о существовании SPF, DKIM и DMARC, ставят локалхост везде где можно, обратный адес не резолвится, и даже встречался с тем что msgid одинаковый во всех письмах от них и любой нормальный сервер это просто зарезает как дублированное письмо
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                        • 0
                                          protonmail,
                                          свой сервер
                                    • 0
                                      2 месяца назад тоже экспериментировал с такими подделываниями. Но mail.ru не пропустил ни одного письма. Тут пишут что пропустил. Кому верить?
                                      • –3
                                        Можешь проверить лично. Ключевое место указал. Скрипт самый обычный. Но если нужно, могу скинуть исходники (php-скрипт + html-форма).
                                        • –1
                                          Давайте. А то проверить хочется, а в подобном совсем не разбираюсь.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                        • +1
                                          Была статья с похожей ситуацией на Хабре: Подделываем письма от крупнейших российских банков. Правда, там не про Mail.ru, а про банки.
                                          • 0
                                            Выскажусь как автор той статьи. Защита от подделки писем должна происходить с двух сторон: владельца сервиса и получателя письма (в большинстве случаев это почтовый провайдер, например Mail.ru).

                                            К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.

                                            Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса.

                                            В тему писем: хотелось бы спросить z3apa3a, почему нужно использовать DMARC (за исключением защиты поддоменов). Часто получаю ответы от разных сервисов вида «Мы публикуем SPF-запись, почтовые провайдеры должны сами проверять запись и отправлять в спам письмо с „~“ и не принимать с „-“, этого достаточно». Буду благодарен за ответ.
                                            • +2
                                              SPF изначально предназначался для другого: чтобы забыть про репутации 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.
                                              • +2
                                                Дополню — аналогичная проблема у DKIM.
                                                DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
                                                • 0

                                                  Соглашусь.
                                                  На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
                                                  В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.

                                                  • 0
                                                    Различие адреса конверта и From не является чем-то запрещенным, тем более нарушением стандарта. А вот такая блокировка это не просто нарушение стандарта, она зарежет все не личные письма, т.к. во всех автоматических письмах (включая письма о восстановлениях эккаунтах и т.п.) адрес конверта устанавливается как правило в какой-нибудь специальный обработчик, т.к. на него падают сообщения о невозможности доставки, и адрес конверта и From не просто отличается, но зачастую вообще из другого домена.
                                                    • 0

                                                      Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
                                                      Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
                                                      В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.

                                                      • 0
                                                        если для авторизованных пользователей — то да, проверка соответствия и адреса From и адреса конверта авторизации это практически must have.
                                                        • 0

                                                          Но, я забыл добавить, что для злонамеренных отправителей, которые, обычно, используют специальные скрипты и особым образом сконфигурированные SMTP-серверы это не поможет.

                                              • –12
                                                Проверил, работает. Кажется, кто-то лишится премии, как минимум )
                                                • –8
                                                  А почему бы не брать From из текущей сессии, из текущего авторизованного пользователя, и вообще не обрабатывать его через хидеры? Ибо он попросту не нужен будет? Или я что-то не понял?..
                                                  • –5
                                                    А, всё, понял. речь идёт непосредственно о SMTP протоколе… Тем ни менее в нём все равно есть авторизация. Это реально больше выглядит как баг…
                                                    П. С. Перед тем как минусовать, лучше объяснить, почему вы ставите тот же минус.
                                                    • +5
                                                      в SMTP нет аутентификации и соответственно авторизации. Совсем. Есть расширение SMTP для аутентификаци (RFC 4954), SMTP с аутентификацией обычно называется Submission. Но между двумя почтовыми серверами (например Yandex и Mail.Ru) почта по SMTP ходит по обычному SMTP без аутентификации.
                                                  • 0
                                                    Проблема есть и у Яндекса. И она намного хуже. https://geektimes.ru/post/291939/

                                                    • +3
                                                      У Яндекса проблема есть, а у mail.ru проблемы нет. Просто автор статьи не знает, как работают почтовые протоколы
                                                    • –2
                                                      Это мелочи жизни.
                                                      Меня больше напрягает, что майл позволяет отправлять со своей почты опасные вложения, exe com js и прочие.
                                                      Эти вложения давно считаются опасными и блокируются гуглом и яндексом, а вот майл почему то принципиально не хотят блокировать эти вложения.
                                                      Опишу суть проблемы:
                                                      майл говорит что вся почта (и облако) проверяется на вирусы, однако все прекрасно понимают, прежде чем запустить новый вирус его проверяют, проверяют в том числе и антивирусником который проверяет почту на майл ру.
                                                      На моем почтовом сервере настроена блокировка подобных вложений, с отчетами о блокировках. По моей личной статистике 90% всех почтовых вирусов отправляются именно с майл.ру. Вот это действительно проблема.
                                                      По этим же соображениям приходится выдавать доступ к облаку майл.ру «по талонам», с предварительной ручной проверкой скачиваемых файлов (благо таких запросов в месяц не более 5).
                                                      • +3
                                                        А меня например напрягает, что я не могу отправить некоторые файлы без плясок с архиватором.
                                                        Хочешь защитить пользователя — запрети ему получать *.exe и прочие исполняемые файлы.
                                                        • 0
                                                          Тащемта через гугль и с плясками с архиватором отправить проблемно — не раз получал сообщение «отправлять архивированные с паролем файлы вам запрещено», у вас не должно быть секретов от гугла, да…

                                                          Так что майлру по этой части претензий нет, молодцы что пока еще не присоединились к мейнстриму.
                                                          • 0
                                                            Попробуйте разбивать архивы на части — у меня всегда проходит
                                                            • 0
                                                              Я отправлял в rar без шифрования — год назад получалось.
                                                          • 0
                                                            а ещё Office документы надо запретить — там есть макросы!
                                                            и прочие обычные данные (картинки, тексты и т. д.) — вики
                                                            • 0
                                                              У Office есть безопасный режим + есть Office Online
                                                              • +1
                                                                У Office есть безопасный режим
                                                                Это который бесполезный полностью?
                                                                • 0
                                                                  Да-да, именно он. Но ведь есть же Office Online
                                                                  • +1
                                                                    Ещё и историю посещений с сохранёнными паролями слить?
                                                                • 0
                                                                  Тогда "*.exe" тоже есть безопасный режим, встроенный в Win + запускать на виртуальной машине.
                                                                  )))
                                                            • +1
                                                              Еще один все понял.
                                                              А раньше еще была такая дичь как открытые релеи.
                                                              http://www.antispam.ru/sh?act=msg&id=1033474961
                                                              https://en.wikipedia.org/wiki/Open_mail_relay
                                                              • 0
                                                                Эта дичь до сих пор функциональна. Некоторые почтовики поддерживают открытые relay сервера, за что вполне заслуженно часто улетают в черные списки антиспамеров.
                                                              • +5
                                                                Господи, неужели каждый узнавший, как работает электронная почта, будет сюда про это писать???
                                                                • –2
                                                                  Господи, неужели каждый, узнавший что это хабр, будет этим возмущаться?
                                                                  Да, такой вот он сейчас /sarcazm
                                                                  • 0
                                                                    Господи, неужели каждый, кто получил доступ к комментированию не через песочницу (внес хоть какой-то полезный вклад сообщество Хабра), будет так говорить? Безусловно, у Хабра есть свои проблемы, но он создается сообществом. Человеку нашел ошибку, да, это не стандарт, да не критично (хотя спорно), да, очевидно. Но это может привнести хоть какой-то вклад в безопасность, т.к. это обратит еще раз внимание к проблеме замене стандартов на более безопасные.
                                                                    • 0
                                                                      Взгляд привлечен уже очень давно. Проблема с безопасностью почты в том, что значимое количество почтовых серверов (в смысле инстансов, а не программ) стандартов безопасности не поддерживают и не собираются в силу различных причин. И у остальных остается только один вариант — следовать стандартам. Я вас уверяю, 15 лет назад, когда подход в массе был другим: «Я буду делать так, пускай это не по RFC, но на мой взгляд так секурнее и пошли все остальные нафиг» было намного хуже. Админ почтового сервиса никогда не знал заранее дойдет ли e-mail в конкретный домен и чего именно там решили проверять и без чего молча дропать сессии…

                                                                      Поэтому рассказывать про проблемы безопасности mail.ru, следующей RFC, на мой взгляд, несколько желтушно, мягко говоря.
                                                                      • –1
                                                                        Сообществом авторов статей в стиле «как я включил компьютер и что из этого получилось»?
                                                                        Ну — вариант.
                                                                        А стандарты — как вам сказать… Ну настроил какой-то студент в своем первом в жизни постфиксе проверку обратной зоны DNS домена отправителя (по стандартам и/или книгам начала 70-х) — и потом жалуется в хабр, что к нему почта не ходит.
                                                                        Такой вот вклад в безопасность, ага.
                                                                  • 0
                                                                    Здесь я проверил совсем свежую статью про Яндекс, там автор, вероятно использовал дебаг шлюз Яндекса, с доступом по карточкам. Интересно, стоит ли регистрироваться в мейле и проверить правдивость статьи?
                                                                    • 0
                                                                      Для проверки авторизация проходила по публичному яндексовскому smtp.yandex.ru.
                                                                      Проблема актуальная. Воспроизведение через thunderbird работает.
                                                                      • 0
                                                                        Вот зачем пользоваться унылым сервисом от мыла, если есть адекватные google и yandex? Мэйл ведь ничего внутри для улучшения работы своей почты не делает, только морду слизывает с конкурентов.
                                                                        • 0
                                                                          Основная почта на gmail. Не хватает:
                                                                          — адекватных фильтров
                                                                          — правил
                                                                          — папок
                                                                          У мейла, в свою очередь, безумно очевидные вещи в фильтрах вроде «удалить и послать сообщение о несуществующем адресе», чтоб с большей вероятностью убраться из списка рассылки.

                                                                          По теме статьи: очень грустно, что некоторые люди пишут про «кто-то лишится премии», имея в виду особенность, обсуждаемую с момента распространения smtp.
                                                                          • 0
                                                                            Папок нет, но есть ярлыки, при умелом расставлении суть та же самая. Тоже самое касается и фильтров, и правил. Тут в общем-то, если умеете пользоваться gmail, то проблем нет, если нет, то, конечно, можно пользоваться унылым мылом.
                                                                            • 0
                                                                              У ярлыков суть не та же самая, потому что я привык следовать правилу 0 inbox и в нормально огранизованной почте у меня под 40 папок, некоторые вложены друг в друга. Ярлыки, насколько я помню, друг в друга не вкладываются, но даже если и да — в Inbox всё равно показываются все письма, включая те, что с ярлыками.
                                                                              • +1

                                                                                В гмайле ярлыки тоже вкладываются друг друга. Так же есть кнопка "Архивировать" и аналогичная опция в фильтрах — письма будут видны в ярлыках, но не во входящих.

                                                                                • +1
                                                                                  Спасибо, мне полегчало. Может разберу своих 50к писем теперь.
                                                                        • 0
                                                                          Ей-Богу, намеренно баг этот юзаю уже несколько лет, неужели о нём никто не знал?
                                                                          • –1

                                                                            Это не баг, это стандартная работа электронной почты.
                                                                            Протокол позволяет что угодно писать в обратный адрес и в имя отправителя.
                                                                            А проверять и доверять это уже надо на стороне получателя.
                                                                            Много лет уже работает у меня рассылка по договорам от имени ответственных инженеров. И вот как раз проблемы с теми кто свой сервер настроил проверять обратный адрес и адрес реального отправителя.

                                                                            • –1
                                                                              Это не добавляет оптимизма.
                                                                              • +1
                                                                                А вы обратили внимание что у них пропал крестик для закрытия письма!
                                                                                Тех поддержка заявила что **** и что там его никогда не было!
                                                                                Я им посоветовал воспользоваться поиском, и посмотреть как закрывать письмо, не потеряв поиск.
                                                                                Меня просто послали…
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  • +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 проверять по вашим спискам.

                                                                                    Я к тому, что крупные почтовые провайдеры предпринимают разумные меры к доставке почты, но они скорее нужны мелким почтовикам, что мелкие почтовики — им.
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        Ага. Щаз. Искореню.

                                                                                        У mail.ru логика топорно проста «не нравится — не пользуйся». Именно поэтому они на RFC кладут такой преогромный железобетонный.

                                                                                        Так чем Вы лучше их? Их система работает так, как работает (мы бы с Вами, подозреваю, не факт что построили бы лучше, с учетом масштаба), и — работает. Вы ссылаетесь на RFC, которые сделаны для доставки почты, а не для ее отбивания, не выполняете их дух (потому что доставку постоянно обеспечиваете не с первого раза), но недовольны, что кто-то еще что-то там нарушает?

                                                                                        Напоминает "- Смотри, чувак идет, пойдем его побьем? — Да он здоровый, еще нас поколотит! — А нас-то за что?"

                                                                                        Я понимаю смысл от greylisting, если он изучает переписку человека, и не задерживает почту от того же человека, с того же IP-адреса больше одного раза. Тогда и задержка для «своих» не видна, и спам вроде как бьется.

                                                                                        Кстати, если про черные списки, вы видели у них такое поведение: если с одного адреса много спама, то в список добавляется /24 вокруг адреса, если продолжается, то /23 и так далее, до размера route-object порой. Все алгоритмически хорошо, но это как «в вашей школе учится драчун, постоянно колотит окрестных ребят, мы посадили в тюрьму всех учеников школы, а заодно и всех детей района проживания драчуна». На все вопрос ответ один — «мы ни за что не отвечаем, хотите — пользуйтесь».
                                                                                  • 0
                                                                                    Эти всякие почты нужны только для активации аккаунтов.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое