[Mailman-Developers] Google Summer of Code - Spam Defense
iane at sussex.ac.uk
Thu Apr 3 12:19:08 CEST 2008
--On 3 April 2008 14:28:55 +0900 "Stephen J. Turnbull" <stephen at xemacs.org>
> Barry Warsaw writes:
> > On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote:
> > > For this reason I am looking forward to a way to issue SMTP rejects
> > > based on content. Eg, for sendmail and postfix, this could be
> > > implemented via a Mailman-provided milter.
> > What about the Mailman 3 LMTP server? I plan on backporting this to
> > 2.2.
> I don't see how that works. Do SMTP MTAs typically initiate an LMTP
> session before accepting mail from remote hosts? If they don't, then
> you don't get any extra leverage on the backscatter problem.
Exim could do that. It has Access Controls that can be implemented at any
stage of the SMTP process. They're capable of running arbitrary perl code.
That's not trivial.
What would be easy and useful though, would be LMTP call forwards, which
are run after each RCPT TO command. We already use these to determine quota
status on our Cyrus mailstores. Mailman would need to reject mail after
RCPT TO if the sender isn't permitted to post to the list, or if the
recipient address doesn't refer to a list.
It would be nice if RFC1893/2034 enhanced error codes were used. These seem
X.1.1 Bad destination mailbox address
X.2.4 Mailing list expansion problem
X.5.3 Too many recipients
X.7.2 Mailing list expansion prohibited
The sender is not authorized to send a message to the intended mailing
X is 4 for a temporary error, 5 for a permanent error.
> > > Unfortunately, tuning list settings that have to do with filtering is
> > > not and never really was something that you want people who have
> never > > even set up an MTA to do. Understanding what happens is quite
> > > complex.
> > The solution in Mailman 3 will be to allow for defining named styles.
> That's half the solution. The other half is providing means and
> encouragement for good ones to end up in a contrib directory. :-)
> > A style is simply a collection of some subset of all the configuration
> > variables on a mailing list.
> And these cascade, right?
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe:
> Security Policy:
IT Services, University of Sussex
More information about the Mailman-Developers