[ On Tuesday, March 18, 2003 at 18:52:31 (+0000), Giuliano Gavazzi wrote: ]
> Subject: Re: [Exim] Reaction to rude 554 greeting
>
> Sorry, but Eric is the only person here having shown lack of
> preconcepts. You do not like 2821, fine, but keep your opinions as
> yours and do not try to sell them as the RFC truth.
What I have to say about RFC 2821 is irrelevant and totally unrelated to
what I have to say about _BROKEN_ systems which return any 5xx response
to a connection!
> Why did they introduce a 554 on connect? Well, perhaps because DNS is
> not part of SMTP and also because DNS has, by nature, updating
> delays. Can be done with a firewall? Maybe, but that is not part of
> SMTP, again.
The DNS has absolutely nothing whatsoever to do with this problem.
And yes, it can be done with SMTP and without using this stupid 554
you're trying to suggest should be used.
You are the one who has consistently mis-interpreted RFC 2821 and
selectively quoted poor justifications out of context.
The only proper and interoperable way to force a connecting SMTP client
to go on and try some other MX is to return a TCP RST packet in response
to its connection attempt. Any other intention can be done by
responding appropriately _after_ HELO.
Anyone thinking they'll force a sender to try the next MX by returning
_any_ 5xx code on connection is totally out of their mind. It will only
ever work with other people who have similarly completely lost their
minds. The rest of the world will have implemented interoperable
standards which will bounce their e-mail and that'll be that.
Look at it from even just the pragmatic point of view. Who's in control
here? The SMTP operator is, not the DNS. The "two bosses" analogy
breaks down completely unless you force a situation where the
de-comissioned boss gets walked out of the building _before_ he's
officially de-comissioned in which case you end up with the analogy
mapping to "return TCP RST". Would you rather shut down your mailer
_and_ write a stupid little script that echos "554 go away" and call it
from inetd on port 25 _and_ enable it; or would you rather just just
down your mailer and be done with it? What would ever even make anyone
think they need to invent a new server that sends 554 when just turning
off the de-commissioned server will do exactly the same thing in a way
that's worked properly since before MX records were ever invented? What
would ever make them think it would be worth the effort no matter how
small it may be?
If you actually look at the history of why 554-on-connect was included
in RFC 2821 I'm certain you'll find that it was intended only for use on
servers which for some unfathomable reason must answer on port#25 but
which never ever has and never ever will accept SMTP connections --
i.e. would never ever have ever been listed as an MX host in the first
place! I.e. the reason for its mention is totally separate from the DNS
and only satisfies some completely unspecified requirement that's really
totally unrelated to even SMTP except in that it allows some
interoperability with a broken SMTP client! I'm certain you'll also
find that the reason it was given a 5xx value and not a 4xx value was
because everyone knows that you have to send a 5xx response in order to
get a message to bounce.
I.e. the idea of using 554 to indicate de-commissioning or an
out-of-service state is totally bogus and is based on a major
mis-interpretation of RFC 2821!
Let's go to the correct part of the horse's mouth for once: RFC 2821
section 3.1:
The SMTP protocol allows a server to formally reject a transaction
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands". Since an attempt to make an SMTP
connection to such a system is probably in error, a server returning
a 554 response on connection opening SHOULD provide enough
information in the reply text to facilitate debugging of the sending
system.
Note very carefully the words "reject a transaction". They translate
directly to "cause a bounce of the message which the sending-SMTP is
trying to deliver"!
Note also very carefully the words "SHOULD provide enough information in
the reply text to facilitate debugging of the sending system." They
have two very important implications: (1) that human intervention is
required, implying that a bounce _MUST_ be generated; and (2) the
problem is in the sending system's configuration, i.e. it is not a DNS
issue at all and it has _nothing_ to do with de-commissioning!
Now please stop trying to justify your mis-perceptions by mis-quoting
RFC text out of context and mis-interpreting the fundamental SMTP
mechanisms!
554 in response to an initial connection is not now, and has not ever
been, intended to force a retry -- quite clearly the opposite: it is
specified explicitly as a way to "reject a transaction while still
allowing the initial connection"!!!!!!!
> Now, you have been sent to buy some nails,
More broken and totally incorrect analogies will get you nowhere.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
