> My experience porting the Advenge SMTPD to be a qpsmtpd plug-in > indicated that the current interface is entirely adequate for > per-recipient things, as long as the plug-in manages its own > persistence. I don't think any new hooks are required.
On principal I'd agree that it's possible to do it all in the plugins, but if we're talking about making per-recip generally supported officially, it seems best to make that as easy as possible. I really like having the user_config and a $rcpt->config() method to go along with the hook_config and corresponding $self->qp->config(). And the more API support we have, the less extra code is added to plugins to support per-recipient stuff, e.g. the less "forked" they are from the non-per-recip counterparts. IMO Could you show some code examples? What do you do with the queue plugin(s) if recipients ended up having different headers or bodies due to tagging etc.? > Per-recipient > features can be provided as a layer consisting of coordinating > handlers for existing hooks, the most that needs to be done in my > opinion is perhaps to establish a registry of name spaces in the > existing per-message notes data, to prevent different plugins from > clobbering e/o's data. Is this still necessary if Qpsmtpd::Address::notes() exists? > One of the problems is that SMTP doesn't support per-recipient results > after DATA. > > Is QPSMTPD used widely enough that we could introduce new ESMTP > extensions with a chance that they could become widely adopted? I > believe I have seen a proposed per-recipient results after DATA ESMTP > specification, but ... okay I'll search for it ... it was in a thread > started by me, in 2006. > > http://www.ietf.org/mail-archive/web/asrg/current/msg12816.html This would be flippin awesome. Although even if QP has more pull than I think it does, it would take a bazillion years for all of the interwebs to adopt any protocol change. Nevertheless the sooner it starts to change, the better :) -Jared
