Re: per-recipient configuration

> 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