Корпорация добра

[tasic]

Витя (среди прочих полезных дел у нас почтой занимается) рассказал мне, что google на своей почте ввел dmarc и dkim.

До dmarc у меня еще руки не дошли, а вот dkim уже немножко почитал. Еще один способ подписывать письма, правда не пользователем (читай MUA), а MTA. Иначе говоря программа передачи почты подписывает письмо, свидетельствуя, что данное письмо с адресом во From: пользователь@домен отправлено действительно с "домен". Обработка этой подписи необязательна, и даже в случае неправильной/неудачной/недействительной подписи, совсем не обязательно это письмо выбрасывать -- оно может быть доставлено получателю. Более того, с этой подписью можно вообще не разбираться, и доставлять письмо не проверяя эту подпись. Казалось бы все хорошо. Но вот гугл начал этот DKIM проверять. Нет, он пока не отвергает писем, не подписанных DKIM. Массово не отвергает, хотя некоторые потуги к этому у него есть. Только вот непонятно мне, а что в этом случае делать со списками рассылки. Пишет некий user1@sender.com письмо на список рассылки по адресу globallist@list.net. Письмо неподписанное. (А хоть бы и подписанное.) А дальше почтовой программе на этом list.net нужно разослать письмо с адресом From: user1@sender.com с почтовой программы, работающей на домене list.net всем адресатам в списке. Насколько я понял, подписать это письмо DKIM она не может, потому как доменная часть адреса во From: и домен, с которого собственно идет рассылка -- отличаются. И что?

Витя предложил подправить программку, обеспечивающую работу списка рассылки на предмет подстановки во From: адреса списка рассылки. А поскольку это писал какой-нибудь определенный человек, то чтобы сохранить хоть какую-то память об авторе письма, то предлагает подстановку типа:
(.*)<user1@sender.com> => $1<globallist@list.net>
Т.е. в комментариях мы сохраняем realname пользователя (если он там конечно есть), а в адрес подставляем адрес списка рассылки. Как пользователь Mac'а, который конечно же упрощает жизнь своим пользователям, я представляю, какая чехарда начнется в адресной книжке после
работы такого списка рассылки. Не говоря уже о том, что если пользователь не позаботился где-нибудь задать свой realname, то письма в список рассылки приобретут совсем анонимных характер.

Я что-то не так понял? А если я все понял правильно, то может у кого есть соображения, что можно в этой ситуации делать? Переходить на форум не предлагать.

Comments

[gul-kiev.livejournal.com]

Я тоже в прошлом году с этим столкнулся: http://gul-tech.livejournal.com/10862.html
Таки приходится подменять адрес в "From:" на адрес списка рассылки, а автора оставлять в Reply-To.

[kaa.livejournal.com]

добавлять вторую подпись от домена-баунсера (envelope-from)?

[vitus_wagner]

Рекомендовать пользователям не пользоваться гуглом. Он, кстати, и треды рвет, что в списках рассылки крайне неудобно.

На всех углах громко вопить "гмейл - это не электронная почта!!"

[tasic.livejournal.com]

Мне понравилось предложение в фб от Зубка, что во From подставлять адрес списка рассылки с комментарием "<real name of sender> via <maillist name>". С одной стороны это не должно запутывать всякие адресные книжки с именами пользователей, с другой должно проходить через DKIM. Пойду видимо minimalist править.

[tasic.livejournal.com]

Нельзя добавлять подпись, потому как софт списка рассылки модифицирует письмо. Обычно в списке рассылки модифицируется Subject, в само письмо добавляется footer. И подпись исходного письма в результате становится недействительной.

[tasic.livejournal.com]

Ну кричат. Ну давно. У меня достаточно много знакомых технарей, которые говорят: ну я перевел почту на гугл со своим доменом, потому как зачем мне морочиться самому с настройкой почты -- гугл все сделает для меня. Так что кричать-то можно...

[kaa.livejournal.com]

И? После этого нужно взять основные заголовки и подписать от домена, стоящего в return-path, уже после скрипта рассылки. Будет две подписи.

[tasic.livejournal.com]

Насколько я понимаю механизм, то после всего этого проверка первой подписи не пройдет. Механизм работает так, что берутся указанные заголовки, тела письма, строится хэш этого всего, кодируется приватным ключом и вставляется в заголовок. Теперь ты меняешь один из заголовков, участвовавших в построении хэша и собственно тело письма, которое тоже было в хэше. После этого проверка первой подписи уже не пройдет. Чтобы подписывать второй подписью и обе подписи правильно проверялись, ты можешь просто добавить какие-то заголовки в письмо, и подписать второй подписью. Больше ты ничего сделать не можешь, чтобы письмо таки проходило проверку первой подписи.

[kaa.livejournal.com]

всё верно. наплевать тогда на первую подпись?

[tasic.livejournal.com]

Ну мне кажется вставлять в письмо невалидную подпись хуже, чем не вставлять никакой. Поэтому таки похоже нужно подставлять другой From и подписывать своей подписью.

[kaa.livejournal.com]

мне почему-то думалось, что подпись по envelope-from не менее валидна, чем по from. я не прав?

[tasic.livejournal.com]

Я все еще читаю RFC, но кажется мне так, что плевать там на envelope-from. Им вынь да положь соответствие значения поля в d= тому, что находится во From:

[kaa.livejournal.com]

ну посмотри на рассылки IETF, там from не меняют:

Dec 14 18:46:58 zebra opendkim[909]: 0B1E4EBFE: message has signatures from ietf.org, fugue-com.20150623.gappssmtp.com
Dec 14 18:46:58 zebra opendkim[909]: 0B1E4EBFE: DKIM verification successful
Dec 14 18:46:58 zebra opendkim[909]: 0B1E4EBFE: s=ietf1 d=ietf.org SSL
Dec 14 18:46:58 zebra postfix/qmgr[72647]: 0B1E4EBFE: from=<dnsop-bounces@ietf.org>, size=8909, nrcpt=1 (queue active)

А вот что подписывает IETF:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1481737601; bh=97q9fBWTxogQOGIrg/dL870tvYGPCcLCLyuqDDe8taE=;
h=From:Date:In-Reply-To:To:References:Cc:Subject:List-Id:
List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;


[tasic.livejournal.com]

И какой у этого письма был From:? Не вижу смысла в такой подписи. У письма во From: стоит один адрес, идет оно с некоего другого домена, и при этом подписывается этим же доменом. А объясни тогда pls, а нафига при таком подходе вообще этот DKIM? От чего защищает?
Кстати, в следующем посте там в процессе экспериментов обнаружил еще одну... фичу gmail'а -- не получение своих писем, прошедших через alias. Тоже кривизна.