> >(2) The notary codes are described in RFC 1893, a standards-track
> >RFC. This is not a "semi-standard list of codes."
>
> What I meant is that these codes are similar in nature to the SMTP reply
> codes. If you look in the RFC, you will find (just taking a few common
> examples, and trying not to pick the exotic ones):
>
> 550 Requested action not taken: mailbox unavailable
> 553 Requested action not taken: mailbox name not allowed
> 554 Transaction failed
>
> In practice, the actual error that the MTA is trying to convey can vary
> widely from the descriptions given above, and it is common for a given
> product to have different messages associated with the same formal reply
> code, to describe different errors where the desired response from the
> MTA at the other end is the same. This is not to say that the official
> descriptions convey no information, but you cannot reasonably claim that
> the official description always matches the reported problem, even
> setting aside cases where people have used the wrong codes, or just
> couldn't find a code that was a reasonable match for what they had to
> report.
Yes, what you say about SMTP reply codes is true and that is the
exact problem that the Notary Working Group was trying to solve
with the new set of status codes. If, as it seems, you think that
the effort did not succeed, some specifics sent to the working
group mailing list ([log in to unmask], subscription requests
to [log in to unmask]) would be helpful in improving
the list of status codes.
> >(3) I don't understand why you say that the same code can mean
> >different things in different contexts.
>
> I imagine that sendmail, an X.400 gateway, an All in one mail router, a
> cc:Mail gateway, a firewall and a BITNET mailer will have widely varying
> phrasing and interpretations of the codes.
The intent was to have enough status codes so that what you say
would not have to be the case with the new codes.
> >(4) The Status field of a DSN (Delivery Status Notification),
> >defined in RFC 1894 (also standards-track), does not require
> >error message text.
>
> This is correct, however the same could be said about SMTP reply codes.
> If I want to write a SMTP agent that just replies with a number, this is
> a perfectly valid implementation, and as you know other MTAs are
> forbidden from even looking at the text. Luckily all (as far as I know)
> SMTP developers understood the merit of providing human-readable text
> that describes the actual error that they were trying to report.
> Similarly, there is a "Diagnostic-Code:" field in the DSN which LISTSERV
> does use when present.
>
> What I am trying to say is that a MTA that says 5.1.1 is no different
> from a SMTP server that says "554 ERR" or just "554". LISTSERV treats
> these two situations in the same manner, the only difference is that SMTP
> servers typically provide a descriptive error text whereas, DSN being new
> and all that, not all MTAs that use DSN fill in the "Diagnostic-Code:",
> even though (being for the most part existing products into which DSN was
> retrofitted) they do have code to generate these one-line descriptions
> everywhere that they occur. They just haven't had the time to add a
> "Diagnostic-Code:" field with these errors, or maybe they haven't
> realized the need. This is a new standard and we need to give people some
> time to implement it.
However you seem to overlook the intended difference in where the
interpretation of DSN status codes should come from, as compared
to SMTP reply codes. For SMTP reply codes, the only available
interpretation is the accompanying (generally English) text.
The intention with RFC 1893 status codes is that the set of codes
be extensive enough that the interpretation could come from the
client receiving the status code, not the sender of the status
code. This permits the client to present the interpretation of
the code in whatever language the user prefers, not just in
English. I would think that you would at least appreciate the
attempt at internationalization.
The Diagnostic-code field is intended to preserve information that
could be useful to the mail system administrator. It's not
intended for end users. Also, it's suggestion that additional
system-dependent information could be put into extension fields
specific to that system.
> >(5) The first section of the multipart/report structure used for
> >DSNs is available for a text description of the error. This is
> >for users whose systems don't understand DSNs. LISTSERV discards
> >this section in Auto-delete processing.
>
> Yes but this is not computer parseable, and LISTSERV needs a reasonably
> short (1-2 line) error description.
Yes, I understand and agree. However, I still would like to get a
copy of the delivery error that causes a user to be deleted from
a list. I also would prefer that delivery errors for addresses
not subscribed to the list be sent through to the list owner, since
auto-delete isn't going to be able to handle them and there can be
important clues in the actual error message to which subscriber
needs to be deleted from the list.
> >(6) You shouldn't just say "5.4.5 Network Congestion". It should
> >at least be "5.4.5 Permanent error, network congestion" or, more
> >likely, "4.4.5 Persistent transient error, network congestion".
> >But RFC 1893 contains longer descriptions of the meaning of the
> >codes and you are free to use those or reword them.
>
> For the auto-deletion report, I need something that fits on a line or
> two. Quite honestly, I have no idea what this network congestion code is
> for (if the network is congested you should just try again later), but I
> assume it has uses or it wouldn't be in there. If phrased in a more
> specific context, I don't doubt that I would understand what it means. I
> must be missing the obvious, but I think this illustrates the problem
> with these generic codes.
Actually, looking it up in RFC 1893, I see that status code X.4.5 is
defined as "Mail system congestion", not "Network congestion". It also
says that it is useful only as a persistent transient error (i.e.,
4.4.5), which, as you know, means that it was retried some number of
times until the server gave up trying. As you also know, MTA (mail
transfer agent) congestion is an error that X.400 systems often like to
report.
> Basically I don't understand why you seem to think that accurate failure
> information can be omitted at the source because it can be regenerated
> from a static, high-level table of generic meanings at the destination.
>
> Eric
Well, the reasons for having codes, as opposed to just English text,
are to allow a program to take appropriate action based on its
author's understanding of what the codes mean and to allow for
interpetations of the codes to be presented to end users in the
language of their choice. RFC 1894 recognizes that system specific
diagnostic information is needed for system administrators and
provides ways to include it in a DSN.
|
