Re: rctpto rejection based on smtp verify?

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.