home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 410 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  2.3 KB
  1. Xref: sparky comp.mail.headers:410 comp.mail.misc:4202
  2. Newsgroups: comp.mail.headers,comp.mail.misc
  3. Path: sparky!uunet!spool.mu.edu!uwm.edu!psuvax1!atlantis.psu.edu!barr
  4. From: barr@pop.psu.edu (David Barr)
  5. Subject: Re: Return-Receipt-To & forwarding...
  6. Message-ID: <6x-1Houstb@atlantis.psu.edu>
  7. Sender: news@atlantis.psu.edu (Usenet)
  8. Organization: Penn State Population Research Institute
  9. References: <1i24ofINNaul@gaia.ucs.orst.edu> <davecb.725923251@yorku.ca>
  10. Date: Sat, 02 Jan 93 10:21:14 GMT
  11. Lines: 41
  12.  
  13. In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
  14. >  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
  15. >defines, as I already pointed out, a positive acknowlegement scheme
  16. >FROM THE SENDING HOST TO THE RECIEVING HOST.
  17.  
  18. Sorry, I have to agree with John Stanley on this one.  In addition
  19. to the scenario John mentioned, consider the following:
  20.  
  21. "user1@A" sends mail to "user2@B".  Mail for site B is handled by its
  22. MX, C.  Therefore, site C is configured to handle all mail for B in
  23. addition to its own.
  24.  
  25. 1. user1@A's MUA hands off mail to A's MTA.
  26. 2. Site A's MTA connects to MTA at site C.
  27. 3. Site C receives mail, acknowleges its recept.
  28. 4. Site C's MTA connects to MTA at site B.
  29. 5. user2 dropped out of school and therefore is no longer a valid
  30.    user at site B.  Site B nak's site C's delivery of mail with
  31.    "user unknown".
  32. 6A. Due to a failure in the DNS configuration of site A, when site C
  33.    tries to send a bounce to user1@A, it gets "host unknown" and
  34.    site C promptly drops the bounce to the floor.
  35. or
  36. 6B. Due to an improperly configured mailer at site A, the "From"
  37. and/or "Reply-To" addresses are munged and unparseable.  Site C
  38. drops bounce to the floor.
  39. or
  40. 6C. Site C's /usr/spool/mqueue fills up and has insuffient disk space
  41. in order to generate a bouce message.
  42.  
  43. What say you now?  Listen to John, you need to get out more.  SMTP may
  44. be reliable, but SMTP is only a part of the picture, regardless of what
  45. the pretty ASCII picture on page two of RFC821 says.  I suggest you
  46. read the section "Reliable Mail Transmission" in RFC 1123, the
  47. "Requirements for Internet Hosts".  Pay close attention to the words
  48. "SHOULD" and "MUST".
  49.  
  50. --Dave
  51. -- 
  52. System Administrator, Population Research Institute    barr@pop.psu.edu
  53. #define ENOTTY          25              /* Not a typewriter */
  54.