Обязательно разберемся. Но по поводу бесполезности статьи, цитата:
Что делать, если, несмотря на соблюдение всех рекомендаций, письма все-таки не доходят до пользователей? Обращайтесь в службы поддержки получателей писем — как правило, подобные проблемы решаются оперативно. О проблемах доставки на адреса, обслуживаемые серверами Mail.Ru, можно писать на abuse@corp.mail.ru. Не забывайте как можно полнее описать проблему – очень помогут сообщения об ошибках, тексты сообщений о невозможности доставки, журналы серверов и прочая техническая информация.
Если в обращении в саппорт нет никакой информации, только код ошибки — то саппорт обычно отвечает шаблоном, соответствующим категории блокированного письма, т.к. у первой линии саппорта нет доступа к содержимому пользовательских писем, только категория ошибки. В данном случае саппорт ошибочно предположил, что вы ответили на фишинговое письмо, это косяк.
Но если вы напишете на abuse@corp.mail.ru и укажете, что проблема произошла с рассылками, то не придется сталкиваться с ответами от роботов или шаблонами.
Помимо технических рекомендаций к рассылкам, есть еще административные требования и репутация. Если вы не валидируете адреса подписчиков или рассылаете то, что пользователи считают спамом, то соблюдение технических рекомендаций не поможет.
Если вы все выполняете, то никаких проблем с общением с abuse@corp.mail.ru у вас не будет.
Поддержка цепочек сейчас в стадии сплит-тестирования. С большой долей вероятности ваш ящик уже имеет эту возможность, тогда в меню «Вид» на списке писем есть пункт «Включить группировку». Если нет — то он появится в ближайшее время.
С mail.ru вполне можно решать такие вещи, есть адрес abuse@corp.mail.ru, с которого обязательно ответят и достаточно быстро.
С гуглом посложнее. Мы достаточно крупный почтовый сервис, у нас есть свои каналы решения проблем, но более мелким почтовым сервисам придется искать решение самостоятельно. Гугл, например, очень подозрительно относится к ссылкам, по которым можно отслеживать переходы пользователей (с уникальным идентификатором в каждом письме) и сокращателям ссылок и у них достаточно разные требования к разным категориям писем. Здесь вам гораздо более полезные советы могут дать коллеги из компаний со схожим профилем по доставляемости.
Такие проблемы достаточно часто обсуждаются на профильных конференциях, например Mailing Day.
По-разному соблюдают, в среднем заметно лучше, чем крупные организации, которые делают рассылки сами себе. Я попрошу коллегу, которая работает с рассыльщиками прокомментировать поподробней и возможно с примерами чуть позже.
Если нет подписи, ваш домен будут подделывать в спам-письмах, вместе со всеми типичными заголовками. И вы в одной цифре будете видеть усредненные значения по отправленным в спам и прочитанным по вашим рассылкам и по спам-рассылкам с поддельным адресом. Отделить одно от другого будет невозможно.
Не поленитесь, внедрите DKIM и DMARC. Это просто и дает гарантию, что с вашего домена кроме ваших писем ничего не придет, никакие спамеры/конкуренты не попортят его репутацию. Профит и вам и окружающим.
Вот да, с таким и боремся. Причем проблемы вылазят у рассыльщиков любого размера, очень мало кто письма генерирует вообще без «помарок». Кодировка это настоящая беда — мы и другие крупные почтовые службы в сомнительных случаях кодировку текста автодетектим. А рассыльщик на каком-нибудь одном ящике посмотрел, что все читается и шуранул по всем пользователям.
Мы не учитываем в репутационных метриках домена статистику по неподписанным письмам, поэтому и не отображаем ее. Подробнее о репутации было в прошлой статье.
Поэтому, если хочется, чтобы домен накапливал репутацию — DKIM подпись обязательно должна присутствовать. Иначе эта репутация может быть использована спамерами.
Привет, на самом деле статья разделена на три раздела: для администраторов, для разработчиков (авторов скриптов рассылок) и для верстальщиков. Выделил пожирнее, кому что предназначается.
Во-первых, добавить environment в CGI не-Bash скрипты (Perl, Python, PHP) достаточно сложно
Вот это не соответствует действительности. Атакующий почти всегда имеет контроль над какой-либо переменной окружения в CGI, а exec-функции, за исключением тех, где переменные окружения передаются явно, наследуют переменные окружения родительского процесса, как и в случае system().
Вы не правы, все заголовки запроса, например User-Agent передаются в CGI как переменные среды окружения. Для эксплуатации достаточно установить соответствующий заголовок.
Фактически, любой PHP или Perl скрипт который делает system() уязвим, если при этом вызывается bash.
Я разруливал однажды очень похожую ситуацию (с MTU, кстати, не связанную), когда из сети одного крупного учреждения за Microsoft DMG пропал доступ к некоторым серверам Yandex, при этом к другим серверам в той же сетке доступ был. Тоже сначала думали на блокировку со стороны Яндекса. Проблема, кстати, оказалась достаточно интересной, могу в личке финальное заключение показать. В целом, никто не виноват, у обоих оказались «особенности» — у TMG в NAT, у Yandex в фильтрации.
В общем, согласен, все может. Может фаерволы не срослись, может МТС фильтровал. А может Yota накосячили в приложении и оно где-то не пролазит через транспарентный прокси который списки Роскомнадзора фильтрует.
Если в обращении в саппорт нет никакой информации, только код ошибки — то саппорт обычно отвечает шаблоном, соответствующим категории блокированного письма, т.к. у первой линии саппорта нет доступа к содержимому пользовательских писем, только категория ошибки. В данном случае саппорт ошибочно предположил, что вы ответили на фишинговое письмо, это косяк.
Но если вы напишете на abuse@corp.mail.ru и укажете, что проблема произошла с рассылками, то не придется сталкиваться с ответами от роботов или шаблонами.
Если вы все выполняете, то никаких проблем с общением с abuse@corp.mail.ru у вас не будет.
мне кажется что в истории хакерства совершенно невозможно обойтись без хаков MIT. В wiki неплохая статья.
С гуглом посложнее. Мы достаточно крупный почтовый сервис, у нас есть свои каналы решения проблем, но более мелким почтовым сервисам придется искать решение самостоятельно. Гугл, например, очень подозрительно относится к ссылкам, по которым можно отслеживать переходы пользователей (с уникальным идентификатором в каждом письме) и сокращателям ссылок и у них достаточно разные требования к разным категориям писем. Здесь вам гораздо более полезные советы могут дать коллеги из компаний со схожим профилем по доставляемости.
Такие проблемы достаточно часто обсуждаются на профильных конференциях, например Mailing Day.
Не поленитесь, внедрите DKIM и DMARC. Это просто и дает гарантию, что с вашего домена кроме ваших писем ничего не придет, никакие спамеры/конкуренты не попортят его репутацию. Профит и вам и окружающим.
Поэтому, если хочется, чтобы домен накапливал репутацию — DKIM подпись обязательно должна присутствовать. Иначе эта репутация может быть использована спамерами.
Вот это не соответствует действительности. Атакующий почти всегда имеет контроль над какой-либо переменной окружения в CGI, а exec-функции, за исключением тех, где переменные окружения передаются явно, наследуют переменные окружения родительского процесса, как и в случае system().
Фактически, любой PHP или Perl скрипт который делает system() уязвим, если при этом вызывается bash.
Релиз с поддержкой этой фичи в Google Play на часть пользователей тоже уже раздается.
В общем, согласен, все может. Может фаерволы не срослись, может МТС фильтровал. А может Yota накосячили в приложении и оно где-то не пролазит через транспарентный прокси который списки Роскомнадзора фильтрует.