🚀 go-pugleaf

In article <davecb.725910818@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>|you didn't get a "599 ..." response. You don't even know that such a
>|response wasn't sent, only that you didn't get one. You certainly don't
>|know that the mail you sent was delivered.
>
>Short answer: 
>	Go read RFC821/2 (and consider yourself insulted).

You had better expand on that answer, for neither RFC appears to claim
anything opposite to what I wrote. And, since both RFC's deal only with
Internet standards, and since electronic mail can cross network
boundaries to systems which have no requirement to use SMTP (much less
obey Internet RFC's), neither can speak definitively on what I wrote.

>Long answer:
>	Mail is a reliable, end-to-end service, and must 

Thanks for the laugh. You may think that mail is reliable, but that
don't make it so. RFC 822 makes no mention of "reliable", and RFC 821
mentions it in two instances, one of which specifies the use of a
"reliable transport" mechanism. 

The other says that the objective of the SMTP standard is reliability.
If you believe that this statement of objective is identical to a
description of the current implementations, then consider yourself
insulted.

>	actively acknowlege both receipt and errors.  

Even were this statement true, it does not prove that mail will always
arrive at the intended recipient nor that error replies will arrive at
the originator. 

>	Gateways which do not support the above are possible
>	(the PC-critters are good at that), 

So are the UNIX critters, and the IBM critters, and every other
critter. I know of no system, PC or otherwise, which actively acks
receipt, unless the originator has requested it. That doesn't mean they
don't exist, just that they aren't real common.

>       but no-one claims they're standard-conforming.

This, of course, begs the question, whose standard?