On Wed, Nov 28, 2001 at 09:06:15AM -0500, Greg Ward wrote:
> [I foolishly said]
> [Matthew Byng-Maddick steps in to set the record straight]
> Err, that's what I meant to say! ;-)
Oh, good. :-)
> Here is what a sensible MTA does when confronted with a bounce to a
> bogus address:
[transaction snipped]
> ...so the message is still the responsbility of the sending MTA,
> eg. your server which is rejecting a message allegedly from
> spammer999@???.
Yes.
> I *think* -- please correct me if I'm wrong -- that the sending MTA
> should just forget the whole matter now. Rather than dropping the
Basically yes, it should forget about trying to deliver it. I'd suggest
that you have the exim option
freeze_tell_mailmaster
set. Which means that a human gets to see when one of these double-bounces
happens.
> undeliverable bounce message on the floor, it simply never
> generates/sends the undeliverable bounce. End of story.
That's correct. Thought it probably should tell a human in some form.
> > I on the other hand get to have a policy file that looks like:
[extract of my policy file]
> Cool! This is a feature of SAUCE, I presume?
Yes.
> Will be interesting to see if Exim 4 makes this obsolete.
It can't make all of the SAUCE features obsolete, as part of the point is
also to do teergrube on the connection if it thinks you might be a spammer,
and it's hard to get Exim to do that. However being able to write a filter
at the end of DATA will be good. ;-)
> > 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.
Right. I have a policy (on my home account, anyway) that if you send me
email, then a return-path should be correct and deliverable. SAUCE actually
calls back the MX host for the email and tries to deliver a bounce (without
sending the DATA).
> > 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?
Yes.
> 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.
This would be sensible, yes.
> 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.
Most of the time, I find that a dedicated filter in front of the main MTA
works a treat.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
