Conference lassie::ucx

5262.0. "UCX 4.1 SMTP mail not forwarding -- %UCX-E-SMTP_CFERROR" by CSC32::R_WILLIAMS () Fri Feb 21 1997 18:41

Hi,
    
    I have a customer in the USA that is having problems with sending mail
    to a user in Tokoyo.  The mail comes in as HOST::USER and the user has
    his mail forwarded via SMTP to the Tokoyo site.  He was getting a
    %UCX-E-SMTP_CFERROR error with the mail being sent.  This used to work
    with 4.1 on this system.  UCX 4.1 for VAX/VMS is the other node in his
    cluster and he has no problem with mail forwarding to Tokoyo.  I looked
    in the debug log file and could not see where the failure was occuring. 
    SMTP just seemed to stop processing the mail request.  The mail forward
    did seem to have a very long mail address line.  Not sure if this could
    be the problem or not.
    
    Your inputs are appreciated.
    
    Thanks,
    
    -Rick
    
    +++++
    
SYSTEM> ucx sho ver

  Digital TCP/IP Services for OpenVMS Alpha Version V4.1
  on a AlphaServer 2100 4/275 running OpenVMS V6.2    

SYSTEM> sh log *smtp*

(LNM$SYSTEM_TABLE)

  "MAIL$PROTOCOL_SMTP" = "UCX$SMTP_MAILSHR"
  "UCX$SMTP_ENABLE" = ".1.."

SYSTEM> ucx sho serv smtp/full
 
Service: SMTP
                           State:     Enabled
Port:               25     Protocol:  TCP             Address:  0.0.0.0
Inactivity:          5     User_name: UCX_SMTP        Process:  UCX$SMTP
Limit:              10     Active:      0             Peak:       1
 
File:         SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_RECV_STARTUP.COM
Flags:        Listen
 
Socket Opts:  Rcheck Scheck
 Receive:            0     Send:               0
 
Log Opts:     Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
 File:        SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_RECV_STARTUP.LOG
 
Security
 Reject msg:  not defined
 Accept host: 0.0.0.0
 Accept netw: 0.0.0.0

SYSTEM> ucx sho confi smtp
 
SMTP Configuration
                                                                   Options
Initial interval:   0 00:30:00.00       Address_max:    16       NOEIGHT_BIT
Retry interval:     0 01:00:00.00       Hop_count_max:  16       RELAY
Maximum interval:   3 00:00:00.00                                HEADERS
 
Timeout             Initial       Mail    Receipt       Data  Terminate
  Send:                   5          5          5          3         10
  Receive:                5
 
Alternate gateway:  CTAS1.AIGFPC.COM
General gateway:    CTAS1.AIGFPC.COM
 
Substitute domain:  HIDDEN, aigtk.aigfpc.com
Zone:               aigtk.aigfpc.com
 
Postmaster:         UCX_SMTP
Log file:           SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_LOGFILE.LOG
 
Generic queue       Queues   Participating nodes
                     
UCX$SMTP_AIGTK0_00     1     AIGTK0

SYSTEM> sh log *inet*

(LNM$SYSTEM_TABLE)

  "UCX$INET_DOMAIN" = "aigfpc.com"
  "UCX$INET_HOST" = "aigtk0"
  "UCX$INET_HOSTADDR" = "137.100.144.11"

SYSTEM> ucx sho interface

                                                           Packets
Interface   IP_Addr         Network mask          Receive          Send     MTU
 
 WF0        137.100.144.11  255.255.240.0         3138953       2829949    4348
 LO0        127.0.0.1       255.0.0.0                   1          1282   65535

SYSTEM> set def sys$specific:[ucx_smtp]

SYSTEM> sh log/table=* *smbsrvshr*

(LNM$SYSTEM_TABLE)

  "SMBSRVSHR_TV" = "SMBSRVSHR"

SYSTEM> sh que *smtp*/full/all

Generic server queue UCX$SMTP_AIGTK0_00
  /GENERIC=(UCX$SMTP_AIGTK0_01) /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) 
  /SCHEDULE=(NOSIZE)

Server queue UCX$SMTP_AIGTK0_01, idle, on AIGTK0::, mounted form DEFAULT
  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM] 
  /PROCESSOR=UCX$SMTP_SYMBIONT /PROTECTION=(S:M,O:D,G:R,W:S)

Generic server queue UCX$SMTP_AIGTK2_00
  /GENERIC=(UCX$SMTP_AIGTK2_01) /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) 
  /SCHEDULE=(NOSIZE)

Server queue UCX$SMTP_AIGTK2_01, idle, on AIGTK2::, mounted form DEFAULT
  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM] 
  /PROCESSOR=UCX$SMTP_SYMBIONT /PROTECTION=(S:M,O:D,G:R,W:S)


MAIL> show forward/user=ikemoto

IKEMOTO has mail forwarded to SMTP%"[email protected]"


MAIL> show forward/user=nakagawa

NAKAGAWA has mail forwarded to SMTP%"[email protected]"

++++
Failed return mail message:
==========================

From:	UCX_SMTP
To:	UCX_SMTP
CC:	
Subj:	Returned mail


---- Transcript of session follows ----
%UCX-E-SMTP_SNDERROR, Error detected while sending mail to SMTP%"MAILER-DAEMON@a
igtk0.aigfpc.com"
-MAIL-E-NOSUCHUSR, no such user !AS

---- Recipients of this delivery ----
SMTP%"[email protected]" (bounced)


---- Unsent message follows ----
Date: Mon, 21 Oct 1996 18:16:54 +0900
Message-Id: <[email protected]>
From: [email protected]
Subject: Returned mail


---- Transcript of session follows ----
%UCX-E-SMTP_SNDERROR, Error detected while sending mail to <[email protected]
.com>
-MAIL-E-LOGLINK, error creating network link to node !AS

---- Recipients of this delivery ----
<[email protected]> (bounced)


---- Unsent message follows ----
Return-Path: [email protected]
Received: by aigtk0.aigfpc.com (UCX V4.0 AXP);
	Mon, 21 Oct 1996 18:16:49 +0900
Received: by ctas1.aigfpc.com; (5.65/2.0/07Oct96-0541PM)
	id AA04870; Mon, 21 Oct 1996 05:18:50 -0400
Date: Mon, 21 Oct 1996 05:18:50 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON>
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]

   ----- Transcript of session follows -----
550 aigtk0.msmail.aigfpc.com (smtpl)... 550 Host unknown
554 <[email protected]>... 550 Host unknown (Authoritative answe
r from name server)


   ----- Unsent message follows -----
Received: from aigtk0.aigfpc.com by ctas1.aigfpc.com; (5.65/2.0/07Oct96-0541PM)
	id AA04519; Mon, 21 Oct 1996 05:18:50 -0400
Date: Mon, 21 Oct 1996 18:16:18 +0900
Message-Id: <[email protected]>
From: [email protected] (KANEKO)
To: [email protected]
Subject: test
X-Vms-To: NAKAGAWA
X-Vms-Cc: KANEKO

todoita??
================== RFC 822 Headers ==================
Date: Sat, 22 Feb 1997 08:01:02 +0900
Message-Id: <[email protected]>
From: [email protected]
To: UCX_SMTP
Subject: Returned mail

>       ----- Transcript of session follows -----
>    550 aigtk0.msmail.aigfpc.com (smtpl)... 550 Host unknown
>    554 <[email protected]>... 550 Host unknown
>    (Authoritative answer from name server)
    
    Have you looked at the DNS and BIND configurations? From outside
    aigfpc.com, none of those host names is listed in the DNS database, but
    all of them return MX records pointing to uu3.psi.com.
    
    -Tom

    Tom,
    
    Both systems in this cluser have the same name server.  We did taka a
    look and one node can send mail with no problem and the other node just
    started having this problem last week.  Not sure what the real problem
    is.
    
    -Rick

    I missed something in .0.
    
    I think all the information you need is contained in the received
    headers and error text of the bounced message (as it almost always is).
    The problem is likely to be in the sendmail configuration on ctas1,
    but something is consistently replacing the first token after the "@"
    with "aigtk0" and leaving the rest of the domain alone.
    
    First, however, I don't entirely understand this about the SMTP
    configuration:
    
    Zone:               aigtk.aigfpc.com
    
    Since there's really nothing _inside_ the domain aigtk.aigfpc.com, this
    causes _all_ mail to be relayed to CTAS1.AIGFPC.COM unless it's
    addressed to [email protected]. Nothing is sent direct to anywhere,
    _including_, possibly, mail addressed to [email protected].
    
    Looking at the received headers and the error message confirms that the
    "Host unknown" is, in fact, generated by ctas1.aigfpc.com, and that
    it's probably because "[email protected]" was changed to
    "[email protected]" somewhere. You need to:
    
    	a) look at the sendmail configuration on ctas1.aigfpc.com to see if
    	   it's been hacked to do something funky, and
    	b) figure out why they're relaying everything there in the first place.
    
    The errors that follow that (preceed it in the bounce message) have to
    do with trying to send back to "[email protected]". Is "kaneko",
    in fact, a local user? Where is his mail forwarded? The one after that
    has to do with trying to send mail back to
    "[email protected]", which should have been
    "[email protected]" - the same problem as the original
    error.
    
    -Tom
                     

    Thanks Tom for you analysis.  What is bazaar about this mail is that
    mail only has problems with just 2 users on the remote node.  Other
    users are getting mail from the one system.  I did not see anything
    strange in their mail folder.  I was just trying to figure out why 2
    users are having this problem.
    
    -Rick

    Also, if mail is sent directly to the SMTP% address, instead of coming
    in through DECnet and being forwarded via SMTP%, then it delivers fine.
    I was trying to figure out what could cause this strange behavior.

    Well, this is just personal opinion (based on some experience), but
    without a lot of knowledgeable tailoring of the sendmail configuration,
    a VMS<->UNIX mail connection is least troublesome if DECnet is used to
    forward from VMS->UNIX and SMTP is used to forward from UNIX->VMS.
    Which may be another way to say that UNIX/mail11v3/sendmail is a bit
    easier to tune as an SMTP<->DECnet gateway than VMS/VMSmail/UCX.
    
    Things like "SMTP%" can screw up many garden-variety sendmail address
    re-writing rules as can nested quotes resulting from multiple protocol
    translations. In addition, most VMS software grew up in a DECnet-only
    environment, so it tends to be happiest with DECnet addresses, and most
    UNIX software tends to be happiest with SMTP addresses.
    
    However, why this particular configuration is doing exactly what it's
    doing can only be answered by examining the sendmail logs and
    sendmail.cf on the UNIX host and/or by parsing some of the incoming
    addresses using "sendmail -bt" to see how the addresses are being
    rewritten by what rules.
    
    -Tom

    Tom,
    
    Thanks for your diligence with this.  I asked the customer to work with
    the DECnet folks and sure enough, it was a DECnet issue.  I will enter
    the extracts from that discussion for historical purposes.
    
    Thanks again.
    
    -Rick
    
    [analysis] - Joe's been working on this about a week, and the ucx
    people found that this wasn't even getting to ucx..
    
    he has a two node cluster, vax and alpha, with a common uaf file.  the
    mail from a system to a vax user that has forwarding to smtp%....set up
    works, but sending to the alpha, same user gets the error message...
    
    I finally found that he was using default decnet access, and we tried a
    directory to vax:: and axp:: and found that the axp directory returned
    an error about the directory not being found.....
    
    the uaf record for decnet pointed to sys$sysroot:[decnet] and was there
    on the vax, but not on the alpha.  We created one on the alpha and now the
    mail is going fine..