At 14:48 -0500 2003/03/18, Greg A. Woods wrote:
[some consideration I agree with, some I do not]
>
>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 am not sure where you are getting with this, but since the object
is highly hypothetical..
>
>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:
perhaps if you had read my first post... (see below)
> 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!
in passing, just how can you or they or anyone say that it is not a
DNS issue and that is a sending system's configuration problem? The
receiver can only determine its own state and not the sender's. If
the RFC really meant that, that it would be in error.
>Now please stop trying to justify your mis-perceptions by mis-quoting
>RFC text out of context and mis-interpreting the fundamental SMTP
>mechanisms!
As you can see, I was not quoting out of context, as that is
*exactly* the snipped *I* quoted in my *first* message, and that I
repeated in a subsequent...
Perhaps you should have given your interpretation before? Why,
because I would have agreed with most of it, even if you don't find
me in agreement with the course of action to be taken.
What I do agree mostly is that a bounce must be generated, only that
I said it should be directed to the postmaster of the client site.
Why? Because the end user(s) will just be confused (and as an Hotmail
user, you would be confused too). Why the postmaster, because he is
the only one in the position to correct the configuration (if needed)
or contact the relevant administrator if the problem is not in his
smtp server.
But why I suggested to also try a second delivery attempt to another
MX? Because if this is, as it likely is, an addressing problem (stale
DNS), or some other unspecified problem, this might correct the
initial delivery problem (perhaps a 30m wait is appropriate if this
is DNS), enhancing the timely delivery chances.
The end user should only be contacted (with permanent error: message
bounced) if this also fails (and again the postmaster).
[...]
>
> > Now, you have been sent to buy some nails,
>
>More broken and totally incorrect analogies will get you nowhere.
I admit, it was incorrect in a number of points!
Now, I will only (possibly) reply to personal messages and not to the
list on this subject..
Giuliano
--
H U M P H
|| |||
software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/
