home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / mail / pmdf / 1982 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  4.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. From: dan@hmcvax.claremont.edu (Daniel C. Newman)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE: Postmaster notification for held msgs
  5. Message-ID: <01GMX0EOW7AOAM2ZDZ@HMCVAX.CLAREMONT.EDU>
  6. Date: 28 Jul 92 23:19:00 GMT
  7. Organization: The Internet
  8. Lines: 78
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 28 Jul 1992 15:19 -0800 (PST)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GMX0FK23ZM9GVWIR@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IN%"bob@camb.com"
  15. X-Vms-Cc: IPMDF
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18.  
  19. > I had situation where pmdf held some msgs after detecting a probable mail
  20. > loop.  I don't think I'd received any notification from pmdf (e.g., via
  21. > a mail msg to postmaster) when this occurred.  Did I miss it?  Should the
  22. > daily RETURN job report on held files if they stick around for too many
  23. > days?
  24.  
  25. No, you did not miss seeing an error report.  When a mail loop is detected,
  26. sending more mail is very, very dangerous.  Consider the case where the local
  27. host is not recognizing one of its names -- the typical cause of a mail loop.
  28. Now, suppose we send mail to the postmaster and the postmaster's address
  29. involves the unrecognized name.  The message to the postmaster will loop and
  30. loop until it is marked .HELD (20 loops) and yet another message will be sent
  31. to the postmaster. Mail then piles up and the postmaster still has no clue as
  32. to the problem.
  33.  
  34. Now, it's not hard to conceive of a loop whereby the looping mail multiplies.
  35. In such a case generating new mail is really, really dangerous.
  36.  
  37. The bottom line here is that when a mail loop occurs, something, somewhere is
  38. misconfigured (the local host, a remote host, who knows) and generating new
  39. mail messages (warnings to the postmaster) is clearly not a safe thing to do.
  40. PMDF therefore does nothing other than to rename the message file to *.HELD
  41. (this prevents PMDF from attempting further delivery attempts).  At present,
  42. it's up to the postmaster to notice such things.  About the only safe thing
  43. PMDF could do would be to issue an OPCOM broadcast of some sort.
  44.  
  45. Now for some general advice on what to do when you find *.HELD messages. [I
  46. know that Bob knows what to do, but I figure other people on this list may
  47. not.]
  48.  
  49. First, the occurrence of these loops are very rare and always indicate a
  50. misconfiguration somewhere.  There are two typical causes:
  51.  
  52. (1) A user has set up a forwarding loop (e.g., their mail on system A goes
  53.     to system B; their mail on system B goes to system A), or
  54.  
  55. (2) System A thinks that mail for user@host goes to system B; B receives
  56.     the mail but doesn't doesn't recognize that it is @host and sends the
  57.     mail back to A (or elsewhere) which then sends it back to B.
  58.  
  59. The way to determine what is going on is to examine the Received: lines in a
  60. *.HELD message.  PMDF, when it sees the local host occur 10 or more times
  61. (configurable with the PMDF option file options MAX_LOCAL_RECEIVED_LINES and
  62. MAX_RECEIVED_LINES) in the Received: header lines, will mark the message *.HELD
  63. and stop trying to deliver it.  Look at these received lines, see who the
  64. message is for and make sure that (1) is not the problem.  If (1) is the
  65. problem then undo the user's forwarding and discuss e-mail concepts with them.
  66. If (1) is not the problem, then it is undoubtedly (2).
  67.  
  68. If (2) seems to be the case, then the problem is either (2a) that the local
  69. host does not recognize one of its names, or (2b) the remote host which keeps
  70. on sending mail to the local host is confused.  In the former case, you
  71. probably need to add a rewrite rule to your PMDF.CNF of the form
  72.  
  73. unknown-host    $U@local-host
  74.  
  75. where "unknown-host" is the host name that is not being recognized and
  76. "local-host" is the official local host name associated with the local (l)
  77. channel.  It may be that the local host is a gateway and should be passing this
  78. mail on to another system, "other-host", in which case a rule of the form
  79.  
  80. unknown-host    $U@other-host
  81.  
  82. is probably appropriate.
  83.  
  84. In the case of (2b), you have to call the postmaster of the remote host and
  85. get them to fix things....
  86.  
  87. Now, after things are straightened out, rename the *.HELD file to *.00, [run
  88. pmdf_root:[exe]synch_cache.exe if you're using PMDF V4.1,] and then release the
  89. PMDF Delivery job in the MAIL$BATCH queue.  There's a good chance that the
  90. message will pass on to another PMDF channel queue directory (e.g., the local
  91. channel directory) and again be marked *.HELD.  This is normal; it happens
  92. because PMDF again sees the local host name appearing 10+ times in the received
  93. line.  Merely rename the file to *.00, [rerun synch_cache,] and then release
  94. the PMDF Delivery job yet again.
  95.  
  96. Dan
  97.