On 1/13/2011 1:09 PM, John Peacock wrote:
On 01/13/2011 06:55 AM, Nicholas Lee wrote:
Is there a plugin that will check rcpt addresses against a back end smtp
server?

Ideally via some sort of smtproutes lookup.

Where are your addresses stored?  What I have done in the past is to
check directly against the user database with a custom finger daemon I
wrote.  This is a very lightweight lookup and can handle anything in
vpopmail (e.g. lists as well as mailboxes and aliases).

We download a flat file containing our user list to the configuration directory on the qpsmtpds, and load it into a note() that returns a hash that can be queried by the rcpt to hook. Qpsmtpd notices changes to the file every couple of hours (it's a nightly process to update it).

It won't introduce that big a problem even with 100K users in the hash.

You could do "forward" rcptto verification with Net::SMTP in the rcptto plugin, by creating a SMTP object aiming at an internal server who knows who exists, issuing a mailfrom() and checking the return from rcptto(), before sending quit(). Our spam filters used to do that. Apparently Postini does this too. It has the advantage of not having to interface with the recipient's user directory. Great for minimizing effort by 3rd party SMTP filtering organizations. Fairly straightforward code except that the parsing of the rcptto return has to use the Net::Cmd-documented interfaces instead of Net::SMTP's.

The problem is that it takes time. Sometimes quite a bit of time. Perhaps quite complicated coding if you're running qpsmtpd-async.

There's potentially failover/outages to consider, and potentially sender timeouts. Not to mention the extra loading on the backends.

Generally I'd advise against forward verification, unless your backend loading is relatively light, your internal infrastructure very stable, and you MUST MUST MUST have realtime identification of user adds or deletes. Mind you, if your local user directory is out of date w.r.t. deletes, your passthru is going to reject it anyway - albeit, with a NDR reject _after_ DATA.

Reply via email to