🚀 go-pugleaf

Note:  I'm crossposting this because it looks like it covers material
that might find clues from, or be of interest to the readers of, several
newsgroups.  I've set followups to comp.os.os2.networking.tcp-ip since
it seems to be, at heart, a TCP/IP name resolution problem.


Background
----------

Last Monday morning, Ultimail 2.10.004 stopped sending my e-mail to the
Advantis SMTP server smtp-gw01.ny.us.ibm.net (165.87.194.252).  Instead,
all e-mail, whether sent while I was online or offline, was queued in my
\MPTN\ETC\MQUEUE directory. Each time MAILQ.EXE was run to try to upload
these messages, it failed, reporting that 

   "Some letters remain in the queue.
    A resend will be attempted the next time
    a network connection is established."

I reported the problem Monday to Advantis via www.ibm.net.

The problem cleared up about an hour later, but was back by 
Tuesday morning, and has persisted ever since.

Advantis' Document #305, "Ultimail Email for OS/2 Troubleshooting
guide", describes similar symptoms under Warp 3 Connect which can be
corrected by applying "ic10390.zip".  Unfortunately, I'm running Warp 4
and FixPak 6, and in any case the file has apparently moved since
Document #305 was last updated.


Problem Details
---------------

This appears to be a problem with MAILQ.EXE or SENDMAIL.EXE being unable
to locate the SMTP server.

The error file created by a failing session looks like this (wrapped):

-- sendmail.err ------------
92 98/06/12 11:06:38 550 rrs0059@ibm.net... Host unknown (Name server:
            smtp-gw01.ny.us.ibm.net: host not found)
----------------------------

The log file (which I've also wrapped) is a little more informative:

-- syslog.uml --------------
2 98/06/12 11:06:38 LAA000.86: SYSERR: putoutmsg 
    (smtp-gw01.ny.us.ibm.net): error on output channel sending
    "550 rrs0059@ibm.net... Host unknown (Name server:
    smtp-gw01.ny.us.ibm.net: host not found)": %m
----------------------------

However, I can 'ping' smtp-gw01.ny.us.ibm.net just fine.

At the time of the failure, here's what the RESOLV file looks like:
-- resolv ------------------
domain ibm.net           
nameserver 165.87.194.244
nameserver 165.87.201.244
----------------------------

Finally, I'm aware of at least one other user who is experiencing the
same problem.  However, as far as I can tell, he didn't see it until
late Thursday evening.

Workaround (temporary, I hope!)
-------------------------------

The following script, based on clues provided in a posting by Jorgen
Slings, _will_ upload my e-mail (or at least, it appears to) by (a)
makilg the RESOLV file vanish, (b) creating a "hosts" file with
smtp-gw01.ny.us.ibm.net's name and IP address, and (c) running
MAILQ.EXE.

-- domail.cmd --------------
del resolv.mlq        
move resolv resolv.mlq
copy hosts.mlq hosts  
mailq.exe             
move resolv.mlq resolv
del hosts             
----------------------------

Note: I do not normally have a HOSTS file present.

If I hide the RESOLV file and add a HOSTS file and then Send a message 
while online, it goes out cleanly without (as far as I can tell) being 
queued.

System:     OS/2 Warp
            FixPak 6 (XR0M006).
            IBM OS/2 LAPS           v5.10, CSD WR08400               
            IBM OS/2 LAN Requester  v5.04, CSD IP08406
            IBM OS/2 TCP/IP Stack   v5.10, CSD WR08400
            IBM TCP/IP for Warp     v4.00, CSD UN00000
            IBM Ultimedia Mail Lite
                   Client for OS/2  v2.10.4, CSD XR21588               

Dialer:     IBM Internet Dialer v1.67
Connection: dial-up only (SLIP)


Questions
---------

 1) What caused MAILQ to suddenly start failing? How do I fix it? 

 2) Does this failure indicate a problem (or "change") on Advantis' end?
    If so, can they correct it? What would they need to do?

 3) If it is, as it seems, a name resolution problem, why do some 
    mechanisms (e.g. ping) resolve the name correctly?

 4) On the lik... er, off chance (;-) that this problem was triggered by
    a change at the Advantis end, but they are not in a position to 
    correct it immediately, is there a simpler/cleaner/better way of 
    working around this?

Clues, hints, and suggestions will be welcomed.

And my thanks to Jorgen Slings (jslings@ibm.net), without whose 1995
posting to comp.os.os2.networking.tcp-ip I would have been at a complete
loss.


Frank McKenney            / OS/2 Advisor (OS2BBS)
McKenney Associates       / Richmond, Virginia / (804) 320-4887
Internet: rrs0059@ibm.net / TalkLink: WZ01123