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

Re: OT: why I don't want CCs



On Wed, Jul 16, 2003 at 06:26:15PM -0700, Steve Lamb wrote:
> On Wed, 16 Jul 2003 18:57:40 -0600 "Jamin W. Collins" wrote:
> 
> 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 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.

I have read the RFC, and simply don't see things the same as you.  I
think this discussion has made the fact that our viewpoints differ quite
clear.

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

I have never said that it was a "must".  I have stated that blatantly
ignoring the "may" is wrong, this is not the same as a "must".

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

More flexibility can be had by the MUA passing it to another application
better suited for the task, see below.

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

And thus, the impact is acceptable, when if the MUA had passed it to a
more suitable application the impact would not exist?

We have utterly different viewpoints on this.  I suggest we move on and
agree to disagree.

-- 
Jamin W. Collins

To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings



Reply to: