On Mon, Jul 26, 2010 at 10:27 PM, Ask Bjørn Hansen <a...@develooper.com> wrote: > > On Jul 25, 2010, at 2:43, Jared Johnson wrote: > >> it will soon be hopelessly forked from normal QP on account of >> per-recipient config directives, etc. > > > Having a common API for "per-recipient" things have long been on the todo > list. > > We've talked about it a couple times before; but the > requirements/needs/wishes never sunk in deep enough in my head to do anything > about it. So: How do you use this?
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. 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. 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
