This looks like it can be done in a plugin and by adding a check for
the second parameter of Qpsmtpd::config():
- in hook_rcpt replace the given Qpsmtpd::Address object by a
Qpsmtpd::Recipient object (similar to yours?). For replacing: see
http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8257.html
You can also do
$_[0] = Qpsmtpd::Recipient->new($_[0]->user,$_[0]->host)
without affecting anything... well, maybe except for setups where
plugins replace the current Q::A object by another Q::A object
instead of just setting ->user() and ->host().
Why support both? Just svn mv lib/Qpsmtpd/Address.pm
lib/Qpsmtpd/Recipient.pm and add a few new methods; then make
Qpsmtpd::Address::new just return a Qpsmtpd::Recipient object for
compatibility. There wouldn't be any real overhead for anyone using the
Qpsmtpd::Recipient object for addresses only. That would also deal with
a plugin completely replacing one object with another.
BTW, I've talked previously about subclassing the real Mail::Address,
but looking further into Mail::Address vs. Qpsmtpd::Address, that
doesn't look sensible at all. I thought that Qpsmtpd::Address was
basically Mail::Address copied and pasted with a few small changes, but
they really are pretty different.
I, personally, would like to see some of the more common config
settings wrapped in config calls in Qpsmtpd::Recipient, like:
$rcpt->queue (which queue plugin to use), ->spamassassin_enabled,
->sa_deny_score, ->drop (if true, drop message silently), ->redirect
(sent to this address if not undef())... i.e. anything which defines a
recipient and is probably useful for most users.
I would personally like to see s/connection/cxn/ and s/transaction/txn/
everywhere in QP ;)
I'm currently working on a Qpsmtpd::Config module supporting some
backend config files transparently. I can add support for a second
parameter to support per recipient user/per domain configs and for a
whatever structured qmail file directory hierarchy [to Ask: also plugin
only ;-)]... as long as the given parameter supports ->user and ->host I
don't care if I get a Qpsmtpd::Address or a Qpsmtpd::Recipient.
[ For configs stored in an SQL database the helper module probably needs
some/much more work. ]
Any ETA on this? I'd be happy to do this work (and will need to on my
way to our own async migration whether or not it's useful to the QP
project, unless you're expecting to have it completed fairly soon)
A Qspmtpd::Address[|Recipient] object needs to have a method returning
its result, probably a Qpsmtpd::DSN object.
...or some other flag based list what to do with the message (drop
silently, deny, accept, redirect, ...)?
I personally like a DSN object, because I think Qpsmtpd::DSN should have
an expanded roll in QP. In our forked code we have made our own DSN
objects based on the easy Qpsmtpd::DSN API with some success. Since we
store this DSN object, with accessors telling us what we did with the
message for each recipient and why, in our recipient object, logging
everything to the database in our own particular archive staging schema
is really easy. I haven't really given much thought to how much of that
would be useful upstream. That's for another thread I guess :)
Mhh, maybe ask the SA people if it's possible to scan one mail and then
switch user and just re-calculate the score for this user. This is
unlikely to work with spamd, but with a qpsmtpd plugin "use()ing"
Mail::SpamAssassin it may work.
Has anyone been able to measure the difference in performance use()ing M::S?
-Jared
