Victor Cheburkin wrote: > >>>>>>> 2. Здесь нет fallback на default domain на случай отсутствия файла с > >>>>>>> ключом, или я его не вижу? > >>>>>> > >>>>>> Если нет файла, нет подписи. Толку-то от fallback, если домен будет > >>>>>> другой? > >>>>> > >>>>> Я не эксперт по DKIM, но AFAIR нет такого требования, чтобы подпись была > >>>>> от того же самого домена, который во From. > >>>> > >>>> Гм. Вроде оно изначально -- подпись идет от домена отправителя. Если > >>> > >>> А в случае mailing list, который не переписывает From на себя, но > >>> модифицирует тело письма например? > >> > >> Это изначально больная тема. Еще с SPF. > > > > Но в случае DKIM как раз получается нормально: поменял письмо - взял > > ответственность на себя. > > Угу. Только вот доверия к такому письму уже не будет... Да и все проверяющие > системы, которые берут домен из From даже смотреть не будут на такую подпись. > Вот получаю я такое письмо, смотрю -- From один, подпись другая... Спам 99%. > И никому Ваша ответственность, в этом случае, не нужна... По крайней мере > пока.
Не все же проверяющие системы так топорно работают. Вот например что сообщает Gmail о подобном письме: http://admin.sibptus.ru/~vas/Screenshot_2019-01-03-13-31-04-965_com.google.android.gm.png С учетом того, что MX домена mpeks.tomsk.su находится в домене sibptus.ru и это легко проверить простым DNS-запросом, IMHO это правильный подход к DKIM-подписи. > > >>>> это Ваш поддомен, то да, можно не париться, но если нет -- какой тогда > >>>> в этом смысл? Я пишу от Вашего лица, но подписываю письмо своим > >>>> ключем? Где ж тогда гарантия, что пишете Вы? > >>> > >>> Если не для подтверждения подлинности отправителя, а для подтверждения > >>> того что письмо по дороге не менялось, то наверное может иметь смысл. \ > >> > >> Кому будет легче, если я отправлю письмо от Вашего имени и оно по дороге > >> не поменяется? > > > > Ну как минимум сразу будет видно, кто подделал мой From :-) > > Да, случай будет как со списками рассылки. Т.е. будет fail. По спецификации DKIM это вовсе не fail, если "From" и подписант различаются. Это вполне себе pass, если подпись подлинная. Хотя если по большому счету, в E-mail нельзя доверять ничему, кроме E2EE. > >>>>>>> 3. Селектор для всех доменов одинаковый, а вряд ли удастся этого > >>>>>>> достичь. > >>>>>> > >>>>>> Если селекторы разные, то лучше подумать, как узнавать какому домену > >>>>>> какой селектор. > >>>>> > >>>>> Ну я в изначальном письме предложил его хранить в файле > >>>>> ${domain}.selector.txt > >>>> > >>>> будет еще n файлов на n доменов. смысл? > >>> > >>> IMHO удобно такие вещи хранить в отдельных файликах, удалил-добавил файл > >>> вместе с удалением-добавлением домена. Скажем из текстового файла > >>> строчку из середины удалить или отредактировать - уже менее удобно, > >>> особенно если скриптом. > >> > >> Гм, не вижу проблемы со скриптами: sed справляется с этим без вопросов. > >> sed -i '/^domain\.com$/d' domainlist.file -- и нет более domain.com в этом > >> файле. > > > > Не хочу начинать holy war, но IMHO весьма неспроста в линуксах (и не > > только) пошла мода пилить конфиги на маленькие фрагменты и класть их в > > conf.d. Значит это даёт удобства. > > Holy war? Да все просто как угол дома -- при установке из пакета куда как > проще один файлик положить/удалить. (глядя на dovecot) И поэтому в _одном_ пакете конфиг побит на полста фрагментов? Что-то не сходится. > > > Это ведь по надежности при автоматизации совершенно разные решения: > > а) просто сказать "rm /etc/exim/somedomain.pem" и б) сгенерить sed script, > > который сделает что нужно, а потом запустить его с нужными правами. А > > если некорректно сгенерить - ещё и снесёт что-нибудь лишнее. > > > Не sed script, а скрипт, который сделает все нужные действия. Разные > вещи, не так ли? К тому же, имея скрипт -- имеем готовую процедуру, в > которой сложнее совершить ошибку чем в удалении пофайлово, а потом, > возможно, еще каких-то действиях. Но дело такое, лично мне все равно, > добавить sed или rm в скрипт, но смотреть мне удобнее в одном файле, а > не в 10, но это дело вкуса и, в любом случае, это немного уже не про > exim. Да, пора с этим заканчивать, а то придёт кто-нибудь и скажет, что единственно верный способ - хранить такую информацию в SQL, или в реестре. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ _______________________________________________ Exim-users mailing list Exim-users@mailground.net http://mailground.net/mailman/listinfo/exim-users
