On 17 Nov 2005, at 15:00, Brad Knowles wrote: > At 10:49 AM +0000 2005-11-17, Ian Eiloart wrote: > >>> MLM >>> developers do not buy into the concept of making the three main >>> data >>> stores available in SQL (those being list config, member and >>> message >>> archives) >> >> Add to that Sender privacy rules, so that the Mail Transport Agent >> can do SMTP time rejections. Bouncing messages isn't really >> acceptable these days, since sender addresses are so frequently >> forged. > > I'm not sure I understand. Are you talking about integrating the > MTA into Mailman, so that it can directly access the list of > allowed senders for a given mailing list and take appropriate > action for other addresses before actually accepting a message?
Erm, I'm not sure what you mean by "integrating the MTA into Mailman". I certainly don't mean that Mailman should replace my MTA. I do mean that my MTA should work closer with Mailman, either by sharing data, or by letting Mailman reject (not bounce) messages somehow. "Integrating with" might be a better way of expressing it. This is going to be an absolutely essential requirement. It's no longer acceptable to generate email bounces for spam. Blackholing spam isn't a very good idea either, since false positives go undetected. The only acceptable options for spam are markup, and SMTP time rejection. SMTP time rejection has the added advantage of discouraging spam-bots. The UK's Joint Academic Network (JANET) recently published an article "Spam Bounces Considered Harmful". http://www.ja.net/newcert/email/ bounceUKN.html Let's be clear. The *requirement* is that my MTA should never accept an email that isn't going to prove undeliverable. Currently there are two main reasons why it might: a full mailbox, or a Mailman rule. I'm agnostic as to how the requirement is met, but there are issues of performance, and configurability to be considered. > It seems to me that this concept is moving even further towards > the "kitchen sink" approach, where one group has to have complete > control over all aspects of the system. No, I just need to be able to access the rules from some other system. That means that the rules need to be stored in a manner that's accessible to my MTA. SQL, LDAP, flat files, I don't really care, but they do need to be accessible. They also need to be represented in a manner that's easy to understand. For example, a list of regular expressions. Exim can easily manage that. Alternatively, I should be able to have my MTA ask Mailman whether it will accept the message. It might need an SMTP or LMTP interface to do that - I don't know LMTP well enough to know whether it can reject messages. Anyway, if the intention is to have open rosters (ie rosters that I can access from any application), then we're pretty close to what's required. It would help if a roster can include regular expressions to say things like [EMAIL PROTECTED] or not [EMAIL PROTECTED], and if ban lists can be expressed as rosters. My MTA (Exim) has ACL rules that can say things like: if /local/mailman/lists($local_part) is a file, then if $sender is in the list (SQL query|LDAP query) then accept the message else reject the message Actually, I *thought* this was all in the plan for Mailman 3, but I'm glad to get the opportunity to make clear a requirement that - for me - is the single most important requirement that Mailman doesn't currently meet easily. I say "easily", because I *could* have my MTA run a python script to get the list of permitted senders, but I've not invested any time into doing that, mainly because I've never done any python programming. -- Ian Eiloart Postmaster, IT Services University of Sussex _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
