On Wed, 13 Apr 2005, Mark Moseley wrote:
> Yeah, what the heck is up with that? I've been scouring logs today
> trying to find other non-null sender bounces and there's a lot.
> Luckily most are some variant of postmaster or mailer-daemon, but
> who are these maniacs writing MTAs (or possibly configuring) that
> don't use a null sender for bounces.
Yup, there's a class of anti-virus nuisance that proudly puts its
distinctive sender address into the envelope-sender of reports, making
them easy to block.
We've got a special stanza in our ACL which rejects sender addresses
that have annoyed us too much with those such virus alerts - with a
specific message, rather than the catch-all sender-blacklist message.
> What a great way to create collateral spam.
If the sender address is specific to the AV server, as in this example
virus-protection@??? , then getting spammed is no more than it
deserves, hmmm?
The even *less* excusable cases are the ones where the anti-virus
report has faked someone else's address - for example the intended
victim, or the originally-faked sender - into the envelope sender of
the report.
Unfortunately, I can't say for sure that all of the items we've
rejected on that criterion really -were- bogus anti-virus reports -
the sender address gets put into our BVA blacklist for that cause, but
what happens after that is left to fate; however, no-one has contacted
our postmaster to suggest that any productive mail is being blocked as
a result.
I suppose if we were to block it at DATA time instead, we'd get the
headers logged, and so a better idea whether we were still justified
in rejecting it. But we're rejecting at RCPT time - life's too
short...
> I've also had a lot of fun trying to come up with some regex to
> cover the completely random envelope senders that Symantac NAV is
> sending out virus warnings for
You might want to try TimJ's spamassassin ruleset
"bogus-virus-warnings.cf", see
http://www.timj.co.uk/linux/sa.php
