Hi,
A new Mailman 3 branch can now be found at https://code.launchpad.net/~wilunix/mailman/lmtp The wiki at http://wiki.list.org/display/DEV/MailmanBranches has been updated with this branch in the unofficial section.
This branch has enhanced LMTP code for Mailman, found in mailman/queue/lmtp.py. The LMTP server will reject mail RCPT TO if: (a) the list doesn't exist, or (b) generic_nonmember_action is set to "reject", and the sender is not a list member. Emails to sub-addresses of known lists will pass this point.
This code still needs enhancing. We would like your views on how emails should be processed, depending on the sender's status (member/non-member), the sub-address in the list address and the non-member filters.
Depending on which sub-addresses are used and if the sender is a known member or not, emails should be accepted or rejected at RCPT TO.
Should emails from unknown senders with the sub-addresses -leave and -unsubscribe not pass RCPT TO, seeing as these senders aren't members of any lists ?
Should emails from unknown senders with the sub-addresses -join and -subscribe be able to pass RCPT TO so that people can join and subscribe to mailing lists ?
What should be done with emails from unknown senders with the sub-addresses -bounces, -owner, -confirm and -request ?
Should all the sub-addresses be accessible by all known members ?
At the moment our code will reject mail from senders who aren't members if generic_nonmember_action is set to "reject".
Seeing as this code is enhancing the LMTP server how should we handle the non-member filters ?
Should we keep the current filters ? or would a new mechanism for handling emails from non members be the best solution ?
William Mead.
--On 14 July 2008 11:03:51 +0100 William Mead <william.multimedia@gmail.com> wrote:
Hi,
A new Mailman 3 branch can now be found at https://code.launchpad.net/~wilunix/mailman/lmtp The wiki at http://wiki.list.org/display/DEV/MailmanBranches has been updated with this branch in the unofficial section.
We're in Willam's final week here, and he's made good progress. He's uploaded an unofficial branch of Mailman 3.0 with an enhanced LMTP interface - supporting ENHANCEDSTATUSCODES, and rejecting mail as early as possible when it isn't wanted.
He's also backported the code to version 2.2.
I've documented this in a comment at http://snipurl.com/33196
William Mead has been working on LMTP code for me. He's produced implementations for version 3.0 and for version 2.2, with these tests applied after RCPT TO in the LMTP conversation:
- message will be rejected if the list name is not known.
- message will be accepted if the sender matches "accept_these_nonmembers".
- message will be accepted if "generic_nonmember_action" is not reject.
- message will be accepted if the sender is a list member.
- if we get this far, the message will be rejected - the sender is a non-member of a closed list.
We could also reject other members if they're moderated, for example. However, we've adopted the view that it is relatively safe to generate a bounce message for someone who is a member of the list.
William has completely reimplemented the SMTPD code in Python, to support ENHANCEDSTATUSCODES, because the LMTP RFC requires that - even though the examples in the RFC don't show them being used! However, the code doesn't implement PIPELINING - also required by LMTP - because the underlying ASYNCHAT/ASYNCORE architecture doesn't seem to support it. We discovered that advertising PIPELINING causes the test smtp client to fail, but we've not even thought about how to fix that - LMTP clients which are re-implementations of SMTP clients might just live with the fact that PIPELINING isn't advertised.
William's code is at https://code.launchpad.net/~wilunix
The LMTP queue runner allows us to run Mailman on a server that's unrelated to the main MTA. With an Exim MTA, you could use a recipient callout to verify that the sender is permitted to post to the list, before accepting the message for deliver. This means that rejecting an unwanted message should not create collateral spam.
-- Ian Eiloart IT Services, University of Sussex x3148
--On 22 July 2008 14:12:09 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
We discovered that advertising PIPELINING causes the test smtp client to fail, but we've not even thought about how to fix that - LMTP clients which are re-implementations of SMTP clients might just live with the fact that PIPELINING isn't advertised.
Actually, it looks like this isn't a real problem. The LMTP Channel raises an error if the client disconnects before getting all the Channel's output. But, once the client has gone away, the Channel has no purpose anyway. Hopefully, it will discard any message that it has to avoid message duplication - this remains to be tested. The LMTP listener survives all this, and so I think we are in fact safe to advertise PIPELINING. Hooray!
-- Ian Eiloart IT Services, University of Sussex x3148
participants (2)
-
Ian Eiloart -
William Mead