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