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
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
I assume you meant to CC the list originally, I've added it :)
Could you show some code examples?
not immediately, but sure
What do you do with the queue
plugin(s) if recipients ended up having different headers or bodies due
to
tagging etc.?
Advenge only deals with deliver/defer with
On Sun, 25 Jul 2010, Jared Johnson wrote:
The plugin has the following advantages over the original:
- Uses MIME::Parser to unpack message text so that we can look for URI's
in base64-encoded data, etc., and _not_ look for URI's in noise.
I think we should probably consider putting support
I think we should probably consider putting support for parsed messages
into core, with the parsing done lazily if requested by the API.
It's a good idea, it's only that I haven't yet had the time and
justification to write and to test a move from the plugin model (see the
attached plugin in my
I think we should probably consider putting support for parsed messages
into core, with the parsing done lazily if requested by the API.
I forgot, we did kinda think of a couple of reasons not to want an API.
depending on where you put it, you may find QP in general depending on
MIME::Parser
Jared Johnson wrote:
I think we should probably consider putting support for parsed messages
into core, with the parsing done lazily if requested by the API.
I forgot, we did kinda think of a couple of reasons not to want an API.
depending on where you put it, you may find QP in
