[Mailman-Developers] before next release: disable backscatter in default installation

[Mads Kiilerich]

Mark Sapiro wrote, On 03/31/2008 06:26 PM:
> So what do I do practically in this case. Calling out to verify the
> recipient won't help because the recipient is valid.

I think that we - admins and developers - have to realize that times are 
changing.

Once upon a time when the RFCs were written then mail was asynchronous 
store-and-forward. MTAs accepted mails before being 100% certain that 
they could and would deliver them, and as soon as the mail had hit the 
disk then the receiving MTA took over delivery responsibility from the 
sending MTA.

In such a scenario Mailman "is just" a MTA with bouncing/holding 
filtering and dynamic alias expansion of envelope-rcpt and replacement 
of envelope-from with a robot address.

But now in modern times all mail handling has to be synchronous. Spam 
and virus and backscatter does that a MTA should never take 
responsibility for anything from an untrusted sender before the mail has 
actually been taken fully care of by someone - perhaps just by making it 
the problem of the next MTA/MDA. Yes, doing this all the way to the 
final mailboxes might be more expensive than the old way of doing it - 
but at the same time the same amount of work (or less?) has to be done, 
so it can't be that bad ... except for the number of live connections. I 
think that the RFCs allows fully synchronous mail handling, they just 
have to be used another way than they usually are today.

In Marks specific case in this scenario: The verification phase has been 
replaced by actually doing the delivery all the way to the final 
recipients, so the recipient ending up being invalid will be handled 
properly.

In this scenario Mailman is a MTA which decouples the synchronous chain. 
Mails are accepted and enqueued by Mailman iff responsibility is taken, 
either for immediate delivery or manual review - all other mails are 
rejected. All filtering thus has to be done synchronously. Delivery to 
list members is a separate process where target mail hosts probably will 
provide synchronous delivery status feedback (perhaps as DSN bounces 
from a trusting "real" MTA) (and if other mail hosts chooses to accept 
and then bounce later then they have a problem, but Mailman can still 
handle receiving bounces).

Lots of details are missing in this description. But do you agree that 
this is the direction we have to take as developers and admins?

/Mads

ps: This might be a bad description of trivial observation, but it 
suddenly made sense to me and I wanted to share it, even though I'm 
mostly a lurker on this list. Take it or leave it ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3422 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080401/c80a0173/attachment.bin