On Sun, Feb 08, 2004 at 02:18:07PM +0100, Kjetil Kjernsmo wrote:
| Hi all!
|
| The recent MS viruses has been bothersome for quite a few of us, I
| presume, because of the noise it creates. I have configured my Exim4
| install to reject MS executables at SMTP-time, so I don't see a lot of
| the actual virus.
|
| But I suppose I get a few bounces, like everyone, because MyDoom tries
| to send itself to "common name"@some.domain, with a forged return path
| it found somewhere. This is rather annoying, so it is important to
| configure the servers to avoid it, I figure. If you agree, please read
| on! :-)
| If I've understood the configuration I have tried to make correctly, if
| you reject the virus in the SMTP-dialog, either due to a unknown
| username (in the RCPT TO) or because it has a MS executable (in DATA),
| that bounce should not go to the address in the return-path or MAIL
| FROM: Which is good, because it is trivially forged, and so, a bounce
| that goes to the addresses there will often end up at an innocent
| third-party.
|
| If, OTOH, you first accept the message, _then_ bounce, the bounce will
| go to that innocent third party. So, one shouldn't do that. If the
| message is accepted, it is too late to bounce.
If a message is either rejected (during the SMTP dialog) or bounced
(after accepting and queueing the message) then the same innocent
third party receives some junk mail.[1] The difference is only in
which server is sending the bounce message.
The best way to handle accurately identified Windows crap is to
discard it - accept the message but do not actually deliver it.
| I've seen quite a few of these bounces, and since I'm not very
| experienced myself, whenever I've seen bounces from Exim4 installs,
| I've dropped the postmaster of that domain a note, telling them what
| happen, and that this must be an error, and I'd like to discuss it, in
| case my install behaves similarly. I haven't had a response from
| anyone, though.
|
| But now, I got a bounce from Debian's servers, and I thought "et tu,
| Brute":
|
| linda@debian.org
| unknown local-part "linda" in domain "debian.org"
|
| ------ This is a copy of the message, including all the headers. ------
|
| Return-path: <editor@learn-orienteering.org>
| Received: from gluck.debian.org [192.25.206.10]
| by master.debian.org with esmtp (Exim 3.35 1 (Debian))
| id 1ApPpz-0005Vz-00; Sat, 07 Feb 2004 04:37:23 -0600
| Received: from catv-d5de9094.bp04catv.broadband.hu
| (learn-orienteering.org) [213.222.144.148]
| by gluck.debian.org with esmtp (Exim 3.35 1 (Debian))
| id 1ApPps-00050t-00; Sat, 07 Feb 2004 03:37:18 -0700
|
| So, it is pretty clear that it didn't come from me, eh... :-) But I got
| the bounce. Why is this happening?
Your address was the sender (MAIL FROM:) and the recipient doesn't
exist - therefore you got the package stamped "Return To Sender" (to
use the US postal service terminology).
| Well, for one thing, it seems like gluck.debian.org has accepted the
| message and sent it on to master.debian.org. Is that the reason? Since
| gluck accepted the message, there's nothing master can do about
| rejecting it and the bounce wrongly ends up in my mailbox.
This is more or less correct.
| gluck is the 2nd MX, as far as I can see, but would the same thing have
| happened if master had been handling the message?
Basically.
| My main worry is of course that my own setup does the same thing,
It basically does - because when you reject a message the sending
server is then responsible for creating and delivering a bounce
message to the sender (MAIL FROM: address).
| so that my bounces end up in random people's mail boxes. I haven't
| got a 2nd MX (but I hope to get one soon), and the rejection at RCTP
| TO I haven't tweaked, it just rejects unrouteable addresses.
| My rule to reject MS executables looks like this:
| deny message = $found_extension files not accepted (may contain MS
| virus)
| demime = com:exe:vbs:bat:pif:scr
| and can be found in my ACL config. I believe this should only reject at
| SMTP time.
Correct.
| So, under what circumstances could this reject a message after it has
| been accepted and result in a bounce to an innocent third-party?
It never accepts the message, however the sending MTA is the one that
generates the bounce and sends it to the innocent third party in this
scenario.
| If I get around to get a 2nd MX, would I have to set up this 2nd MX to
| reject viruses and spam at SMTP-time, or is this something that could
| be left to the primary MX? From the above story, I think it looks like
| the 2nd MX would have to handle the rejection, that it can't be handed
| over to the primary MX.
If you have a secondary MX, it SHOULD be configured with the same
constraints as the primary. If it isn't, then it can accept messages,
try to deliver them to the primary, the primary rejects it, and the
secondary gets stuck trying to deliver the bounce. This can hurt the
secondary if the sender address is invalid and the bounce messages get
stuck on the queue.
| Your thoughts on this subject?
See above :-).
HTH,
-D
[1]: there is an exception - some really brain-dead setups will accept
the message, then send an auto response to some or all of the
addresses found in the message headers. This behavior is
completely wrong. Do not do it.
--
The way of a fool seems right to him,
but a wise man listens to advice.
Proverbs 12:15
www: http://dman13.dyndns.org/~dman/ jabber: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature