[I foolishly said]
> It doesn't keep out spammer999@???, but that's OK:
> your rejection message will be (in SMTP)
> mail from:<>
> rcpt to:<spammer999@???>
> so hotmail.com should just drop the rejection on the floor. You don't
> bounce bounces.
[Matthew Byng-Maddick steps in to set the record straight]
> They'll do *WHAT*? No. I think you misunderstand a simple concept of
> "reliable" mail delivery. Once your machine accepts the mail, as Malcolm
> correctly mentions in his original post, it has a responsibility to try
> and deliver it or bounce it. What will happen if it accepts a message from
> an undeliverable address, which it then tries to bounce, is that when the
> local exim tries to send the bounce, it gets refused, and exim can do
> NOTHING, other than to freeze the message and attempt to draw the attention
> of the postmaster.
Err, that's what I meant to say! ;-)
Here is what a sensible MTA does when confronted with a bounce to a
bogus address:
220-HotMail (NO UCE) ESMTP server ready at Wed, 28 Nov 2001 05:56:54 -0800
220 ESMTP spoken here
ehlo cthulhu.gerg.ca
250-hotmail.com Hello
250-8bitmime
250 SIZE 1572864
mail from:<>
250 Requested mail action okay, completed
rcpt to:<spammer999@???>
550 Requested action not taken: mailbox unavailable
...so the message is still the responsbility of the sending MTA,
eg. your server which is rejecting a message allegedly from
spammer999@???.
I *think* -- please correct me if I'm wrong -- that the sending MTA
should just forget the whole matter now. Rather than dropping the
undeliverable bounce message on the floor, it simply never
generates/sends the undeliverable bounce. End of story.
> I on the other hand get to have a policy file that looks like:
>
> * *@insideporn.net * 550 Spam return-path
> *.monsterhut.com * * 550 Spam host
> *.sfba.home.com * * 550 Dialup host - use your smarthost
Cool! This is a feature of SAUCE, I presume?
Will be interesting to see if Exim 4 makes this obsolete.
> > For sender verification, I do this:
> > # Reject mail with a bogus sender domain, but if the envelope sender
> > # is bogus, look in the headers for a valid sender domain before rejecting.
> > sender_verify
> > sender_verify_fixup
> > sender_verify_reject
>
> I'm not convinced I like the idea of the middle one, but that comes down to
> policy.
Yeah, sender_verify_fixup makes me a tad nervous too. However, I found
we were bouncing a *little* too much semi-legitimate email (bad envelope
sender, good "From" header) for my taste, so I turned it on. We don't
have a big problem with lots of spam rejections frozen in the queue --
one every week or two, and they're actually virus rejections for the
most part -- so I can live with it.
> Doing something with viral email during the response to the final '.' is
> IMO, evil bad and wrong. You should try and keep the time to respond as
> short as possible, and the sender-SMTP should try to wait for as long as
> possible, as otherwise you end up with duplicated mail.
Is your objection purely on the grounds that it can take a long time to
scan the message body, thus possibly causing timeouts and duplicates?
If so, surely a quick scan -- eg. just look at the MIME types in the
first couple kB of the message and make sure there are no .exe, .vbs,
etc. files in the message -- would be a good first measure? Then you
could do thorough scanning after accepting the message.
I'll admit, though, that this whole idea of interceding at SMTP time
does sound a bit dodgy and prone to problems. That's why I haven't
bothered mucking with it, curious as I am.
Greg
--
Greg Ward - software developer gward@???
MEMS Exchange http://www.mems-exchange.org
