------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1066
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pdp@???
--- Comment #7 from Phil Pennock <pdp@???> 2011-01-13 10:09:51 ---
[original response discarded; Graeme pointed to the retry rules; I'll just note
that you're looking for "32.5 Retry rules for specific errors" in The Spec]
There's room for disagreement here. I think I'm in the minority of the Exim
Devs with my view, but I'm not opposed to having an option to *upgrade* the
severity of an error.
An arbitrary facility to change the response code is bad, as it would lead to
people treating 5xx as 4xx which would cause them to become abuse emitters.
A facility to permit an admin to treat 4xx as 5xx is not causing abuse to
others and permits the owner of a system to retain control over their own
system. Email is a cooperative venture and nobody should be *forced* to
consume resources on behalf of someone else -- whether their systems are broken
or not.
While fixing the other systems is ideal, robustness in a networked system of
autonomous systems means that we need to be able to deal with brokenness
elsewhere in a sane way.
I do not think we should hard-code something in the way this patch does. I'd
be happier if we had something like the ACL language for dealing with outbound
connections, so that the admin could script the response.
I think that an SMTP transport option of "upgrade_rcpt_4xx_to_5xx" which is an
expanded string yielding a boolean and which gets the rcpt response line in a
variable would be a good choice. Let the admins upgrade, make sure we log hard
that the response was upgraded. Also include a variable which contains the
SMTP banner text.
upgrade_rcpt_4xx_to_5xx = ${if and{\
{match{$remote_banner}{\N\bPostfix\b\N}}\
{or{\
{match{$rcpt_response_text}{\N^Recipient address rejected: User unknown\N}}\
{eq{$rcpt_response_text}{unknown user account}}}}} {yes}{no}}
As is evident, this is contentious and not everyone would agree, but I'd be
prepared to argue in favour of submitting such a feature.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
