On Mon, 26 Mar 2001, Yann Golanski wrote:
> I am strongly against that one. If another MTA is broken, then it is not
> Exim's job to try to fix it. Once this door has been opended, then there
> is no stoping it.
The thing is, the line between broken and not broken is not, in
practice, a solid one. It's fuzzy. Exim already has some options (and
behaviour that is not optional) for coping with not-quite-conforming
peers. There is certainly some kind of hard boundary either way (THIS is
ok, THIS is bad) but unfortunately we have to live with a fuzzy bit in
the middle where things aren't so clear. For those, somebody has to
judge what to do. Sometimes one is contrained by "all/most other MTAs do
this...".
The particular case of return codes on connection is one of these. I now
believe I originally got it wrong in Exim by treating 5xx as not a
permanent error.[1] But it seems that others made the same mistake at the
server end. RFC 821 is not altogether clear about codes on connection
(the revised RFC is better). So in this particular case I am sympathetic
to an argument for an option.
The more general case is, I agree, more arguable, especially turning 5xx
into 4xx. Actually, I seem to recall that the previous request was for
the other way round - to turn 4xx into 5xx when some stupid host was
forever giving 4xx responses to everything.
-----------------
[1] What I thought was this: the remote host has not seen any details of
a particular message; therefore one shouldn't bounce addresses in that
message. I am now more inclined to the view that if an address is routed
to a host that gives 5xx on connection, you should bounce the address so
that somebody notices.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
