[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: why I don't want CCs



On Wed, 16 Jul 2003 18:57:40 -0600
"Jamin W. Collins" <jcollins@asgardsrealm.net> wrote:
> You seem to miss the point of the 4yz error code.

    No, I haven't.

> The fact that an automated retry can (and should) be done.  What you propose
> would remove this and instead require human interaction for a transient
> error.  This *is* wrong.

    No, it is not.  Again I direct you to the cited passage.  It does not say
ANYWHERE that a retry *must* be made, only that it *may* be made.  The
strongest word is "encouraged".

> Whether you choose to see it that way or not.  Imagine if all the MTAs out
> there behaved this way.

    But we're not talking an MTA, are we?  We're talking about a mail client. 
Please also read the RFC and note that it does make the distinction between
client and server.  The protocol is written so that behaviors that must be
followed are but there are places where the spec allows leeway on the part of
the author of any piece of software to use his or her discretion on what is
appropriate in the situation at hand.  That means for a mail client in is
entirely withing the bounds of the RFCs to choose *NOT* to retry.  If you are
going to refute this please back it up with citations from the RFC.  I've done
my homework, I would appreciate the courtesy that you do the same.

> The fact that the RFCs classify a 4yz and 5yz error differently indicates
> that there is a forseeable need for the difference.

    Yes.  4xx is a "may retry".  5xx is a "must not retry."  Please tell me
where it says a 4xx is a must retry.  Cites, please, not your interpretation
of what you think is there.

> You propose eliminating that need.  If it was not needed, I highly doubt it
> would have survived revision.  Your own citations show the difference and
> the suggested actions based on them.  Yet you suggest going against the
> recommendations of the RFC, when there is no need to do so.

    But there is a need.  As you, and others, have so aptly pointed out, a
mail client is not a full-blown MTA.  An MTA passing on the mail to another
MTA would want to follow that suggestion because it is an intermediary.  A
mail client is not an intermediary, it is an end point.  As such the impact is
exceedingly low and the return on flexibility and ease of use far outweighs
any problems which can occur.

    Or, to put it another way, if an MTA does not at least attempt a
retransmit it can potentially cause hundreds of thousands of email, and thus
hundreds of thousands of people to have problems.  If a mail client does not
attempt to retransmit it risks, at most, inconveniencing one person.  Couple
that with the notification that it was unable to perform the action and the
impact is negligible.

    If you cannot see the difference in those scenarios then I am at a loss as
to how to explain it to you any more clearly.

-- 
         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
-------------------------------+---------------------------------------------

Attachment: pgp7eaAuxIUH6.pgp
Description: PGP signature


Reply to: