On 3/18/2011 4:40 AM, Ian Eiloart wrote: >
>
> --On 17 March 2011 09:27:31 -0700 Marc Perkel <marc@???> wrote:
>
>> I was just wondering why the mailfrom option wasn't allowed in recipient
>> callouts?
>
> I'm not sure about this, but I think it's something like this:
>
> mailfrom was introduced for sender verification callouts to work
> around the situation where various clumsy and arguably rfc
> non-compliant implementations of "bounce protection" cause the
> callouts to break, by rejecting all bounce messages before DATA.
>
> mailfrom wasn't deemed necessary for recipient verification callouts,
> because they're supposed to be used internally to your site. That is,
> the callout should be to a machine that you control in order to more
> reliably determine whether the recipient is local to the site. We use
> them to determine whether our list server will accept a message - it
> avoids the need to put our list addresses into LDAP.
>
> Since you're in control of the destination host, there doesn't seem to
> be a need for mailfrom in recipient callout verifications.
>
My situation is that I'm doing front end spam filtering and I'm doing
recipient callouts to the destination server to verify the recipient
exists. That way if the recipient doesn't exist then I can reject at
SMTP time.
Right now I can choose either and empty sender or the original sender.
I've had some problems with empty sender because some people mistake
recipient verification for sender verification and do strange things
with it. Passing the original sender works better but because the
caching stores sender recipient pairs there are more callouts that could
be avoided.
I'd like to try passing a fixed mailfrom address like
recipient-verify@??? and see how that works. It would
also have other advantages when the people on the recipient end sees the
logs they know what I'm doing.
Maybe I should suggest it be added to the next Exim?
