home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2247 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.2 KB

  1. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!nigel.msen.com!emory!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!news.cs.indiana.edu!syscon!gator!inland!cmkrnl!infopiz!mccall!ipmdf-newsgate!list
  2. From: ned@sigurd.innosoft.com (Ned Freed)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: Documentation of PMDF's mail server access control
  5. Message-ID: <01GOFMPYBR8Y9S3VPQ@SIGURD.INNOSOFT.COM>
  6. Date: 6 Sep 92 00:42:08 GMT
  7. Organization: The Internet
  8. Lines: 81
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 05 Sep 1992 17:42:08 -0700 (PDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GOHM4RHNTE96VPKJ@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IPMDF
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18.  
  19. > I have recently set up an MTCP channel. It works fine on reception,
  20. > but delivery fails.
  21.  
  22. This error is not being produced by PMDF. It is being produced by the remote
  23. machine after PMDF successfully transfers mail to it. The Received: header
  24.  
  25.   Received: from chemna.dichi.unina.it by risc55.dichi.unina.it (AIX 3.1/UCB 5.61/4.03)
  26.             id AA03814; Wed, 2 Sep 92 15:09:13 -0500
  27.  
  28. clearly indicates that the message has been transferred. Once the message is
  29. transferred PMDF no longer has responsibility for it. This is therefore
  30. definitely NOT a PMDF problem.
  31.  
  32. The error messages
  33.  
  34.   >>> HELO risc55.dichi.unina.it
  35.   <<< 553 Local configuration error, hostname not recognized as local
  36.   554 <avitab@[192.135.165.26]>... Service unavailable: Bad file number
  37.  
  38. indicate that sendmail on risc55.dichi.unina.it is misconfigured.  It
  39. apparently does not know its own IP address.
  40.  
  41. I am not sure why you are trying to send to the machine's IP address anyway.
  42. sendmail is notorious for not supporting this sort of thing correctly.
  43. You might want to change the rules:
  44.  
  45.   risc55.dichi.unina.it                   $U%$D@mtcp-daemon
  46.   [192.135.165.26]                        $U%$D@mtcp-daemon
  47.  
  48. to read:
  49.  
  50.   risc55.dichi.unina.it                   $U%risc55.dichi.unina.it@mtcp-daemon
  51.   [192.135.165.26]                        $U%risc55.dichi.unina.it@mtcp-daemon
  52.  
  53. This will avoid the use of the IP address that sendmail cannot handle.
  54.  
  55. I note, however, that the DNS is incorrectly configured for this machine. There
  56. is no A record pointing risc55.dichi.unina.it to [192.135.165.26] and there is
  57. no PTR record pointing [192.135.165.26] to risc55.dichi.unina.it. The machine
  58. is in fact on the Internet and reachable at its IP address. The lack of this
  59. information may actually be what's confusing sendmail.
  60.  
  61. > My machine is chemna.dichi.unina.it running VMS 5.5, PMDF 4.0
  62. > and Multinet 3.1.
  63.  
  64. Your machine is also not registered in the DNS. You do have an MX record, but
  65. MX records are no substitute for correct DNS information. Correct DNS
  66. information should be provided for all systems that are directly connected
  67. to the Internet.
  68.  
  69. > An example of delivery failure follows. I mailed a message to
  70. > risc55.dichi.unina.it, an IBM RISC6000, and I got the following
  71. > mail, stating the failure.
  72.  
  73. I beg to differ. The mail was sent to avitab@[192.135.165.26], not
  74. avitab@risc55.dichi.unina.it. Use of avitab@[192.135.165.26] is in fact
  75. working insofar as reaching the remote host goes, but the remote host is then
  76. failing to deliver the mail properly. This is not a PMDF problem.
  77.  
  78. > 1) Failures like this one happen with any destination
  79.  
  80. I quite frankly don't believe this is true either. In any event the example you
  81. provide does not demonstrate that such problems exist.
  82.  
  83. > 2) The RISC6000 machine is able to receive mail by SMTP at the
  84. >    same address I used, coming from other hosts
  85.  
  86. This is also incorrect. I sent mail not using PMDF to this system using its IP
  87. address and had similar problems with it. This simply confirms that the IBM
  88. system is not properly configured.
  89.  
  90. > I enclose my PMDF.CNF file. Any help will be appreciated.
  91.  
  92. There is nothing wrong with your configuration that I can see. You can
  93. make the change indicated above and it may serve to work around the
  94. problems with domain literals. However, the fact that the DNS doesn't know
  95. about risc55.dichi.unina.it may then prevent delivery. (You may have host
  96. tables that work around this problem -- I would not know about that.) But this
  97. is a DNS issue and not a PMDF issue.
  98.  
  99.                 Ned
  100.