home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / bit / listserv / maill / 246 < prev    next >
Encoding:
Internet Message Format  |  1992-10-15  |  5.7 KB

  1. Path: sparky!uunet!stanford.edu!lll-winken!bu.edu!wupost!newsfeed.rice.edu!rice!is.rice.edu!schafer
  2. From: schafer@is.rice.edu (Richard Alan Schafer)
  3. Newsgroups: bit.listserv.mail-l
  4. Subject: Re: questions on mail to bitnet nodes
  5. Message-ID: <Bw4D7E.Bwz@rice.edu>
  6. Date: 14 Oct 92 16:16:26 GMT
  7. References: <MAIL-L%92101320174177@BITNIC.EDUCOM.EDU>
  8. Sender: news@rice.edu (News)
  9. Organization: Rice University
  10. Lines: 105
  11.  
  12. In article <MAIL-L%92101320174177@BITNIC.EDUCOM.EDU>, SXKAC@ALASKA.BITNET (Kurt
  13. Carlson) writes:
  14. |> BITnet messages from our system are posted from MAILER@ALASKA
  15. |> direct to the recipient (not any mailer defined within XMAILER NAMES)
  16. |> Class=M, Name=sender_userid, Type=Mail, with appropriate
  17. |> RFC822 headers.
  18.  
  19. Why not?  By doing so, you're bypassing the place that those sites have
  20. said they wish to receive mail.
  21.  
  22. |> Occassionally, users at our site foul up the recipient userid.
  23. |> We've encountered several VM sites running RSCS v3 which are
  24. |> sending non-delivery notifications as files back to MAILER@ALASKA
  25. |> which is, needless to say, less than desirable.  My understanding
  26. |> is that this is an RSCS v3 function and the original messages
  27. |> never made it to their mailer as it was posted directly to the
  28. |> user.
  29.  
  30. Yes, if you try to send mail directly to an invalid user, RSCS will 
  31. recognize this and complain.  Their mailer (as you say) never gets
  32. involved at all.  (Another reason why what you're doing is a bad idea,
  33. since the user may have been forwarding their mail using mailer functions.)
  34.  
  35. |> My questions:
  36. |> 
  37. |>  1.  Must we (or even just "should we")  respect XMAILER NAMES and
  38. |>      post bitnet messages to the registered mailer in bsmtp packaging?
  39. |> 
  40. |> We have not done this to date for BITnet messages as we've not felt
  41. |> obligated to and it is more efficient not to.  We do, of course,
  42. |> package bsmtp and use DOMAIN NAMES registered mailers for gated
  43. |> internet messages.
  44.  
  45. "Must we"?  No, probably no more than you're obligated to send
  46. RFC822 format mail instead of VAXMail notes with :: things in the headers.
  47. Must I send your users mail in English, or can I use Sanscrit if that's more
  48. efficient for me to write?  
  49.  
  50. "Should we"?  Absolutely.  Those sites had told the world "We are running
  51. a post office function, please send mail to us there".  You're ignoring
  52. their stated wishes, and denying them the ability to handle things like
  53. mail forwarding that they have setup using their mailer.
  54.  
  55. "More efficient"?  Perhaps in some way it's more efficient for you to
  56. generate the mail, but in the long run, the efficiency is certainly not
  57. to ignore other sites configurations.  The problem that caused you to send
  58. your note is an example of an "inefficiency" you're causing yourself by
  59. having something which appears to be a mailer refusing to send to other
  60. people's mailers.  
  61.  
  62. Frankly that question almost comes down to: "Why should I care if the people
  63. on the other end have trouble reading my mail, if it's harder for me to 
  64. send it in a fashion that they can read easily?"
  65.  
  66. BSMTP packaging is really just icing on the cake, although perhaps at
  67. the root of your "efficiency" issue.  Although you *should* put BSMTP
  68. envelopes around your mail if you can, I'd rather have mail be sent to
  69. my mailer without a BSMTP envelope than have it sent to my userid directly.
  70.  
  71. |>  2.  Should sites in general accept direct posts irregardless of
  72. |>      a registered mailer?
  73. |> 
  74. |> We accept direct or to MAILER@ALASKA, all of which are passed through
  75. |> our mailer which will bounce non-deliverables back to the recipient.
  76.  
  77. Yes, you should accept direct posts.  The guiding principle should always be
  78. to get the mail delivered.  Of course, if accepting direct posts means
  79. that the mail is unreadable by the user in any fashion, then I'd probably
  80. change my mind.  But you clearly say that's not the case.  In fact, you're
  81. taking direct posts and passing them to your mailer, probably taking advantage
  82. of the way JNET handles NJE traffic to do so.  For other systems, that
  83. may not be feasible.  Seems odd to me that if you think your mailer is so
  84. important that you do this, that you wouldn't believe other sites mailers
  85. are important enough to send to them, too.
  86.  
  87. |>  3.  In the event of non-deliverable messages, are there any
  88. |>      standards on how they should be processed?
  89. |> 
  90. |> Most sites, us and the RSCS v3 sites in questions, endeavor to process
  91. |> them automatically without human intervention.
  92.  
  93. I'd have to go back and read RFC1123 and RFC821 to be sure exactly what
  94. they say, but those documents do describe procedures for non-delivery.
  95. Certainly, returning the mail to the originator of the file is a standard
  96. action.  However, you should recognize that at the RSCS level, most systems
  97. who haven't coded special handling of things will not distinguish between
  98. a mail file and anything else.  That's probably why your mailer is getting
  99. the bounce-backs, since your mailer is the NJE originator of the file.
  100. Those sites run a mailer to deal with mail transport issues, which is yet
  101. another reason why you should send mail to their mailer when you know about
  102. it.
  103.  
  104. |> If there is some definitive CREN authorized document which answers these
  105. |> questions, that would be my preference.  Lacking that, I'll listen to
  106. |> whatever opinions are offered.
  107.  
  108. To be honest, I don't know if I've ever conceived of a site which ran a 
  109. mailer refusing to send mail to other sites mailers.  It seems basically
  110. unsociable, and counter-productive to me.  Whether there is a CREN
  111. document which specifically says that, I don't know.  A place to look
  112. might be the NEWTAGS DESCRIPT document which describes the tags in BITEARN
  113. NODES which define mailer information, but to be honest, I doubt that 
  114. it *requires* sites to send to those mailers if their sites has one.
  115. -- 
  116. Richard
  117.