home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / vmsnet / mail / pmdf / 2461 < prev    next >
Encoding:
Internet Message Format  |  1992-10-09  |  3.9 KB
  1. Path: sparky!uunet!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. Newsgroups: vmsnet.mail.pmdf
  3. Subject: RE: Handling broken From:-addrs with PMDF-MR
  4. Message-ID: <01GPR0VPSPDC8Y4ZA9@SIGURD.INNOSOFT.COM>
  5. From: Ned Freed <ned@sigurd.innosoft.com>
  6. Date: 09 Oct 1992 15:54:33 -0700 (PDT)
  7. Organization: The Internet
  8. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  9. Resent-Date: 09 Oct 1992 15:54:33 -0700 (PDT)
  10. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  11. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  12. Resent-Message-ID: <01GPR0W2IXBM8WX5DM@YMIR.CLAREMONT.EDU>
  13. X-Vms-To: IN%"bob@camb.com"
  14. X-Vms-Cc: IPMDF
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18. Lines: 78
  19.  
  20. > It appears that the way I have configured PMDF-MR it bounces messages which
  21. > arrive from the Internet with invalid From:-headers (at least those ones
  22. > with syntax errors, given the attached example).
  23.  
  24. PMDF-MR does not care if the From: header does not convert. It will ignore any
  25. error produced and generate no header From: information in the Message Router
  26. message header. The original RFC822 header, bogons and all, will be left in the
  27. header attachment so no information is lost.
  28.  
  29. Header From: information isn't required by Message Router so there is no
  30. problem omitting it.
  31.  
  32. The envelope address is somewhat different. It is a mandatory element according
  33. to Message Router. So PMDF-MR does the following:
  34.  
  35. (1) It tries to parse and convert the address.
  36. (2) If (1) fails it uses whatever default address is specified in your
  37.     TO_MR.TXT file (usually the postmaster's address) and adds a note to
  38.     the message saying that a substitution was done.
  39. (3) The result of (1) or (2) is converted to MR formats and checked. If this
  40.     conversion or check fails the message fails.
  41.  
  42. The error you're getting
  43.  
  44.   WESTS@a1.decus.org: cannot convert originator address:
  45.      <AVLAB::MRGATE::"AM::westms"%avlab.dnet@aaunix.aa.wpafb.af.mil>
  46.      - mandatory USERID field was not produced
  47.  
  48. indicates that the check in (3) is failing. This means that either (1) or (2)
  49. is working but is producing a bogus address that will cause Message Router
  50. failures. (We do the check because Message Router doesn't.)
  51.  
  52. You can track this down in more detail by turning on slave_debug on the
  53. channel.
  54.  
  55. > Is this something that's hardwired into PMDF-MR, or is it something that I
  56. > control with configuration options?  [I didn't attach my to_mr.txt file, but
  57. > could send it to you if it turns out I broke something there.]
  58.  
  59. It isn't configurable. It makes no sense for it to be configurable.
  60.  
  61. > I can see a number of possible courses of action when msgs are received with
  62. > invalid From-addrs:
  63.  
  64. > 1. Bounce the message.  [I guess this sounds like the safest, but it seems
  65. >    violate the ``be liberal in what you accept'' philosophy.]
  66.  
  67. PMDF-MR does not do this.
  68.  
  69. > 2. Pass the message, mapping the From:-addr to something that will reverse
  70. >    map back (when a REPLY is done) to the same (invalid) address.
  71.  
  72. Cannot be done. Message Router limitations prevent this from being possible.
  73.  
  74. > 3. Pass the message, translating the From:-addr into one that is
  75. >    syntactically correct, but (admittedly) has little chance of being
  76. >   a symantic equivalent, with a warning msg (of course) that this has
  77. >   happened.  [This seems like a very bad idea to me.]
  78.  
  79. This is part of what PMDF-MR does.
  80.  
  81. > 4. Send the message on as an `enclosure' in a msg from the postmaster,
  82. >    with a note of what the problem was.  [This is what I'd do manually
  83. >    today, if I had the time...]
  84.  
  85. This is also part of what PMDF-MR does.
  86.  
  87. > If I had all the above choices available, I think I'd choose 2.
  88.  
  89. PMDF does this but it isn't possible when dealing with a system that fails when
  90. it encouters bogus addresses.
  91.  
  92. I note in passing that most other gateways will reject this sort of address and
  93. drop the message summarily on the floor. The offending site has to fix the
  94. problem if they expect to interoperate with practically any software besides
  95. PMDF and PMDF-MR.
  96.  
  97.                     Ned
  98.