[Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

On Tue, 2005-11-22 at 17:18 +0900, Stephen J. Turnbull wrote:
> >>>>> "Brad" == Brad Knowles <brad at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/7c74196a/attachment.pgp