On Wed, 16 Jul 2003 17:08:04 -0600 "Jamin W. Collins" <[EMAIL PROTECTED]> wrote: > WRONG! Completely and utterly wrong. The error codes have specific > meanings and those meanings should be followed. Anything less is an > incomplete implementation.
Really? Reading 2821 one sees that it boils down to this:
2xx - "good"
4xx - "transient error"
5xx - "constant error"
There's some granularity in the 2xx section but by and large a client can
take 4xx/5xx messages and treat them both as constant. The only difference
between 4xx and 5xx is that on a 5xx error the client "must not attempt
delivery to the same server without human intervention" whereas a 4xx is
allowed retries. Treating a 4xx like a 5xx hurts nothing on the server nor
the client. The further granularity of the error codes, for the purpose of a
simple client, DO NOT MATTER. In fact most of them are more for informational
purposes than anything else and there is no compulsion for behavior other than
whether one can retry and notifying the human of the error.
> No, it is different. SMTP communication is not a basic as a system call
> with a success or failure return code.
Yes, it is. 2xx - sucess. 4xx/5xx - failure.
> And leave out key parts of the protocol, no. Implement the entire
> protocol or don't do it. And as far as I'm concerned an MUA shouldn't
> speak SMTP at all, there is absolutely no need for it.
There is need. I highlighted the need. Furthermore one does not have to
implement the entire protocol. One can easily send HELO instead of EHLO and
use the basic set. The basic protocol is described above.
> There is no need for the MUA to implement SMTP.
Wrong.
> SMTP transmission is as simple as piping it to a command line utility and
> checking the return code, you're sorely mistaken.
In the years I have been involved in email delivery/reading at various
levels I have *never* heard a compelling argument to prove me wrong. There is
nothing in the RFCs to suggest otherwise. I've had people tell me I'm wrong
but so far not a one over the years has been able to back it up with the RFCs.
> No it's not. During the SMTP communication you can get a variety of
> error codes. Some permanent errors and others temporary. To treat them
> all the same and leave them up to user interaction is wrong.
How so?
-----
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary and the action
may be requested again.
-----
Some key words. First 4xx is an error condition. Second, it is
temporary. Third, the action *MAY* be requested again. Not must. There is
absolutely no compelling reason for the client to absolutely retry without
human intervention. 4xx only states that it is possible (and indeed
encouraged) for the client to try again. However it no-where states that
human intervention is a nono. There aren't any guidelines as to how long to
wait for another attempt or under what circumstances that attempt can be made.
---
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client is discouraged from repeating the exact
request (in the same sequence). Even some "permanent" error
conditions can be corrected, so the human user may want to direct
the SMTP client to reinitiate the command sequence by direct
action at some point in the future (e.g., after the spelling has
been changed, or the user has altered the account status).
---
Here we see human intervention explicitly mentioned as well as the client
being discouraged from sending the same request in the same sequence again.
> No, the difference is a complete vs incomplete implementation of SMTP.
Of course, the client doesn't need to implement the server portions of
SMTP since it will, at no time, accept an SMTP connection. All it needs to do
is connect to the server, send the data in the right sequence, look for
success (2xx) or failure (4xx/5xx) and act accordingly.
Now if you still feel compelled to refute that please back it up with
citations from the RFCs and a plausible explanation on why a *client* cannot
treat a 4xx as a 5xx without doing harm. I do not like being told there are
problems with my take on the matter without any supporting arguments or
citations.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
| -- Lenny Nero - Strange Days
-------------------------------+---------------------------------------------
pgp00000.pgp
Description: PGP signature
