"Brad" == Brad Knowles <brad@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 MTAsNo, 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.