On Fri, Jan 14, 2011 at 7:28 AM, Chris Lewis <cle...@nortel.com> wrote:
> 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. > Postfix deal with this by 450 on timeout [1]. > 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. > Although I could write some scripts to poll the user db at the mail server back ends. It would be nice if I could be somewhat lazy have have a plugin do this. ;) Real time checking for each delivery is obviously unworkable, but poll then cache with maybe a expiry is still a practical option. The mechanics are probably similar to greylisting. Nicholas [1] http://www.postfix.org/ADDRESS_VERIFICATION_README.html
