Re: rctpto rejection based on smtp verify?

On Fri, Jan 14, 2011 at 7:28 AM, Chris Lewis <[email protected]> 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