[Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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 *@sussex.ac.uk or not *@sussex.ac.uk, 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