[clug] [AUSCERT ALERT - Email worm W32.Beagle.A/Win32.Bagle.A]

[Matthew Hawkins]

Martin Pool said:
> It's not my relay.  It is the outgoing relay of the person infected
> with the virus.  I have no control over it.  Neither do you.  Please try
> to understand.  The only way to stop it generating wild bounces is to
> not reject viruses.

Okay.  If the mail is coming from an *authorized client* ie, they have passed
some kind of SMTP AUTH or POP-before-SMTP or client check rules etc, then the
SMTP envelope sender will be the address of that authorized client, the bounce
generated goes to that address, and why the hell do you give a damn?  This is
the way its meant to work!  At what point does this bounce ever become *your*
problem?  It's generated by the remote server and delivered to the remote
user, and at no point involves your mail server at all!  This addresses the
scenario you spoke of, but lets explore the others.

If the mail is coming from an unauthorized client (ie, some MUA has connected
and said "MAIL FROM: <joebloggs at this.domain>") and absolutely no checking is
done whatsoever that joebloggs is a valid username, then a) its a semi-open
relay b) the bounce is still generated by the remote system and goes to
joebloggs at this.domain - the user on the remote system - and again its not your
problem.

If the mail is coming from an unauthorized client and the SMTP command is more
like "MAIL FROM: <mbp at sourcefrog.net>", then a) the remote system is an open
relay and b) you will get the bounce and c) finally, its your problem.

Block open relays.  This is irrespective of whether or not the message is
spam, virus, trojan, or even legit.  (and yes, for completeness' sake its not
as simple as that as open relays come and go and its a maintenance nightmare
and so forth, no-one denies that).  And that little niggly is what we're
currently faced with solving, and I don't believe the solution is a technical
one.

-- 
Matt