И получил бы ожидаемый результат, т.к. тут нет чего-то, что ловится фаззером, если его только специально на затачивать именно на такую утечку содержимого.
Несколько процентов сбоев DKIM не бывает без причины. Сбои бывают, но на правильно сформированных письмах это маленькие доли процента (менее 0.1%). Сбои на существенном проценте означают, что часть ваших писем нормализуется получателем, и происходит это, скорей всего, из-за проблем озвученных выше. Если письмо генерируется с нарушением RFC 5322, то поведение на нем не предсказуемое и может быть разным у разных получателей.
Очень даже можно. Если это не проблема самого ESP, то можно сегментировать разные категории писем по разным поддоменам (в конверте или в From) или DKIM-селекторам, чтобы идентифицировать проблемную категорию пиcем.
Даже если какое-то письмо не дойдет из-за разового сбоя DMARC (например, был недоступен DNS), при reject вы можете понять это по ответу SMTP и переотправить письмо. Но при тех же самых условиях при none ваше письмо с побитым DKIM с очень большой долей вероятности легло в папку «Спам», и ровно так же не будет прочитано пользователем, но об этом вы никогда не узнаете.
И ARC, к сожалению, не очень решает проблему с пересылками, т.к. требует доверия к пересылающей стороне и мало чем отличается от любого другого списка известных форвардеров (например по IP или DKIM-подписям).
Обычный форвардинг на уровне MTA не ломает DKIM, т.к. не меняет содержимое письма. Если он ломает, значит либо DKIM неправильно настроен, например подписываются трекинговые заголовки, либо письмо неправильно формируется, например не формируются обязательные заголовки (Date, From, Message-ID), и они добавляются транзитным сервером уже после DKIM, что «бьет» DKIM подпись. Другие «косяки» с формированием письма, по которым DKIM может биться тоже обсуждаются в статье — слишком длинные строки, неправильные терминаторы, 8-битные символы в заголовках и т.д.
Единственное исключение, которое я знаю это Microsoft Exchange / office365, он при некоторых настройках фактически формирует письмо заново.
Электронные письма могут содержать несколько альтернативных частей, обычно это plain text и HTML. Сейчас к ним добавился AMP. Почтовый клиент показывает ту часть, которую умеет, клиент без поддержки AMP будет показывать привычный HTML.
Скорей всего, вы не в ту игру играете и пытаетесь поймать себя за хвост.
Все поисковые боты Mail.Ru идентифицируют себя через User-Agent и поддерживают robots.txt. Но из сети Mail.Ru могут приходить не только боты, но и обычный трафик от внутренних пользователей и проксированные запросы от внешних пользователей, например за внешней картинкой из письма или предпросмотром страницы по ссылке из письма. Запросы проксируются, чтобы скрыть IP адрес пользователя и не давать его отслеживать, но пользовательский User-Agent при этом сохраняется. Если у вас есть какие-то жалобы на активность из сетей Mail.Ru — пишите на abuse@corp.mail.ru
Вы приучаете пользователя вводить пароль от одного приложения в другом приложении, это одна из тех вещей, которых OAuth 2.0 старается избежать. Пользователь не может отличить зловредное приложение от незловредного, поэтому не надо его приучать вводить пароль где попало.
location ~ /memleak {
rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
}
location / {
root html;
index index.html index.htm;
}
без использования openresty приводит к раскрытию данных другого запроса:
curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...
Это весьма искусственная, но все-таки демонстрация наличия ошибки в самом nginx. Вопрос может быть является ли эта ошибка уязвимостью безопасности.
У меня действительно нет опыта работы с Mikrotik'ами.
Даже если какое-то письмо не дойдет из-за разового сбоя DMARC (например, был недоступен DNS), при reject вы можете понять это по ответу SMTP и переотправить письмо. Но при тех же самых условиях при none ваше письмо с побитым DKIM с очень большой долей вероятности легло в папку «Спам», и ровно так же не будет прочитано пользователем, но об этом вы никогда не узнаете.
Единственное исключение, которое я знаю это Microsoft Exchange / office365, он при некоторых настройках фактически формирует письмо заново.
en.wikipedia.org/wiki/Nagle%27s_algorithm
help.mail.ru/mail-help/letters/write/trouble/error
Еще с 1981го года:
Все поисковые боты Mail.Ru идентифицируют себя через User-Agent и поддерживают robots.txt. Но из сети Mail.Ru могут приходить не только боты, но и обычный трафик от внутренних пользователей и проксированные запросы от внешних пользователей, например за внешней картинкой из письма или предпросмотром страницы по ссылке из письма. Запросы проксируются, чтобы скрыть IP адрес пользователя и не давать его отслеживать, но пользовательский User-Agent при этом сохраняется. Если у вас есть какие-то жалобы на активность из сетей Mail.Ru — пишите на abuse@corp.mail.ru
P.S. _escaped_fragment_ имеет статус deprecated с 2015го года.