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