🚀 go-pugleaf

In article <davecb.725910818@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
|>Short answer: 
|>	Go read RFC821/2 (and consider yourself insulted).

stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
|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. 

  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
defines, as I already pointed out, a positive acknowlegement scheme
FROM THE SENDING HOST TO THE RECIEVING HOST.  If the mail doesn't 
get there, I know about it because I'm doing end-to-end positive handoffs.
If I'm talking to a proxy (gateway) site, I get a 250 OK from the proxy,
and at that point it becomes that sites's responsability to do the same
with any further sites it contacts.  If it gets a negative acknowlegement,
it's its responsability to send me mail saying it didn't get through.
And that responsability is passed on to each intermediate site in turn.
Unless you use proprietary PC mailers, your mail uses RFC822 as a
format standard, and SMTP, BSMTP or UUCP as a transport.  SMTP and BSMTP
do exacly the above, and known UUCP mailers do the same.

  And the number of **formally unreliable** mailers can be counted 
on the fingers of a one-fingered man's hand.  Alas, he's growing more
fingers as we speak, due to the existance of erroniously specificed and 
designed PC mail programs.

if skyking.OCE.ORST.EDU is losing mail, you should speak to your
postmaster: you're on the internet too. 


--dave (all the world's not a vax, but
	Usenet, BITnet and the Internet ain't trivial) c-b
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
>defines, as I already pointed out, a positive acknowlegement scheme
>FROM THE SENDING HOST TO THE RECIEVING HOST.

Sorry, I have to agree with John Stanley on this one.  In addition
to the scenario John mentioned, consider the following:

"user1@A" sends mail to "user2@B".  Mail for site B is handled by its
MX, C.  Therefore, site C is configured to handle all mail for B in
addition to its own.

1. user1@A's MUA hands off mail to A's MTA.
2. Site A's MTA connects to MTA at site C.
3. Site C receives mail, acknowleges its recept.
4. Site C's MTA connects to MTA at site B.
5. user2 dropped out of school and therefore is no longer a valid
   user at site B.  Site B nak's site C's delivery of mail with
   "user unknown".
6A. Due to a failure in the DNS configuration of site A, when site C
   tries to send a bounce to user1@A, it gets "host unknown" and
   site C promptly drops the bounce to the floor.
or
6B. Due to an improperly configured mailer at site A, the "From"
and/or "Reply-To" addresses are munged and unparseable.  Site C
drops bounce to the floor.
or
6C. Site C's /usr/spool/mqueue fills up and has insuffient disk space
in order to generate a bouce message.

What say you now?  Listen to John, you need to get out more.  SMTP may
be reliable, but SMTP is only a part of the picture, regardless of what
the pretty ASCII picture on page two of RFC821 says.  I suggest you
read the section "Reliable Mail Transmission" in RFC 1123, the
"Requirements for Internet Hosts".  Pay close attention to the words
"SHOULD" and "MUST".

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
#define ENOTTY          25              /* Not a typewriter */

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
>defines, as I already pointed out, a positive acknowlegement scheme
>FROM THE SENDING HOST TO THE RECIEVING HOST.  If the mail doesn't 
>get there, I know about it because I'm doing end-to-end positive handoffs.

That statement should have been posted to rec.humor, not to a comp group.

You send mail to a user at host B.  Host B doesn't recognize its own
name, and thinks it must relay it.  It accepts the mail for forwarding
to its relay.  At this stage it disconnects, and you have your "positive
handoff" acknowledgement.  Now host B tries to send to its relay.  I
discovers that the relay doesn't exist.  It tries to bounce the message.
The bounce is sent to the relay.  But the relay doesn't exist, so the
bounce also fails.

This type of situation is quite common.  Newly installed machines just
out of the box often behave this way, and inexperienced administrators
may not notice the problem for several months.

rickert@mp.cs.niu.edu (Neil Rickert) writes:
[...]
|name, and thinks it must relay it.  It accepts the mail for forwarding
|to its relay.  At this stage it disconnects, and you have your "positive
|handoff" acknowledgement.  Now host B tries to send to its relay.  I
|discovers that the relay doesn't exist.  It tries to bounce the message.
|The bounce is sent to the relay.  But the relay doesn't exist, so the
|bounce also fails.

|This type of situation is quite common.  Newly installed machines just
|out of the box often behave this way, and inexperienced administrators
|may not notice the problem for several months.

With respect, that's an administrator error, not a problem in the
protocol or its normal implementation.  I can make any mail system
fail by carefull misconfiguration.  Thus the definition of sendmail
in my signature.

--dave

-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, ...

The reality is that it's a miracle that SMTP based mail works _at all_.
The complexity of the problem is astounding, but it does work for a 
large number of all the messages sent.  Peer-to-peer it may give some
degree of certainty, but apart from that it's like Neil Rickart described
in <1993Jan2.171410.30990@mp.cs.niu.edu>.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''

barr@pop.psu.edu (David Barr) writes:
|Sorry, I have to agree with John Stanley on this one.  In addition
|to the scenario John mentioned, consider the following:
[scenario which make outdoing mail fail from a site]

With respect, any system, reliable or not, can be buggered up.  That doesn't
make the system unreliable (ie, it does not change its underlying character).

   Mr. Stanley is raving mad (in the sense of angry, not insane, but
also consider fingering him and making up your own mind) and is
arguing events which may well have taken place somewhere, some time.
They are seriously unusual and do not justify the establishment of the
return receipt mechanism.

  York is the second-largest and second-cheapest university in Canada,
and one of our three main mailhubs processes between 100 and 200
thousand messages per month (see below). 

Jun 1991 4729 x
Jul 1991 4423 x
Aug 1991 43405 xxxxx
Sep 1991 84828 xxxxxxxxx
Oct 1991 62510 xxxxxxx
Nov 1991 164421 xxxxxxxxxxxxxxxxx
Dec 1991 202805 xxxxxxxxxxxxxxxxxxxxx
Jan 1992 93286 xxxxxxxxxx
Feb 1992 116862 xxxxxxxxxxxx
Mar 1992 132674 xxxxxxxxxxxxxx
Apr 1992 137614 xxxxxxxxxxxxxx
May 1992 144873 xxxxxxxxxxxxxxx
Jun 1992 112393 xxxxxxxxxxxx
Jul 1992 186773 xxxxxxxxxxxxxxxxxxx
Aug 1992 115636 xxxxxxxxxxxx
Sep 1992 122207 xxxxxxxxxxxxx
Oct 1992 202904 xxxxxxxxxxxxxxxxxxxxx
Nov 1992 193313 xxxxxxxxxxxxxxxxxxxx
Dec 1992 191306 xxxxxxxxxxxxxxxxxxxx

 It is a rare event and a major concern when messages go missing or
unanswered in a given month: my job depends on the reliable operation
of SMTP.
  If memory serves, we had about three panics (searches for missing
messages) last year, out of 1.8m+.  That still makes my blood run cold...

--dave 
ps: we use Rayan's Zmailer from UofT and pop/imap: the comment
  below about sendmail is becoming less and less true. (Special thanks
  to ozan for leading me to the true religion: zmailer is programmable
  by mere mortals)
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.