🚀 go-pugleaf

In article <009620A8441C5360.20401486@cesi.it>, "Alberto Meregalli (SIC)"
<meregalli@cesi.UUCP> writes:
>As I specified, the 'connection' was 'refused' both while sending to
>the cluster alias and to the cluster nodes!
>But about that, MAYBE, I have found out something: my
>MX_STARTUP_INFO.DAT file looked so
>
>001NETLIB:*
>002ROUTER:V8530
>003LOCAL:V8530
>004SMTP:V8530
>004SMTP_SERVER:V8530
>004UUCP:V8530
>
>It seems to me that this is correct according to 1.2.1 in page 1-2 of
>the 'Message Exchange Instllation Guide' that states that
>
>        'the processing agents [...]can be run on any or all
>        nodes of the cluster [...] and will automatically cooperate
>        in providing their respective services'

SMTP_SERVER (the agent that was giving you trouble). isn't really a "processing
agent" for the purposes of that paragraph.  I admit, the documentation's not
too clear about this, but if you think about it, SMTP_SERVER *MUST* be running
on any node that's to accept incoming mail. Consider:  If you don't run
SMTP_SERVER on a particular node, then there's nothing listening on port 25. 
Hence, when another machine attempts to connect to port 25, your TCP/IP
software will refuse the connection.  This happens *BEFORE* *ANY* MX software
gets involved.

>But I only had all work as I changed the file to
>
>001NETLIB:*
>002ROUTER:*
>003LOCAL:*
>004SMTP:*
>004SMTP_SERVER:*
>004UUCP:V8530

To fix the problem you reported, you merely had to change it to:

001NETLIB:*
002ROUTER:V8530
003LOCAL:V8530
004SMTP:V8530
004SMTP_SERVER:*
004UUCP:V8530

Once the SMTP_SERVER processes the message and puts it in the QUEUE, the ROUTER
on any other node can handle it, and pass it along to the appropriate delivery
agent on any node.

>Now I have still the 'unknown host' problem, but at least not the
>'connection refused' one.
>
>Is the statement in the Guide incorrect? have I misunderstood it?
>is the trick somewhere else?

It's vague, and you misunderstood it, as explained above.

>>The bounces with "host unknown" don't sound like problems with the VAXes
>>at all, but perhaps a configuration problem on your Sun.  Including a
>>copy of one of these bounce messages might help in trying to track down
>>the problem.
>
>This is the message I get
>
>>From meregall Tue Oct 13 16:45:41 1992
>>Return-Path: <Mailer-Daemon>
>>Received: by sic5020.cesi.it. (4.1/SMI-4.1)
>>       id AB00286; Tue, 13 Oct 92 16:45:39 GMT
>>Date: Tue, 13 Oct 92 16:45:39 GMT
>>From: Mailer-Daemon (Mail Delivery Subsystem)
>>Subject: Returned mail: Host unknown
>>Message-Id: <9210131645.AB00286@sic5020.cesi.it.>
>>To: meregall
>>Status: R

OK.  It's not MX that's bouncing the mail, it's the mailer on the unix machine.

>>   ----- Transcript of session follows -----
>>421 Host mailhost not found for mailer ether.
>>550 meregalli@decvax.cesi.it... Host unknown

It can't find the host decvax.cesi.it.  It would appear that the unix host is
using nameservers rather than its local hosts database (if decvax is really
reachable from the unix machine), or that the mailer on that system is
misconfigured.  Judging from other things in the bounced header, I'd guess that
the unix machines mailer is very badly misconfigured.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.