Re: spamassassin + exim
Andrey Melnikoff wrote:
> Нет, послать DSN это можно. Только где гарантия, что та сторона его примет?
> Вон почта.ру DSN'ы снаружи не принимает, да и много еще кто не принимает.
А можно необходимость считать отправителя <> допустимым обосновать
апеллируя к здравому смыслу? :) Раз RFC _требует_ отсылать DSN'ы, то,
исходя из непротиворечимости аксиоматики RFC, MTA не должны отвергать
DSN'ы безусловным образом. Об этом и RFC 2505 (Anti-Spam Recommendations
for SMTP MTAs) говорит:
2. Recommendations
Here we first give a brief list of recommendations, followed by a
more thorough discussion of each of them. We will also give
recommendations on things NOT to do, things that may seem natural in
the spam fight (and might even work so far) but that might wreak
havoc on Internet mail and thus may cause more damage than good.
[...]
6a) MUST NOT refuse "MAIL From: <>".
Это, конечно, нисколько не стандарт, чтобы его соблюдали. Но отвергать все
DSN'ы... - тут ни капли здравого смысла. Борьба со спамаом? - смешно! Даже
RFC, посвящённый этому вопросу рекомендует принимать. _Единственное_
неудоство от <> - в том, что нельзя сделать SMTP-callback; остальные
проверки будут работать и ни каких дополнительных проблем этот отправитель
по сравнению с обычным <user@internet.com> не создаёт. Таким образм,
фильтрация <> ни чем не обусловлена - борцунство, одним словом.
>>По приведённым RFC не бывает на столько non-aware, что б совсем молча
>>дропали. А конфинурации бывают, вот только стандарт они нарушают.
>
> Оно - non aware. Незнает оно ничего об нем. Неумеет. Впрочем, покажите мне
> в RFC[2]821 в параграфе "Minimum Implementation" вообще про
> RCPT TO: <user@internet.com> NOTIFY=FAILURE,DELAY
Эээ? В поскипаных RFC[2]821 что было написано? DSN _должен_ быть послан в
случае проблем с доставкой. Всё. А был он заказан или нет в NOTIFY,
который не обязателен, а лишь _расширение_ стандарта, роли не играет.
Reply to: