home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / pmdfl / 2600 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.1 KB  |  43 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!auvm!INNOSOFT.COM!NED
  3. Errors-to: epmdf@YMIR.BITNET
  4. X-Envelope-to: PMDF-L@IRLEARN.BITNET
  5. X-VMS-To: IN%"Rollo.Ross@Levels.UniSA.Edu.Au"
  6. X-VMS-Cc: IPMDF
  7. MIME-version: 1.0
  8. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  9. Content-transfer-encoding: 7BIT
  10. Message-ID: <01GTFEAKREKI8WWDND@YMIR.CLAREMONT.EDU>
  11. Date:         Tue, 12 Jan 93 18:41:28 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN.BITNET>
  13. From:         Ned Freed <NED@INNOSOFT.COM>
  14. Subject:      RE: Empty MAILSERV list causes error message
  15. Newsgroups: bit.listserv.pmdf-l
  16. Lines: 25
  17.  
  18. In general it seems much riskier to me to fail to warn people that they
  19. are sending to an empty list. It seems like a great way to lose a lot of
  20. mail. You must also remember that lots of postmaster mail is deleted without
  21. ever being read, especially when it looks like a routine send failure of
  22. some kind... Sending such traffic to the postmaster is therefore not an
  23. effective solution in most cases.
  24.  
  25. It also seems to me that empty expansion lists are something that primary
  26. list maintainers actually _do_ want to know about. True, it may be
  27. inappropriate in some cases to return such information to the primary
  28. list maintainer, but in other cases the primary list maintainer may need
  29. this information to run the list effectively. The risk of the primary list
  30. maintainer acting in an inappropriate fashion seem far less than the risks
  31. of eliminating this information completely.
  32.  
  33. In any case, it is pretty easy to get PMDF to handle this in whatever
  34. way you like. You can arrange for any alias to override the error return
  35. addresses in a message. Just set things up so that the externally visible
  36. list address sets the error return addresses to either the local
  37. postmaster or <>. This will require another indirect file but that's no
  38. big deal. And the bogus address on the list will eliminate the possibility
  39. of the list ever emptying completely. The bitbucket channel can be used to
  40. process such bogus addresses.
  41.  
  42.                                 Ned
  43.