I noticied a *huge* amount of spamaware nowadays, and some
legitimate mail systems too can't deal with non-ok result
after message DATA was sent (a response to last CRLF.CRLF).
We was attacked the whole day today by "Advanced Mass Sender"
spamaware by Elcomsoft (helo Dmitry Sklarov!) that is running
via open proxies all over the world. But this program, be
it by design of by config, can't understand anything after
last CRLF.CRLF except of "250 Ok". It resends the same spam
again and again and again and again (you got the idea), using
our bandwidth/traffic/resources. Well, I worked around this
by first rejecting mails from those IP addresses (every one
in turn until this flood stopped finally -- those morons
switched to new proxy every time) using check_client_access,
and by submitting found proxies to proxy.relays.osirusoft.com
(thanks Maximiliano!). But this was manual actions, and who
knows how much traffic was generated by this whole day of
constant flood. Well, policy daemon may solve this situation
somehow (be it built-in to postfix or just scanlogd-like), but
it is difficult to say what algorithm should be used.

For such spamaware, it is far better to accept a message and
either deliver it, or drop it silently, but not reject. Drop
can be done in content_filter (but I don't want to use it as
it will double maillogs and it will be difficult to track msgs).

For now, I was forced to turn off some header_checks, since I
can't afford 24x7 manual monitoring of mail system.

In additional to some spamaware, there is several legitimate
mail systems as well that doesn't understand or understand
somewhat differently final code after last dot.

A conclusion, sort of: be at least careful when implementing
header/body checks, and avoid 'em as much as possible.

Regards,
 Michael.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]