On Tue, 2005-11-22 at 17:18 +0900, Stephen J. Turnbull wrote:
"Brad" == Brad Knowles brad@stop.mail-abuse.org writes:
To get all the way to "MTA doesn't accept anything that MM is going to refuse to deliver", yes. But we certainly could define an interface to an auxiliary service such that if the MTA tells us (AuthType, AuthCredentials, EnvelopeSender, Sender, From, To) we'll say "nuke it" or "OK, we'll handle that". That would allow us to push a lot of simple cases (such as "authenticated user not a list member") back to the MTA, and never invoke the heavy equipment of Mailman itself.
I think that's an acceptable goal. My own feeling is that the way to accomplish this is through an out of band (though well-specified) communication protocol, probably based on some standard interoperable IPC, like XMLRPC or some such.
It's so new it's vapor.<wink> The point is that while I worry that Exim and Postfix may require source patches, sendmail can be done as a separate milter module. This is exactly the kind of thing that the milter API was designed for.
I'm fairly confident you can extend Postfix in this direction, though I haven't done it myself. And I'd be very surprised if you couldn't do it in Exim, that being traditionally a very extensible MTA.
Well, you may have a bigger problem in mind, but 90% of Mailman users would get a big bonus from getting only halfway there. Or maybe you know something I don't.
Actually, I'll bet 90% of Mailman users won't care. :) But the other 10% will care A LOT, so it's worth thinking about.
Speaking for myself, I see nothing wrong with asking the bleeding edge adopters to change MTAs, and I see nothing wrong with restricting Mailman-supplied MTA code to a couple of MTAs that we "like". Of course we help other MTAs to incorporate the feature, but we don't need to promise that they can use it in advance. Some MTAs may never get it.
I definitely want us to think about ways to improve the entire tool chain, from MTA to archiver. I'd prefer solutions that are geared more toward interoperable specifications first, followed by implementation and/or patches to the tools in those chains. For example, we can publish X-* headers, or XMLRPC specs, etc. By striving for MTA, web server, and even MLM agnosticism where possible, we can push the entire state of the art forward.
A good example of something I've looked for for a long time is an interface between MLM and archiver, where the MLM could anticipate the archiver URL without having to actually archive the message first. If we had that spec, we could include the archive URL in an X-header or a footer when we send the copy to the list members.
Definitely. That's been my main theme both in this thread and in the SQL database thread---simply specifying requirements is a big job. The users know the effects they want, but UI/API/implementation constraints haven't been presented at all. And users won't really be able to express them until they've got a prototype to work with.
One of the things I plan on doing is to get a new project wiki up where we can start collecting all this information. That's all part of my plan to improve project management, which I'm personally committed to addressing by year's end.
-Barry