I manage about 30 smarthosts for various versions of MS exchange from
5.0 to 2003. And most causes for queues filling up on exchange come from
the fact they accept everything as a recipient (except 2003 but that
needs extra configuration) for their domains, and they try to send
bounces to non existent forged senders because they sent mails to non
existent local users. All those bounces will be deferred by you do
recipient callout verification. Do you also handle incoming spam
verification for those exchanges?
AFAIK 451 is a temporary error, so the MTA shouldn't drop the connection
(forbidden by RFC2821), but issue a QUIT and retry later.
Some buggy MTAs just treat 451 errors as permanent errors if the first
recipient was ok but others where 45x'ed, but this isn't the case for
exchange.
Dave Evans wrote: > Hi,
>
> At this site we've got some Exim servers which do various forms of "verify =
> recipient". Our customers use our Exim servers as a "smart host". Some
> customers with MS Exchange report problems with their queues filling up, which
> I /think/ is triggered by the "verify = recipient" failing (i.e. throwing a 451
> error code); I'm /guessing/ that Exchange treats this as some sort of
> connection- or host-level error, as opposed to an error for just that
> recipient, or even just that message.
>
> Does any of this sound familiar to you?
>
> How should an RFC-compliant MTA handle a 451 error from RCPT? I get as far as
> it's a temporary error, in the "Mail system", which may mean "Requested action
> aborted: error in processing". So does that mean that a compliant MTA should
> drop the connection? Defer all messages for that host? Defer that message,
> but continue with other messages for that host? Defer that recipient, but
> continue with other recipients for that message?
>
> Thanks,
>
