[Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That Thing Alone)

[Ian Eiloart]

--On 12 April 2008 11:18:09 -0400 Barry Warsaw <barry at list.org> wrote:

>>> IIRC, this is going to be called when the "\r\n.\r\n" terminator to
>>> the
>>> DATA command is seen.  That might be an interesting place to hook in
>>> content filtering.
>>
>> Yes, that's the earliest opportunity to filter content. It also
>> allows the LTMP server to accept the message for some lists, but not
>> others. It doesn't help the local SMTP server, though, since it's
>> too late for an SMTP server to selectively reject.
>>
>> Some admins may prefer this though. For example, I monitor my SMTP
>> server queues more closely than my Mailman queues.
>
> So you mean that most SMTPd's will have accepted the message by they time
> they issue the DATA to the LMTP?

Exim will have, almost certainly. Although it's  possible for Exim to run 
any perl script before sending the response to DATA, or even call any 
external program, there are three reasons why it probably won't:

1. It requires some coding to create the script.
2. The script would have to substantially replicate Exim's routing and 
delivery code.
3. It's relatively expensive to run such scripts.
4. It's already too late to selectively reject the message when there is 
more than one recipient, because we've passed the SMTP RCTP stage. If only 
email were all done by LMTP!

I don't know about other MTAs.

>  If that's the case, then does it even
> make sense to do content filtering at that step in LMTP, given that we'll
> still be doing the full-blown rule matching in the incoming runner?

It's of very limited use. I'm not convinced that my users use it at all. If 
a message passes the sender filter, then it's probably OK to generate a 
bounce message. The exception would be for an open list, but an open list 
that gets lots of spam probably isn't going to last very long.

My view is that content filtering for spam belongs in the MTA, which is 
much better equipped to deal with it. Rejecting spam at SMTP time has the 
huge advantage that spambots can learn to leave you alone. I don't know if 
they do, though. Otherwise, you can teergrube them (add delays to the smtp 
replies, to slow them down).

-- 
Ian Eiloart
IT Services, University of Sussex
x3148