Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
exim и greylist (!DKIM)
89 views
Skip to first unread message
Dmitry E. Oboukhov
Sep 18, 2017, 9:40:05 AM9/18/17
to
Имеется exim и greylistd. Все в целом работает норм, но иногда
задержки нормальной почты поддостают.
я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
имеет DKIM/senderid.
Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
грей а принимать с первого раза.
Как это грамотно настроить?
--
. ''`. Dmitry E. Oboukhov <un...@debian.org>
: :’ :
`. `~’ GPG key: 4096R/08EEA756 2014-08-30
`- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756
задержки нормальной почты поддостают.
я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
имеет DKIM/senderid.
Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
грей а принимать с первого раза.
Как это грамотно настроить?
--
. ''`. Dmitry E. Oboukhov <un...@debian.org>
: :’ :
`. `~’ GPG key: 4096R/08EEA756 2014-08-30
`- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756
Михаил Касаджиков
Sep 18, 2017, 4:00:05 PM9/18/17
to
Dmitry E. Oboukhov <un...@uvw.ru> писал(а) в своём письме Mon, 18 Sep 2017 16:06:02 +0300:
>> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
>> грей а принимать с первого раза.
>
> понятное дело что имеющие _валидные_ DKIM-подписи [и senderid]
Думаю, что использование переменной — самый простой способ. До DKIM у меня руки не дошли (лень), а для SPF я когда-то сделал так:
defer
condition = ${if eq {$acl_m_spf_code}{0}{no}{yes}}
!authenticated = *
…
Проверка SPF у меня раньше greylist и в ней устанавливается переменная acl_m_spf_code. 0 — SPF_PASS, остальные числа — варианты разной степени успешности прохождения проверки.
--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
>> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
>> грей а принимать с первого раза.
>
> понятное дело что имеющие _валидные_ DKIM-подписи [и senderid]
defer
condition = ${if eq {$acl_m_spf_code}{0}{no}{yes}}
!authenticated = *
…
Проверка SPF у меня раньше greylist и в ней устанавливается переменная acl_m_spf_code. 0 — SPF_PASS, остальные числа — варианты разной степени успешности прохождения проверки.
--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Andrey Jr. Melnikov
Sep 18, 2017, 4:10:04 PM9/18/17
to
Dmitry E. Oboukhov <un...@debian.org> wrote:
> [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
> Имеется exim и greylistd. Все в целом работает норм, но иногда
> задержки нормальной почты поддостают.
> я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> имеет DKIM/senderid.
> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> грей а принимать с первого раза.
> Как это грамотно настроить?
Никак.
Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
такой грейлистинг?
Впрочем, я тебя расстрою - еще больше спама ходит с валидным DKIM.
Спаммеры, они не исповедуют принцип "работает - не тронь", они все
новомодные фичи внедряют на раз-два не задумываясь, особенно если это
увеличивает количество проскочивших через фильтры писем.
> [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
> Имеется exim и greylistd. Все в целом работает норм, но иногда
> задержки нормальной почты поддостают.
> я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> имеет DKIM/senderid.
> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> грей а принимать с первого раза.
> Как это грамотно настроить?
Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
такой грейлистинг?
Впрочем, я тебя расстрою - еще больше спама ходит с валидным DKIM.
Спаммеры, они не исповедуют принцип "работает - не тронь", они все
новомодные фичи внедряют на раз-два не задумываясь, особенно если это
увеличивает количество проскочивших через фильтры писем.
Михаил Касаджиков
Sep 18, 2017, 4:20:02 PM9/18/17
to
Andrey Jr. Melnikov <temno...@gmail.com> писал(а) в своём письме Mon, 18 Sep 2017 23:03:19 +0300:
> Dmitry E. Oboukhov <un...@debian.org> wrote:
>> [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
>
>> Имеется exim и greylistd. Все в целом работает норм, но иногда
>> задержки нормальной почты поддостают.
>
>> я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
>> имеет DKIM/senderid.
>> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
>> грей а принимать с первого раза.
>
>> Как это грамотно настроить?
> Никак.
> Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> такой грейлистинг?
Ну, зато в ящике глаза мозолить не будет. Хотя, да, толку немного…
> Dmitry E. Oboukhov <un...@debian.org> wrote:
>> [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
>
>> Имеется exim и greylistd. Все в целом работает норм, но иногда
>> задержки нормальной почты поддостают.
>
>> я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
>> имеет DKIM/senderid.
>> Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
>> грей а принимать с первого раза.
>
>> Как это грамотно настроить?
> Никак.
> Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> такой грейлистинг?
Eugene Berdnikov
Sep 18, 2017, 5:10:02 PM9/18/17
to
On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
> Dmitry E. Oboukhov <un...@debian.org> wrote:
> > [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
>
> > Имеется exim и greylistd. Все в целом работает норм, но иногда
> > задержки нормальной почты поддостают.
>
> > я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> > имеет DKIM/senderid.
> > Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> > грей а принимать с первого раза.
>
> > Как это грамотно настроить?
> Никак.
> Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> такой грейлистинг?
Ну, принять письмо ещё не значит его доставить, вот такой грейлистинг.
> Dmitry E. Oboukhov <un...@debian.org> wrote:
> > [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
>
> > Имеется exim и greylistd. Все в целом работает норм, но иногда
> > задержки нормальной почты поддостают.
>
> > я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> > имеет DKIM/senderid.
> > Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> > грей а принимать с первого раза.
>
> > Как это грамотно настроить?
> Никак.
> Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> такой грейлистинг?
И Exim это уникальный МТА, который позволяет нарисовать грейлистинг на
стадии DATA легко и просто. Правда, подход этот слегка хреноватый
в плане экономии трафика и, возможно, неадекватного поведения разных
там мелкомягких МТА на 45x после DATA, но в целом вполне себе.
Особенно если цель экономить время юзеров, при безлимитном трафике,
широких каналах и скучающих без майнеров cpu. :)
> Впрочем, я тебя расстрою - еще больше спама ходит с валидным DKIM.
> Спаммеры, они не исповедуют принцип "работает - не тронь", они все
> новомодные фичи внедряют на раз-два не задумываясь, особенно если это
> увеличивает количество проскочивших через фильтры писем.
является применение полноценных MTA для рассылки. Так что те письма,
которые преодолевают традиционный грейлистинг (на стадии RCPT),
с гораздо большей вероятностью могут быть иметь валидные DKIM/SPF и даже
нижние Received:, имитирующие рилеи домена, нарисованного во From:, чем
те письма, которые через грейлистинг на стадии RCPT не прошли.
Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
--
Eugene Berdnikov
Andrey Jr. Melnikov
Sep 18, 2017, 5:10:04 PM9/18/17
to
Предлогаю начать с выкидывания spamassassin в мусор. На дврое XXI век - а
оно в 3х оставшихся русских кодировках не разбирается. Ну и до кучи -
медленное, тормозное. Заменить на rspamd - он быстрее и как-то адекватнее
фильтрует.
Andrey Jr. Melnikov
Sep 19, 2017, 5:40:03 AM9/19/17
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
> > Dmitry E. Oboukhov <un...@debian.org> wrote:
> > > [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
> >
> > > Имеется exim и greylistd. Все в целом работает норм, но иногда
> > > задержки нормальной почты поддостают.
> >
> > > я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> > > имеет DKIM/senderid.
> > > Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> > > грей а принимать с первого раза.
> >
> > > Как это грамотно настроить?
> > Никак.
> > Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> > такой грейлистинг?
> Ну, принять письмо ещё не значит его доставить, вот такой грейлистинг.
Грейлистинг - это не принять.
> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
> > Dmitry E. Oboukhov <un...@debian.org> wrote:
> > > [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 29 строк --]
> >
> > > Имеется exim и greylistd. Все в целом работает норм, но иногда
> > > задержки нормальной почты поддостают.
> >
> > > я полистал spam-detected от spamassassin и вижу, что 99.9% спама не
> > > имеет DKIM/senderid.
> > > Соответственно хочется письма имеющие DKIM/senderid не сплавлять в
> > > грей а принимать с первого раза.
> >
> > > Как это грамотно настроить?
> > Никак.
> > Чтоб проверить DKIM письмо надо принять. А если ты его принял, то какой
> > такой грейлистинг?
> Ну, принять письмо ещё не значит его доставить, вот такой грейлистинг.
> И Exim это уникальный МТА, который позволяет нарисовать грейлистинг на
> стадии DATA легко и просто. Правда, подход этот слегка хреноватый
> в плане экономии трафика и, возможно, неадекватного поведения разных
> там мелкомягких МТА на 45x после DATA, но в целом вполне себе.
> Особенно если цель экономить время юзеров, при безлимитном трафике,
> широких каналах и скучающих без майнеров cpu. :)
прочитает. Зато разборок - куда делась отправленная картинка с котиком из
очередной бесплатной помойки - станет сразу меньше.
> > Впрочем, я тебя расстрою - еще больше спама ходит с валидным DKIM.
> > Спаммеры, они не исповедуют принцип "работает - не тронь", они все
> > новомодные фичи внедряют на раз-два не задумываясь, особенно если это
> > увеличивает количество проскочивших через фильтры писем.
> А вот с этим полностью согласен. И добавлю, что одной из таких фич
> является применение полноценных MTA для рассылки. Так что те письма,
> которые преодолевают традиционный грейлистинг (на стадии RCPT),
> с гораздо большей вероятностью могут быть иметь валидные DKIM/SPF и даже
> нижние Received:, имитирующие рилеи домена, нарисованного во From:, чем
> те письма, которые через грейлистинг на стадии RCPT не прошли.
обычные MTA не применялись в спамометах. Они слишком умные и тормозные. А
то, что пробивает грейлистинг на стадии rctp to - умнее, т.к. похоже парсит
ответ и приходит ровно через 5/10 минут после.
> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
Sergey Matveev
Sep 19, 2017, 6:10:03 AM9/19/17
to
*** Andrey Jr. Melnikov <temno...@gmail.com> [2017-09-19 12:41]:
огромное количество спама, очень вот вероятно что больше 90%. А SPF --
согласен, мизерное количество.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
>> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
Не соглашусь. По своему личному опыту graylisting действительно убивает
>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
огромное количество спама, очень вот вероятно что больше 90%. А SPF --
согласен, мизерное количество.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Dmitry E. Oboukhov
Sep 19, 2017, 9:00:03 AM9/19/17
to
>>> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
>>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
> Не соглашусь. По своему личному опыту graylisting действительно убивает
> огромное количество спама, очень вот вероятно что больше 90%. А SPF --
> согласен, мизерное количество.
хм, я ведь анализировал тот спам что сквозь грейлист прошел, а
>>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
> Не соглашусь. По своему личному опыту graylisting действительно убивает
> огромное количество спама, очень вот вероятно что больше 90%. А SPF --
> согласен, мизерное количество.
количество непропущенного спама не анализировал.
так вот из того спама что грейлист прошел на 1000 сообщений примерно
4-5 валидно подписанных DKIM (моя статистика).
Вы думаете что те спамеры что не могут пробить greylist могут валидно
подписать DKIM? Там же подпись с DNS еще увязана
Dmitry E. Oboukhov
Sep 19, 2017, 9:20:03 AM9/19/17
to
On 16:05 Tue 19 Sep , Sergey Matveev wrote:
> *** Dmitry E. Oboukhov <un...@debian.org> [2017-09-19 16:01]:
> graylisting сказали что он не работает, а речь была про DKIM.
> Лично я про DKIM сейчас ничего не могу сказать, так как когда-то
> давно его проверял и видел что толку от этих проверок нет, как
> и с SPF, и поэтому сейчас уже давно его отключил.
я долго не настраивал DKIM на своем почтосервере (думал нафиг не
надо).
Столкнулся с тем что растет понемногу количество серверов которые НЕ
принимают почту без DKIM. Когда попала пара ключевых (для меня)
адресов в список "им я не могу написать", в итоге настроил себе DKIM.
ну и вот теперь разглядываю в свете настроенного свой лист со спамом и
вижу что если на валидный DKIM реагировать, то _кажется_ что можно
(пока во вс. случае) отказаться от грейлиста для таких писем.
> *** Dmitry E. Oboukhov <un...@debian.org> [2017-09-19 16:01]:
>> хм, я ведь анализировал тот спам что сквозь грейлист прошел, а
>> количество непропущенного спама не анализировал.
> Я похоже не понял ваше предыдущее письмо и подумал что вы про
>> количество непропущенного спама не анализировал.
> graylisting сказали что он не работает, а речь была про DKIM.
> Лично я про DKIM сейчас ничего не могу сказать, так как когда-то
> давно его проверял и видел что толку от этих проверок нет, как
> и с SPF, и поэтому сейчас уже давно его отключил.
я долго не настраивал DKIM на своем почтосервере (думал нафиг не
надо).
Столкнулся с тем что растет понемногу количество серверов которые НЕ
принимают почту без DKIM. Когда попала пара ключевых (для меня)
адресов в список "им я не могу написать", в итоге настроил себе DKIM.
ну и вот теперь разглядываю в свете настроенного свой лист со спамом и
вижу что если на валидный DKIM реагировать, то _кажется_ что можно
(пока во вс. случае) отказаться от грейлиста для таких писем.
Eugene Berdnikov
Sep 19, 2017, 5:50:03 PM9/19/17
to
On Tue, Sep 19, 2017 at 12:13:30PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
> > Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
> > переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
# greylist stats root@passat 0:08
> Eugene Berdnikov <b...@protva.ru> wrote:
> > Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
> > переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
Statistics since Tue Feb 13 16:22:00 2007 (3871 days and 8 hours ago)
---------------------------------------------------------------------
4202 items, matching 326526 requests, are currently whitelisted
0 items, matching 0 requests, are currently blacklisted
85 items, matching 142 requests, are currently greylisted
Of 16268935 items that were initially greylisted:
- 1772014 ( 10.9%) became whitelisted
- 14496921 ( 89.1%) expired from the greylist
# greylist stats root@typhoon 0:08
Statistics since Tue Feb 13 16:22:00 2007 (3871 days and 8 hours ago)
---------------------------------------------------------------------
3729 items, matching 336816 requests, are currently whitelisted
0 items, matching 0 requests, are currently blacklisted
61 items, matching 113 requests, are currently greylisted
Of 15201268 items that were initially greylisted:
- 1714227 ( 11.3%) became whitelisted
- 13487041 ( 88.7%) expired from the greylist
# greylist stats root@tornado 0:09
Statistics
----------
3729 items, matching 350488 requests, are currently whitelisted
0 items, matching 0 requests, are currently blacklisted
61 items, matching 113 requests, are currently greylisted
Of 11104242 items that were initially greylisted:
- 1328121 ( 12.0%) became whitelisted
- 9776121 ( 88.0%) expired from the greylist
# greylist stats root@citrine 0:09
Statistics
----------
3812 items, matching 374019 requests, are currently whitelisted
0 items, matching 0 requests, are currently blacklisted
63 items, matching 115 requests, are currently greylisted
Of 11206337 items that were initially greylisted:
- 1339635 ( 12.0%) became whitelisted
- 9866702 ( 88.0%) expired from the greylist
Правда, тут не чистая статистика, а после выполнения sender verify.
Так что подтвердить слова о 97-98% не могу, но утверждение о том, что
грейлистинг "давно не работает", это явно преувеличение. :)
А вот эффект от проверки SPF действительно весьма скромный.
--
Eugene Berdnikov
Tim Sattarov
Sep 19, 2017, 6:10:02 PM9/19/17
to
On 09/19/17 17:48, Eugene Berdnikov wrote:
> On Tue, Sep 19, 2017 at 12:13:30PM +0300, Andrey Jr. Melnikov wrote:
>> Eugene Berdnikov <b...@protva.ru> wrote:
>>> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
>>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
>
> On Tue, Sep 19, 2017 at 12:13:30PM +0300, Andrey Jr. Melnikov wrote:
>> Eugene Berdnikov <b...@protva.ru> wrote:
>>> Ну а поскольку грейлистинг на стадии RCPT убивает 97-98% спама, то
>>> переность его на стадию DATA ради привязки к DKIM нет никакого смысла.
>> Да не убивает он ничего уже давно, как и SPF. Так, только делает вид.
>
> А вот эффект от проверки SPF действительно весьма скромный.
Сейчас в чести другие акронимы: DKIM, DMARC...
Ivan Shmakov
Oct 1, 2017, 4:00:02 AM10/1/17
to
>>>>> Andrey Jr Melnikov <temno...@gmail.com> writes:
>>>>> Eugene Berdnikov <b...@protva.ru> wrote:
>>>>> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
[…]
>>>>> Eugene Berdnikov <b...@protva.ru> wrote:
>>>>> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
>>> Впрочем, я тебя расстрою — еще больше спама ходит с валидным DKIM.
>>> Спаммеры, они не исповедуют принцип «работает — не тронь», они все
>>> новомодные фичи внедряют на раз-два не задумываясь, особенно если
>>> это увеличивает количество проскочивших через фильтры писем.
>> А вот с этим полностью согласен. И добавлю, что одной из таких фич
>> является применение полноценных MTA для рассылки. Так что те письма,
>> которые преодолевают традиционный грейлистинг (на стадии RCPT), с
>> гораздо большей вероятностью могут быть иметь валидные DKIM/SPF и
>> даже нижние Received:, имитирующие рилеи домена, нарисованного во
>> From:, чем те письма, которые через грейлистинг на стадии RCPT не
>> прошли.
> Я тебе открою страшную тайну — со времен «центра американского
>>> это увеличивает количество проскочивших через фильтры писем.
>> А вот с этим полностью согласен. И добавлю, что одной из таких фич
>> является применение полноценных MTA для рассылки. Так что те письма,
>> которые преодолевают традиционный грейлистинг (на стадии RCPT), с
>> гораздо большей вероятностью могут быть иметь валидные DKIM/SPF и
>> даже нижние Received:, имитирующие рилеи домена, нарисованного во
>> From:, чем те письма, которые через грейлистинг на стадии RCPT не
>> прошли.
> английского» обычные MTA не применялись в спамометах. Они слишком
> умные и тормозные.
Не уверен.
> умные и тормозные.
Был тут один настойчивый нарушитель. Последняя активность была
с адресов AS24875 (вроде 77.220.213.13 IN PTR fastmstart.bid.,
185.213.209.120 IN PTR valdis-k.bid., etc.); до этого — AS48666,
AS201094.
Было очень похоже, что на используемых IP работал именно
полновесный MTA. (Если верить 220 — Exim.)
> А то, что пробивает грейлистинг на стадии rcpt to — умнее,
> т. к. похоже парсит ответ и приходит ровно через 5/10 минут после.
То, что мне приходило в обход greylisting, в основном шло через
бесплатные ресурсы — вроде Google Mail, Yahoo, etc.
Адреса Yahoo пришлось перечислить в local_host_blacklist,
поскольку ценной корреспонденции с них я не припоминаю вовсе.
[…]
--
FSF associate member #7257 http://am-1.org/~ivan/ 7D17 4A59 6A21 3D97 6DDB
yuri.n...@gmail.com
Oct 1, 2017, 4:30:03 PM10/1/17
to
On Sun, 1 Oct 2017, Ivan Shmakov wrote:
>
> Адреса Yahoo пришлось перечислить в local_host_blacklist,
> поскольку ценной корреспонденции с них я не припоминаю вовсе.
>
Вот, вот. Вот так же админы одного из серверов решили,
>
> Адреса Yahoo пришлось перечислить в local_host_blacklist,
> поскольку ценной корреспонденции с них я не припоминаю вовсе.
>
что подлый жмаил исчадье спама. Письмо с него просто не дошло.
> ** Message not delivered **
>
> Learn more here: http://www.sorbs.net/lookup.shtml?209.85.215.42
Такое ощущение, что труд по написанию пропавшего письма, это такая
мелочь по сравнения с доблестным трудом по отражению члено-сисько
увеличителей с возможностью бесплатно обогатиться и помочь
родственникам принца Имена-рек.
В личной беседе я узнал, что email это пережиток прошлого и
мне надо было позвонить по телефону...
Ю.
p.s. У меня есть несколько знакомых с адресами от yahoo.
Почту они там завели еще в прошлом веке и почему то не видят
причин ее менять.
Eugene Berdnikov
Oct 1, 2017, 6:30:02 PM10/1/17
to
On Sun, Oct 01, 2017 at 11:23:03PM +0300, yuri.n...@gmail.com wrote:
> p.s. У меня есть несколько знакомых с адресами от yahoo.
> Почту они там завели еще в прошлом веке и почему то не видят
> причин ее менять.
Помнится, в начале этого года один товарищ в exim-users играл с Yahoo
> p.s. У меня есть несколько знакомых с адресами от yahoo.
> Почту они там завели еще в прошлом веке и почему то не видят
> причин ее менять.
в игру "Угадай, отчего режектится твой мейл". :) Ему предлагали искать
причину методом последовательного исключения хедеров, так как набранный
в telnet'е тестовый мейл успешно доставлялся. Не знаю, чем его изыскания
закончились, но по моему мнению почта на *публичный* хостинг должна
проходить, а не отскакивать, даже если классификатор посчитал её спамом.
За ним приходили другие, плакались на yahoo-шный SSL для SMTP. Беда,
многие MTA не умеют при ошибке ssl-ного хендшейка откатываться на
plain SMTP, и возвращают мейл отправителю.
Правда, это не повод банить Yahoo, как предлагают здесь экстремисты.
Но повод задуматься о том, стоит ли им пользоваться.
--
Eugene Berdnikov
Ivan Shmakov
Oct 1, 2017, 11:00:02 PM10/1/17
to
>>>>> yuri nefedov <yuri.n...@gmail.com> writes:
>>>>> On Sun, 1 Oct 2017, Ivan Shmakov wrote:
>> Адреса Yahoo пришлось перечислить в local_host_blacklist, поскольку
>> ценной корреспонденции с них я не припоминаю вовсе.
> Вот, вот. Вот так же админы одного из серверов решили, что подлый
> жмаил исчадье спама. Письмо с него просто не дошло.
Справедливости ради, с Gmail тоже идет немало нежелательных
>>>>> On Sun, 1 Oct 2017, Ivan Shmakov wrote:
>> Адреса Yahoo пришлось перечислить в local_host_blacklist, поскольку
>> ценной корреспонденции с них я не припоминаю вовсе.
> Вот, вот. Вот так же админы одного из серверов решили, что подлый
> жмаил исчадье спама. Письмо с него просто не дошло.
сообщений. Но вот почему-то с Yahoo — больше. Чем-то он,
видимо, привлекателен для данного класса «пользователей».
При этом, ясно, что едва ли не единственный способ повлиять на
их политику (предполагая, что именно в ней причина) — не
принимать от них почту.
>> ** Message not delivered **
>> Learn more here: http://www.sorbs.net/lookup.shtml?209.85.215.42
> Такое ощущение, что труд по написанию пропавшего письма, это такая
> мелочь
[…]
> В личной беседе я узнал, что email это пережиток прошлого и мне надо
Известная проблема. Задолжал я тут порядка 2 USD одной
компании. Попытался получить доступ к «личному кабинету» —
отказ. («Восстановление пароля» проходит, но не далее.)
Контактных email не обнаружилось; на «подобранные» реакции не
последовало.
Видимо, не так уж им нужны мои деньги.
> p.s. У меня есть несколько знакомых с адресами от yahoo. Почту они
У порядка трех пользователей, которых обслуживает мой MTA, таких
знакомых, насколько мне известно, — нет.
yuri.n...@gmail.com
Oct 2, 2017, 3:40:03 AM10/2/17
to
On Mon, 2 Oct 2017, Ivan Shmakov wrote:
> > Такое ощущение, что труд по написанию пропавшего письма, это такая
> > мелочь
>
> Пропавшего? Так ведь во всех приличных MUA есть «отправленные»?
>
Я же письмо не для себя писал. Оно пропало для получателя.
> > Такое ощущение, что труд по написанию пропавшего письма, это такая
> > мелочь
>
> Пропавшего? Так ведь во всех приличных MUA есть «отправленные»?
>
Как то даже не по себе, объяснять такие простые вещи.
Ю.
Ivan Shmakov
Oct 3, 2017, 8:00:03 AM10/3/17
to
Поскольку смысл борьбы с нежелательной корреспонденцией как
раз и состоит в том, чтобы /некоторые/ письма «пропадали» для
получателя.
2. Если недоставка конкретного письма является проблемой,
получатель всегда может обратиться к администратору узла с
просьбой ее решить.
3. При невозможности (нежелании) решать проблему ответственным
лицом — получатель как правило может найти иной (в частности
— «бесплатный») почтовый ящик.
4. Отправитель, в свою очередь, может обратиться к
администраторам /своего/ почтового узла, с просьбой внести
поправки в их политику (или практику ее применения), чтобы
исключить случаи злоупотреблений — которые обычно и приводят
к включению почтовых узлов в «черные списки».
5. Иначе, отправитель так же может найти иной почтовый узел.
6. Наконец, отправитель может найти иной способ связаться с
получателем. Подчеркну, что в этом случае (как, впрочем, и в
предыдущих), «труд по написанию» не оказывается напрасным —
коль скоро письмо можно переслать с нового адреса отправителя.
(Или на новый адрес получателя. Или даже зачитать по телефону.)
Я понимаю, что в идеальном мире электронная почта работает
несколько более надежно. OTOH, в оном не возникает и проблемы
нежелательной корреспонденции.
Коротаев Руслан
Oct 3, 2017, 9:30:03 AM10/3/17
to
В сообщении от [Вт 2017-10-03 11:33 +0000]
Ivan Shmakov <iv...@siamics.net> пишет:
> 1. Был ли получатель заинтересован в получении этого письма?
> Поскольку смысл борьбы с нежелательной корреспонденцией как
> раз и состоит в том, чтобы /некоторые/ письма «пропадали» для
> получателя.
У вас проблемы с DKIM, у меня при проверке выдает «fail (message has
been altered)», уже несколько писем таких было. Его или отключить или
настроить, иначе ваши письма могут пропадать, если у получателей
настроена строгая проверка DKIM.
Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
поэтому счел уместным об этом написать.
--
Коротаев Руслан
https://blog.kr.pp.ru
Ivan Shmakov <iv...@siamics.net> пишет:
> 1. Был ли получатель заинтересован в получении этого письма?
> Поскольку смысл борьбы с нежелательной корреспонденцией как
> раз и состоит в том, чтобы /некоторые/ письма «пропадали» для
> получателя.
been altered)», уже несколько писем таких было. Его или отключить или
настроить, иначе ваши письма могут пропадать, если у получателей
настроена строгая проверка DKIM.
Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
поэтому счел уместным об этом написать.
--
Коротаев Руслан
https://blog.kr.pp.ru
Ivan Shmakov
Oct 3, 2017, 10:10:02 AM10/3/17
to
>>>>> Руслан Коротаев <subs...@mail.kr.pp.ru> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> пишет:
>> 1. Был ли получатель заинтересован в получении этого письма?
>> Поскольку смысл борьбы с нежелательной корреспонденцией как раз и
>> состоит в том, чтобы /некоторые/ письма «пропадали» для получателя.
> У вас проблемы с DKIM, у меня при проверке выдает «fail (message has
> been altered)», уже несколько писем таких было. Его или отключить или
> настроить, иначе ваши письма могут пропадать, если у получателей
> настроена строгая проверка DKIM.
> Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
> поэтому счел уместным об этом написать.
ACK, благодарю за информацию. Похоже, однако, что в этом случае
>>>>> Ivan Shmakov <iv...@siamics.net> пишет:
>> 1. Был ли получатель заинтересован в получении этого письма?
>> Поскольку смысл борьбы с нежелательной корреспонденцией как раз и
>> состоит в том, чтобы /некоторые/ письма «пропадали» для получателя.
> У вас проблемы с DKIM, у меня при проверке выдает «fail (message has
> been altered)», уже несколько писем таких было. Его или отключить или
> настроить, иначе ваши письма могут пропадать, если у получателей
> настроена строгая проверка DKIM.
> Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
> поэтому счел уместным об этом написать.
проблема в рассылке. (Или, возможно, в том, как конкретно
DKIM-подписи с моего MTA проходят через рассылку.)
Отправил проверочное письмо на check-auth at verifier dot port25
dot com ($ swaks --server=ip6-localhost --from=ivan@XXX
--header=Subject:" test " --to=check-auth@YYY) и получил в ответ:
DKIM check details:
----------------------------------------------------------
Result: pass (matches From: iv...@siamics.net)
Кроме того, в заголовке сообщения в архиве рассылки [1]
обнаруживаю:
X-Virus-Scanned: at lists.debian.org with policy bank lang-slavic
X-Amavis-Spam-Status: No, score=-1 tagged_above=-10000 required=5.3
tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, FOURLA=0.1, GMAIL=1]
autolearn=no autolearn_force=no
Так что по меньшей мере lists.debian.org эту подпись принял.
[1] nntp://news.gmane.org/gmane.linux.debian.user.russian/126685
Eugene Berdnikov
Oct 3, 2017, 10:30:02 AM10/3/17
to
On Tue, Oct 03, 2017 at 01:50:27PM +0000, Ivan Shmakov wrote:
> >>>>> Руслан Коротаев <subs...@mail.kr.pp.ru> writes:
> > Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
> > поэтому счел уместным об этом написать.
>
> ACK, благодарю за информацию. Похоже, однако, что в этом случае
> проблема в рассылке. (Или, возможно, в том, как конкретно
> DKIM-подписи с моего MTA проходят через рассылку.)
Посмотрите список заголовков, подписанный вашим DKIM. Там есть такие,
> >>>>> Руслан Коротаев <subs...@mail.kr.pp.ru> writes:
> > Не следил за дискуссией по этой теме, но вижу что есть слово DKIM,
> > поэтому счел уместным об этом написать.
>
> ACK, благодарю за информацию. Похоже, однако, что в этом случае
> проблема в рассылке. (Или, возможно, в том, как конкретно
> DKIM-подписи с моего MTA проходят через рассылку.)
которые заведомо модифицируются шлюзом рассылки, например Resent-From:
и Resent-Message-Id:. Подобные заголовки уместно включать в подпись
лишь на выделенном для рассылки рилее.
--
Eugene Berdnikov
Artem Chuprina
Oct 3, 2017, 11:40:03 AM10/3/17
to
Ivan Shmakov -> debian-...@lists.debian.org @ Tue, 03 Oct 2017 11:33:44 +0000:
>> Я же письмо не для себя писал. Оно пропало для получателя. Как то
>> даже не по себе, объяснять такие простые вещи.
> 1. Был ли получатель заинтересован в получении этого письма?
> Поскольку смысл борьбы с нежелательной корреспонденцией как
> раз и состоит в том, чтобы /некоторые/ письма «пропадали» для
> получателя.
> 2. Если недоставка конкретного письма является проблемой,
> получатель всегда может обратиться к администратору узла с
> просьбой ее решить.
Тут есть очевидная проблема: получатель _своевременно_ не знает, что
письмо было ему отправлено, поскольку он его не получил.
При молчаливом выбрасывании письма почтовкой у отправителя сходная
проблема: он тоже _своевременно_ не знает, что его письмо не было
доставлено.
>> Я же письмо не для себя писал. Оно пропало для получателя. Как то
>> даже не по себе, объяснять такие простые вещи.
> 1. Был ли получатель заинтересован в получении этого письма?
> Поскольку смысл борьбы с нежелательной корреспонденцией как
> раз и состоит в том, чтобы /некоторые/ письма «пропадали» для
> получателя.
> 2. Если недоставка конкретного письма является проблемой,
> получатель всегда может обратиться к администратору узла с
> просьбой ее решить.
письмо было ему отправлено, поскольку он его не получил.
При молчаливом выбрасывании письма почтовкой у отправителя сходная
проблема: он тоже _своевременно_ не знает, что его письмо не было
доставлено.
Andrey Jr. Melnikov
Oct 3, 2017, 6:10:02 PM10/3/17
to
Ivan Shmakov <iv...@siamics.net> wrote:
> >>>>> Andrey Jr Melnikov <temno...@gmail.com> writes:
> >>>>> Eugene Berdnikov <b...@protva.ru> wrote:
> >>>>> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
[???]
> >>>>> Andrey Jr Melnikov <temno...@gmail.com> writes:
> >>>>> Eugene Berdnikov <b...@protva.ru> wrote:
> >>>>> On Mon, Sep 18, 2017 at 11:03:19PM +0300, Andrey Jr. Melnikov wrote:
> > Я тебе открою страшную тайну ??? со времен ??центра американского
> > английского?? обычные MTA не применялись в спамометах. Они слишком
> > умные и тормозные.
> Не уверен.
> Был тут один настойчивый нарушитель. Последняя активность была
> с адресов AS24875 (вроде 77.220.213.13 IN PTR fastmstart.bid.,
> 185.213.209.120 IN PTR valdis-k.bid., etc.); до этого ??? AS48666,
> Не уверен.
> Был тут один настойчивый нарушитель. Последняя активность была
> с адресов AS24875 (вроде 77.220.213.13 IN PTR fastmstart.bid.,
> AS201094.
> Было очень похоже, что на используемых IP работал именно
> полновесный MTA. (Если верить 220 ??? Exim.)
> Было очень похоже, что на используемых IP работал именно
То, что рассылает письма и то что отвечает на 25 порту - это обычно разные
вещи. Да и эксим - хреновый эмиттер, он как ресивер хорош.
Ivan Shmakov
Oct 4, 2017, 10:50:03 AM10/4/17
to
Действительно, я не задавал значения для DKIM_SIGN_HEADERS
(dkim_sign_headers) в конфигурации Exim. (Фрагмент которой на
всякий случай привожу отдельной MIME-частью.) Согласно
документации [1], в этом случае используется рекомендуемый
RFC 4871 (ныне obsolete) список заголовков — который включает
в том числе Sender:, а равно некоторые Resent- и List-.
После просмотра RFC 6376, RFC 6377 на предмет текущих
рекомендаций у меня сложилось впечатление, что такого рода
заголовки действительно следует включать в подпись главным
образом при их наличии в сообщении. Любопытно, есть ли готовые
примеры настройки Exim таким образом?
Можно поспорить, однако, что их может быть полезно включать и
в противном случае — если заведомо известно, что сообщение не
предназначено для каких-либо рассылок.
(Так или иначе, полагаю, нынешнее умолчание просит bug report.)
[1] http://exim.org/exim-html-current/doc/html/spec_html/ch-support_for_dkim_domainkeys_identified_mail.html
Andrey Jr. Melnikov
Oct 4, 2017, 12:10:02 PM10/4/17
to
Ivan Shmakov <iv...@siamics.net> wrote:
[...]
> Действительно, я не задавал значения для DKIM_SIGN_HEADERS
> (dkim_sign_headers) в конфигурации Exim. (Фрагмент которой на
> всякий случай привожу отдельной MIME-частью.) Согласно
> документации [1], в этом случае используется рекомендуемый
> RFC 4871 (ныне obsolete) список заголовков ??? который включает
использованны все заголовки, которые ниже подписи, иначе это какая-то
профанация а не подпись.
> Можно поспорить, однако, что их может быть полезно включать и
> в противном случае ??? если заведомо известно, что сообщение не
рассылки, который ниразу не DKIM-aware.
[...]
> Действительно, я не задавал значения для DKIM_SIGN_HEADERS
> (dkim_sign_headers) в конфигурации Exim. (Фрагмент которой на
> всякий случай привожу отдельной MIME-частью.) Согласно
> документации [1], в этом случае используется рекомендуемый
> в том числе Sender:, а равно некоторые Resent- и List-.
> После просмотра RFC 6376, RFC 6377 на предмет текущих
> рекомендаций у меня сложилось впечатление, что такого рода
> заголовки действительно следует включать в подпись главным
> образом при их наличии в сообщении. Любопытно, есть ли готовые
> примеры настройки Exim таким образом?
Есть. Стереть эту ересь из конфига. В момент подписи письма - будут
> После просмотра RFC 6376, RFC 6377 на предмет текущих
> рекомендаций у меня сложилось впечатление, что такого рода
> заголовки действительно следует включать в подпись главным
> образом при их наличии в сообщении. Любопытно, есть ли готовые
> примеры настройки Exim таким образом?
использованны все заголовки, которые ниже подписи, иначе это какая-то
профанация а не подпись.
> Можно поспорить, однако, что их может быть полезно включать и
> предназначено для каких-либо рассылок.
> (Так или иначе, полагаю, нынешнее умолчание просит bug report.)
Два. Первый на дефолтный конфиг эксима в дебане, второй - на софт списка
> (Так или иначе, полагаю, нынешнее умолчание просит bug report.)
рассылки, который ниразу не DKIM-aware.
Eugene Berdnikov
Oct 4, 2017, 1:10:02 PM10/4/17
to
On Wed, Oct 04, 2017 at 02:25:23PM +0000, Ivan Shmakov wrote:
> DKIM_SIGN_HEADERS = Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From:Reply-To:Cc:Content-ID:Content-Description
По моему скромному мнению, для рассылок следует ограничиться подписью
заголовков From, To, Cc, Date и Message-Id, плюс, возможно, Reply-To,
In-Reply-To и References. При этом не следует подписывать тело (body).
Все остальные заголовки могут быть модифицированы: в Subject иногда
префиксом [..] вставляется название списка, шлюз также может поменять
Content-Transfer-Encoding и добавить в тело футер разными способами,
в том числе изменив Content-type (некоторые шлюзы так делают, если
тело содержит HTML).
--
Eugene Berdnikov
> DKIM_SIGN_HEADERS = Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From:Reply-To:Cc:Content-ID:Content-Description
По моему скромному мнению, для рассылок следует ограничиться подписью
заголовков From, To, Cc, Date и Message-Id, плюс, возможно, Reply-To,
In-Reply-To и References. При этом не следует подписывать тело (body).
Все остальные заголовки могут быть модифицированы: в Subject иногда
префиксом [..] вставляется название списка, шлюз также может поменять
Content-Transfer-Encoding и добавить в тело футер разными способами,
в том числе изменив Content-type (некоторые шлюзы так делают, если
тело содержит HTML).
--
Eugene Berdnikov
Ivan Shmakov
Oct 4, 2017, 1:30:02 PM10/4/17
to
>>>>> Eugene Berdnikov <b...@protva.ru> writes:
[…]
> Правда, это не повод банить Yahoo, как предлагают здесь
Не вполне понимаю, о каких предложениях идет речь, но JFTR:
я лишь привел информацию о подходе, которого фактически
придерживаюсь. Без каких-либо рассуждений «за» или «против».
Надо сказать, что я в целом делаю много того, чего не
рекомендую. Вот, к примеру, не далее, как в июне, обновил
Debian через версию…
> экстремисты.
Это такой намек на то, что предлагающим следует давать
«от двух до шести»?
> Но повод задуматься о том, стоит ли им пользоваться.
Поддерживаю.
[…]
> Правда, это не повод банить Yahoo, как предлагают здесь
я лишь привел информацию о подходе, которого фактически
придерживаюсь. Без каких-либо рассуждений «за» или «против».
Надо сказать, что я в целом делаю много того, чего не
рекомендую. Вот, к примеру, не далее, как в июне, обновил
Debian через версию…
> экстремисты.
Это такой намек на то, что предлагающим следует давать
«от двух до шести»?
> Но повод задуматься о том, стоит ли им пользоваться.
Ivan Shmakov
Oct 4, 2017, 1:50:01 PM10/4/17
to
>>>>> Eugene Berdnikov <b...@protva.ru> writes:
>>>>> On Wed, Oct 04, 2017 at 02:25:23PM +0000, Ivan Shmakov wrote:
>> DKIM_SIGN_HEADERS =
>> Content-Transfer-Encoding:Content-Type:MIME-Version
>> :Message-ID:In-Reply-To:Date:References:Subject:To:From:Reply-To:Cc
>> :Content-ID:Content-Description
> По моему скромному мнению, для рассылок следует ограничиться
> подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> Reply-To, In-Reply-To и References.
Задача определения, идет ли письмо в рассылку или нет, не
>>>>> On Wed, Oct 04, 2017 at 02:25:23PM +0000, Ivan Shmakov wrote:
>> DKIM_SIGN_HEADERS =
>> Content-Transfer-Encoding:Content-Type:MIME-Version
>> :Message-ID:In-Reply-To:Date:References:Subject:To:From:Reply-To:Cc
>> :Content-ID:Content-Description
> По моему скромному мнению, для рассылок следует ограничиться
> подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> Reply-To, In-Reply-To и References.
кажется мне тривиальной. Но если есть конкретные примеры
настройки Exim для этого — я не против на них взглянуть.
> При этом не следует подписывать тело (body).
возможность отправить условный «$$$ make money fast $$$» с моим
заголовком и /действительной/ подписью моего MTA?
> Все остальные заголовки могут быть модифицированы: в Subject иногда
> префиксом [..] вставляется название списка, шлюз также может поменять
> Content-Transfer-Encoding и добавить в тело футер разными способами,
> в том числе изменив Content-type (некоторые шлюзы так делают, если
> тело содержит HTML).
я так думаю, ее администратор уже вполне может взять на себя
ответственность за распространение пересылаемых сообщений и
настроить их подписывание ключом своего узла.
Eugene Berdnikov
Oct 4, 2017, 2:50:03 PM10/4/17
to
On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > По моему скромному мнению, для рассылок следует ограничиться
> > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > Reply-To, In-Reply-To и References.
>
> Задача определения, идет ли письмо в рассылку или нет, не
> кажется мне тривиальной.
Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > По моему скромному мнению, для рассылок следует ограничиться
> > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > Reply-To, In-Reply-To и References.
>
> Задача определения, идет ли письмо в рассылку или нет, не
> кажется мне тривиальной.
тогда везде будет меньше проблем, в том числе в рассылках.
> > При этом не следует подписывать тело (body).
>
> Прошу прощения? Другими словами, предоставить злоумышленнику
> заголовком и /действительной/ подписью моего MTA?
Злоумышленник будет больше озадачен тем, как подделать обратный адрес
на транспортном уровне, т.е. в envelope_from. Потому как MTA именно его
обычно проверяют -- применяют SPF, грейлистинг и т.д. А те, кто ведётся
на "make money fast", они не только про DKIM ничего не слышали, они
вообще не догадываются, что в письме может быть какая-то ложь. :)
> > Все остальные заголовки могут быть модифицированы: в Subject иногда
> > префиксом [..] вставляется название списка, шлюз также может поменять
> > Content-Transfer-Encoding и добавить в тело футер разными способами,
> > в том числе изменив Content-type (некоторые шлюзы так делают, если
> > тело содержит HTML).
>
> Если рассылка вносит сколь угодно существенные изменения,
> я так думаю, ее администратор уже вполне может взять на себя
> ответственность за распространение пересылаемых сообщений и
> настроить их подписывание ключом своего узла.
перед форвардом в рассылку. Но мы ведь сейчас обсуждаем что делать
если админ шлюза даже этим не озаботился.
--
Eugene Berdnikov
Andrey Jr. Melnikov
Oct 4, 2017, 4:40:02 PM10/4/17
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > По моему скромному мнению, для рассылок следует ограничиться
> > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > Reply-To, In-Reply-To и References.
> >
> > Задача определения, идет ли письмо в рассылку или нет, не
> > кажется мне тривиальной.
> Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> тогда везде будет меньше проблем, в том числе в рассылках.
Даа, далека криптография от народа, очень далека.
> On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > По моему скромному мнению, для рассылок следует ограничиться
> > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > Reply-To, In-Reply-To и References.
> >
> > Задача определения, идет ли письмо в рассылку или нет, не
> > кажется мне тривиальной.
> Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> тогда везде будет меньше проблем, в том числе в рассылках.
> > > При этом не следует подписывать тело (body).
> >
> > Прошу прощения? Другими словами, предоставить злоумышленнику
> > возможность отправить условный ??$$$ make money fast $$$?? с моим
> > заголовком и /действительной/ подписью моего MTA?
> Злоумышленник будет больше озадачен тем, как подделать обратный адрес
> на транспортном уровне, т.е. в envelope_from. Потому как MTA именно его
> обычно проверяют -- применяют SPF, грейлистинг и т.д. А те, кто ведётся
> на "make money fast", они не только про DKIM ничего не слышали, они
> вообще не догадываются, что в письме может быть какая-то ложь. :)
отлуп было отправить. А вот письмо, которое в предложенном тобой варианте
будет как-то подписано тобой, видоизмененнное до "слезных расказов дочери
старшего инструктора организации запрещенной в россии (тм)" может больно
стукнуть. И ведь не отмажешься - подписи твои и верные.
> > > Все остальные заголовки могут быть модифицированы: в Subject иногда
> > > префиксом [..] вставляется название списка, шлюз также может поменять
> > > Content-Transfer-Encoding и добавить в тело футер разными способами,
> > > в том числе изменив Content-type (некоторые шлюзы так делают, если
> > > тело содержит HTML).
> >
> > Если рассылка вносит сколь угодно существенные изменения,
> > я так думаю, ее администратор уже вполне может взять на себя
> > ответственность за распространение пересылаемых сообщений и
> > настроить их подписывание ключом своего узла.
> Достаточно просто снести нахрен все заголовки DKIM из входящего письма
> перед форвардом в рассылку. Но мы ведь сейчас обсуждаем что делать
> если админ шлюза даже этим не озаботился.
отдельный контенйнер и разошлет. Их таких есть, но в дебиане -
стааабииильность, даа!
Andrey Jr. Melnikov
Oct 4, 2017, 4:40:03 PM10/4/17
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Sun, Oct 01, 2017 at 11:23:03PM +0300, yuri.n...@gmail.com wrote:
> > p.s. У меня есть несколько знакомых с адресами от yahoo.
> > Почту они там завели еще в прошлом веке и почему то не видят
> > причин ее менять.
[...]
> On Sun, Oct 01, 2017 at 11:23:03PM +0300, yuri.n...@gmail.com wrote:
> > p.s. У меня есть несколько знакомых с адресами от yahoo.
> > Почту они там завели еще в прошлом веке и почему то не видят
> > причин ее менять.
> Правда, это не повод банить Yahoo, как предлагают здесь экстремисты.
> Но повод задуматься о том, стоит ли им пользоваться.
https://techcrunch.com/2017/10/03/yahoo-says-all-3b-accounts-were-impacted-by-2013-breach-not-1b-as-thought/
становиться понятно, откуда там столько спама. Впрочем, если учесть, что
yahoo древнейшная почтовая помойка и юзерей с паролями 123456 и qwerty там
тысячами уже было.
Eugene Berdnikov
Oct 4, 2017, 5:40:02 PM10/4/17
to
On Wed, Oct 04, 2017 at 11:31:08PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
> > On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > > По моему скромному мнению, для рассылок следует ограничиться
> > > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > > Reply-To, In-Reply-To и References.
> > >
> > > Задача определения, идет ли письмо в рассылку или нет, не
> > > кажется мне тривиальной.
> > Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> > тогда везде будет меньше проблем, в том числе в рассылках.
>
> Даа, далека криптография от народа, очень далека.
Да не, криптография уже близка: у нас, например, mail.ru и yandex.ru уже
> Eugene Berdnikov <b...@protva.ru> wrote:
> > On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > > По моему скромному мнению, для рассылок следует ограничиться
> > > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > > Reply-To, In-Reply-To и References.
> > >
> > > Задача определения, идет ли письмо в рассылку или нет, не
> > > кажется мне тривиальной.
> > Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> > тогда везде будет меньше проблем, в том числе в рассылках.
>
> Даа, далека криптография от народа, очень далека.
подписывают письма, и это легко включается для корпоративных доменов.
> А вот письмо, которое в предложенном тобой варианте
> будет как-то подписано тобой, видоизмененнное до "слезных расказов дочери
> старшего инструктора организации запрещенной в россии (тм)" может больно
> стукнуть. И ведь не отмажешься - подписи твои и верные.
что это не вариант и нужно полностью исключать DKIM для рассылок,
которые модифицируют тело и/или Subject.
--
Eugene Berdnikov
Andrey Jr. Melnikov
Oct 5, 2017, 5:10:02 AM10/5/17
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Wed, Oct 04, 2017 at 11:31:08PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> > > On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > > > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > > > По моему скромному мнению, для рассылок следует ограничиться
> > > > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > > > Reply-To, In-Reply-To и References.
> > > >
> > > > Задача определения, идет ли письмо в рассылку или нет, не
> > > > кажется мне тривиальной.
> > > Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> > > тогда везде будет меньше проблем, в том числе в рассылках.
> >
> > Даа, далека криптография от народа, очень далека.
> Да не, криптография уже близка: у нас, например, mail.ru и yandex.ru уже
> подписывают письма, и это легко включается для корпоративных доменов.
Осталось еще кому-то с выражением прочитать админам яндекса RFC6376 про DKIM, в
> On Wed, Oct 04, 2017 at 11:31:08PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> > > On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
> > > > >>>>> Eugene Berdnikov <b...@protva.ru> writes:
> > > > > По моему скромному мнению, для рассылок следует ограничиться
> > > > > подписью заголовков From, To, Cc, Date и Message-Id, плюс, возможно,
> > > > > Reply-To, In-Reply-To и References.
> > > >
> > > > Задача определения, идет ли письмо в рассылку или нет, не
> > > > кажется мне тривиальной.
> > > Ну и решать её незачем. Просто не нужно тянуть в подпись разный мусор,
> > > тогда везде будет меньше проблем, в том числе в рассылках.
> >
> > Даа, далека криптография от народа, очень далека.
> Да не, криптография уже близка: у нас, например, mail.ru и yandex.ru уже
> подписывают письма, и это легко включается для корпоративных доменов.
особенности пункт 5.3 и может тогда можно начинать верить ихним подписям.
> > А вот письмо, которое в предложенном тобой варианте
> > будет как-то подписано тобой, видоизмененнное до "слезных расказов дочери
> > старшего инструктора организации запрещенной в россии (тм)" может больно
> > стукнуть. И ведь не отмажешься - подписи твои и верные.
> Несколько заголовков мои, а тело-то не подписано. :) Но да, убедили,
> что это не вариант и нужно полностью исключать DKIM для рассылок,
> которые модифицируют тело и/или Subject.
дворе, всё что может читать почту научилось фильтровать по заголовкам.
Всё что до сих пор не научилось - в утиль.
Иван Лох
Oct 5, 2017, 5:20:03 AM10/5/17
to
On Thu, Oct 05, 2017 at 11:48:18AM +0300, Andrey Jr. Melnikov wrote:
> Нет, надо рассылочный софт лезущий в Subject/Body выкидывать. 21 век на
> дворе, всё что может читать почту научилось фильтровать по заголовкам.
> Всё что до сих пор не научилось - в утиль.
А пользователей, которые не могут отписаться от рассылки не прочитав
> Нет, надо рассылочный софт лезущий в Subject/Body выкидывать. 21 век на
> дворе, всё что может читать почту научилось фильтровать по заголовкам.
> Всё что до сих пор не научилось - в утиль.
инструкцию в футере письма куда?
То, что менеджер почтовых рассылок модифицирует тему и тело письма —
совершенно нормально. Как, кстати, и то, что четко помечает рассылки —
тоже.
В действительности, вреда от тронувшихся от перенапряжения борцов со спамом
больше чем от спама.
Andrey Jr. Melnikov
Oct 5, 2017, 7:10:03 AM10/5/17
to
Иван Лох <l...@1917.com> wrote:
> On Thu, Oct 05, 2017 at 11:48:18AM +0300, Andrey Jr. Melnikov wrote:
> > Нет, надо рассылочный софт лезущий в Subject/Body выкидывать. 21 век на
> > дворе, всё что может читать почту научилось фильтровать по заголовкам.
> > Всё что до сих пор не научилось - в утиль.
> А пользователей, которые не могут отписаться от рассылки не прочитав
> инструкцию в футере письма куда?
В вконтактик/фейсбучек, где им самое место. Там нету этих страшных
> On Thu, Oct 05, 2017 at 11:48:18AM +0300, Andrey Jr. Melnikov wrote:
> > Нет, надо рассылочный софт лезущий в Subject/Body выкидывать. 21 век на
> > дворе, всё что может читать почту научилось фильтровать по заголовкам.
> > Всё что до сих пор не научилось - в утиль.
> А пользователей, которые не могут отписаться от рассылки не прочитав
> инструкцию в футере письма куда?
спамов, почтов и рассылков. А есть котэги и видосики.
Впрочем, гмылы/яндексы давно имеют кнопку "отписаться", а тех, кто ползуется
своим MUA и MTA - это явно не касается.
> То, что менеджер почтовых рассылок модифицирует тему и тело письма ???
> совершенно нормально. Как, кстати, и то, что четко помечает рассылки ???
> тоже.
Совершенно ненормально. Письмо может быть подписано/зашиврованно PGP.
Менеджер почтовой расслки должен отвечать за 2 вещи - знать кому рассылать и
уметь подписывать/отписывать. Лезть в письмо - он не должен.
Иван Лох
Oct 5, 2017, 11:20:02 AM10/5/17
to
On Thu, Oct 05, 2017 at 01:33:31PM +0300, Andrey Jr. Melnikov wrote:
> > То, что менеджер почтовых рассылок модифицирует тему и тело письма ???
> > совершенно нормально. Как, кстати, и то, что четко помечает рассылки ???
> > тоже.
> Совершенно ненормально. Письмо может быть подписано/зашиврованно PGP.
На то есть multipart/mixed
> > То, что менеджер почтовых рассылок модифицирует тему и тело письма ???
> > совершенно нормально. Как, кстати, и то, что четко помечает рассылки ???
> > тоже.
> Совершенно ненормально. Письмо может быть подписано/зашиврованно PGP.
Коротаев Руслан
Oct 5, 2017, 1:30:03 PM10/5/17
to
В сообщении от [Чт 2017-10-05 18:17 +0300]
Иван Лох <l...@1917.com> пишет:
> On Thu, Oct 05, 2017 at 01:33:31PM +0300, Andrey Jr. Melnikov wrote:
> > > То, что менеджер почтовых рассылок модифицирует тему и тело письма ???
> > > совершенно нормально. Как, кстати, и то, что четко помечает рассылки ???
> > > тоже.
> > Совершенно ненормально. Письмо может быть подписано/зашиврованно PGP.
>
> На то есть multipart/mixed
У вас проблемы с DKIM, у меня выдает «invalid (public key: not
available)». Возможно селектор другой.
Иван Лох <l...@1917.com> пишет:
> On Thu, Oct 05, 2017 at 01:33:31PM +0300, Andrey Jr. Melnikov wrote:
> > > То, что менеджер почтовых рассылок модифицирует тему и тело письма ???
> > > совершенно нормально. Как, кстати, и то, что четко помечает рассылки ???
> > > тоже.
> > Совершенно ненормально. Письмо может быть подписано/зашиврованно PGP.
>
> На то есть multipart/mixed
available)». Возможно селектор другой.
Ivan Shmakov
Oct 6, 2017, 2:20:03 PM10/6/17
to
>>>>> Eugene Berdnikov <b...@protva.ru> writes:
>>>>> On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
>>>>> Eugene Berdnikov <b...@protva.ru> writes: >
>>> По моему скромному мнению, для рассылок следует ограничиться
>>> подписью заголовков From, To, Cc, Date и Message-Id, плюс,
>>> возможно, Reply-To, In-Reply-To и References.
>> Задача определения, идет ли письмо в рассылку или нет, не кажется
>> мне тривиальной.
> Ну и решать её незачем. Просто не нужно тянуть в подпись разный
> мусор, тогда везде будет меньше проблем, в том числе в рассылках.
«Мусор» не нужно тянуть в заголовок вовсе. Вот только не
>>>>> On Wed, Oct 04, 2017 at 05:25:26PM +0000, Ivan Shmakov wrote:
>>>>> Eugene Berdnikov <b...@protva.ru> writes: >
>>> По моему скромному мнению, для рассылок следует ограничиться
>>> подписью заголовков From, To, Cc, Date и Message-Id, плюс,
>>> возможно, Reply-To, In-Reply-To и References.
>> Задача определения, идет ли письмо в рассылку или нет, не кажется
>> мне тривиальной.
> Ну и решать её незачем. Просто не нужно тянуть в подпись разный
> мусор, тогда везде будет меньше проблем, в том числе в рассылках.
уверен, что это относится к, e. g., List-*.
>>> При этом не следует подписывать тело (body).
>> Прошу прощения? Другими словами, предоставить злоумышленнику
>> заголовком и /действительной/ подписью моего MTA?
> Злоумышленник будет больше озадачен тем, как подделать обратный адрес
> на транспортном уровне, т. е. в envelope_from. Потому как MTA именно
> Злоумышленник будет больше озадачен тем, как подделать обратный адрес
> его обычно проверяют — применяют SPF, грейлистинг и т. д.
А в чем собственно проблема? Вот как раз год назад стал я
получать нежелательную корреспонденцию со всяческих
cameraforme.ru, network-asp.ru, lambdafsu.ru, …, school38.bid,
etc. — со вполне себе действительными SPF. И, к слову, DKIM. [1]
[1] news:87vax8x...@violet.siamics.net
SPF? DKIM? spammers can do them too // news:comp.mail.misc
> А те, кто ведётся на «make money fast», они не только про DKIM ничего
> не слышали, они вообще не догадываются, что в письме может быть
> какая-то ложь. :)
с @abuse.example.invalid как spam, то можно надеяться, что
автоклассификатор отметит корреспонденцию с того же домена
следующим ста самостоятельно.
Другое дело, что узлам с тремя пользователями (или же без
работающих автоклассификаторов) извлечь пользу из DKIM уже
ощутимо сложнее. Или?
[…]
>> Если рассылка вносит сколь угодно существенные изменения, я так
>> думаю, ее администратор уже вполне может взять на себя
>> ответственность за распространение пересылаемых сообщений и
>> настроить их подписывание ключом своего узла.
> Достаточно просто снести нахрен все заголовки DKIM из входящего
> письма перед форвардом в рассылку.
с рекомендациями некоторых популярных почтовых служб. А значит
такое поведение чревато массовым попаданием сообщений в Spam.
(Из-за чего я и озадачился поддержкой DKIM, IIRC.)
А значит необходимо либо сохранять исходную подпись (что, в свою
очередь, предполагает достаточно консервативный подход к правке
транзитных сообщений), либо озаботиться созданием собственной
подписи (и со спокойной совестью добавлять [LIST] в Subject:,
«unsubscribe» в тело, не говоря уже о рекламе…)
> Но мы ведь сейчас обсуждаем что делать если админ шлюза даже этим не
> озаботился.
справились с DKIM. В итоге, оная стала «группой Google.»
--
FSF associate member #7257 np. Absolution — Makkon 7D17 4A59 6A21 3D97 6DDB
Ivan Shmakov
Oct 6, 2017, 2:20:03 PM10/6/17
to
>>>>> Artem Chuprina <r...@lasgalen.net> writes:
>>>>> Ivan Shmakov -> debian-russian@ @ Tue, 03 Oct 2017 11:33:44 +0000:
>>> Я же письмо не для себя писал. Оно пропало для получателя. Как то
>>> даже не по себе, объяснять такие простые вещи.
>> 1. Был ли получатель заинтересован в получении этого письма?
>> Поскольку смысл борьбы с нежелательной корреспонденцией как раз и
>> состоит в том, чтобы /некоторые/ письма «пропадали» для получателя.
>> 2. Если недоставка конкретного письма является проблемой, получатель
>> всегда может обратиться к администратору узла с просьбой ее решить.
> Тут есть очевидная проблема: получатель _своевременно_ не знает, что
> письмо было ему отправлено, поскольку он его не получил.
Верно; я предположил, что у отправителя есть и иной канал для
связи с получателем в случае обнаружения отказа в доставке.
> При молчаливом выбрасывании письма почтовкой у отправителя сходная
> проблема: он тоже _своевременно_ не знает, что его письмо не было
> доставлено.
Здесь могу разве что известный анекдот процитировать — «а вы так
не делайте.» (В связи с чем я, в частности, поостерегся бы
пробовать реализовать «graylist» после DATA.)
В целом же — проблемы случаются; и не всегда можно решить
проблему за тех, вследствие чьих действий она возникает. Это
отнюдь не ограничивается вопросами работы электронной почты.
>>>>> Ivan Shmakov -> debian-russian@ @ Tue, 03 Oct 2017 11:33:44 +0000:
>>> Я же письмо не для себя писал. Оно пропало для получателя. Как то
>>> даже не по себе, объяснять такие простые вещи.
>> 1. Был ли получатель заинтересован в получении этого письма?
>> Поскольку смысл борьбы с нежелательной корреспонденцией как раз и
>> состоит в том, чтобы /некоторые/ письма «пропадали» для получателя.
>> 2. Если недоставка конкретного письма является проблемой, получатель
>> всегда может обратиться к администратору узла с просьбой ее решить.
> Тут есть очевидная проблема: получатель _своевременно_ не знает, что
> письмо было ему отправлено, поскольку он его не получил.
связи с получателем в случае обнаружения отказа в доставке.
> При молчаливом выбрасывании письма почтовкой у отправителя сходная
> проблема: он тоже _своевременно_ не знает, что его письмо не было
> доставлено.
не делайте.» (В связи с чем я, в частности, поостерегся бы
пробовать реализовать «graylist» после DATA.)
В целом же — проблемы случаются; и не всегда можно решить
проблему за тех, вследствие чьих действий она возникает. Это
отнюдь не ограничивается вопросами работы электронной почты.
0 new messages