[Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

    >> For access to the ACL database, we really need only to consider
    >> two MTAs (at most): Exim and Postfix.

    Brad> 	You have to give the MTA direct access to the internal
    Brad> filters of Mailman in some sense.

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.

    Brad> I don't think we can restrict ourselves to just these two
    Brad> MTAs.

Permanently, no.  I'm saying that to start with if we do Exim and
Postfix, the sendmail milter interface makes it likely that sendmail
can adapt code from one or the other, the qmail people will take care
of qmail like they always do, and that is enough to get the ball
rolling.

    Brad> 	Moreover, who owns this code?  It crosses the boundary
    Brad> between Mailman and the MTAs

No, the point is to define the boundary, and give a well-defined API
for crossing it.

    Brad> Do we have to patch their code?

Not "have to", but that may be the most effective way to jump start
it, may even be necessary for jump starting.  It's not our "job", but
it's something we may need to budget resources for if we want to do
it.  Of course if those resources are large and won't come from fresh
blood, that kills the idea.  But we haven't shown that the needed
resources are large, and there are a couple of people who I don't
recognize as frequent code contributors who are pushing hard---there
might be fresh blood out there to do this.

    >> Sendmail has milters for this purpose; you don't need to do
    >> surgery on sendmail itself, just configure the mailman-acl
    >> milter.

    Brad> 	Mailman-acl milter?  This is the first I've heard of
    Brad> it.  Is this a new thing?  Who maintains this code?

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.

    Brad> 	Okay, I can see Mailman providing a single, hopefully
    Brad> reasonably well-specified specification, and letting
    Brad> everyone else adapt. That's a far cry from what Ian was
    Brad> talking about.

Was it?  I don't know.  My feeling is that Ian is lacking some
necessary facts, and consequently expressed his requirements in terms
that can't be satisfied.  But if we give him the details and withhold
judgment on the substance until he's reformulated, we might find that
what he really wants is a lot closer to what would be do-able than our
initial impressions are.

    Brad> 	I'm willing to go that route.  But you do seem to
    Brad> agree with me that this problem is going to be a lot tougher
    Brad> to solve than Ian implies, yes?

I think so.  Solving them for Ian probably is not too hard.  Solving
them in a way that generalizes is going to be hard.  But Python is a
very good environment for such generalization.

    Brad> I am not convinced that this is a question that can be
    Brad> answered within the overall scheme of MM3.  I'm willing to
    Brad> be proven wrong, but what I know of the problem is that it's
    Brad> a much bigger mountain than I think it's being given credit
    Brad> for.

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.

    >> But saying "it's gotta be perfect on introduction or it's no
    >> good" is not a way to communicate.

    Brad> 	That is not an accurate characterization of what I was
    Brad> saying. Re-read my previous message to Ian -- I said to him:

    Brad> 		Trust me, this issue is far more complex than
    Brad> you think it is.

You said that, true.  You also said "open data formats that ALL MTAs
understand", and "ACL formats that ALL MTAs understand" (emphasis
mine).  Of course you meant something substantially weaker than "all
MTAs must understand as an absolute requirement", but surely it was
something at least as strong as "we cannot ask users to change MTAs to
get this feature."  Agreed?

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.

Now, that may inhibit adoption to the extent that creating the feature
isn't worth it, but that is not a foregone conclusion as far as I can
see.  It depends on how big a win this feature would be, and how hard
implementing the MTA-side code would be.

    Brad> 	Now, if you can agree that this is a big issue that
    Brad> will need to have a lot of thought and work put into it, and
    Brad> it not something you're likely to knock out on a single
    Brad> late-night hacking session, well that's all I'm really
    Brad> asking for.

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.

OTOH, I wonder if you're not overestimating the degree of difficulty
and underestimating the benefits of the structural work required.
Mailman itself is partially structured to do this kind of hacking, but
mostly in the posting pipeline at this point.  I've done a fair amount
of experimenting with the posting pipeline, though, and it's safe and
easy.

The "database backend" is _not_ structured that way yet, but I think
it would probably be worthwhile to move in that direction for its own
sake.  Mailman has a lot of databases: users, list config, site
config, filter rules, archives, maybe others.  I think there would be
substantial, though mostly unpredictable, benefits from regularizing
the database APIs to Mailman's current user base.  The benefits to the
"integration" crowd (like Kevin McCann) are more obvious, but I think
there will be benefits to people running traditional discussion lists,
too.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.