topic Re: Inbound SMTP in Operating System - OpenVMS

Inbound SMTP

Allan Large — Tue, 04 May 2010 13:00:42 GMT

We have an Alpha system running V8.3 TCPIP V5.6 ECO 5 and are experiencing a problem with inbound SMTP connections.

If you $ TELNET LOCALHOST/PORT=25 the connection is made but you don't get the normal SMTP 220 banner line nor does it respond to SMTP commands (HELO, etc). The commands do echo but otherwise do nothing.

We have rebooted --- reconfigured SMTP but to no avail.

Does anyone have any suggestions to help trace down the problem ?

$ telnet localhost/port=25
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host localhost, port 25
heloNET-I-ESCAPE, Escape character is ^]
quit
send
TELNET> exit
%TELNET-S-LCLCLOSED, Local connection closed
-TELNET-I-SESSION, Session 01, host localhost, port 25

Re: Inbound SMTP

P Muralidhar Kini — Tue, 04 May 2010 13:15:58 GMT

Hi Allan,

>> We have rebooted --- reconfigured SMTP but to no avail.
Is the SMTP configured and started up properly.
Whats the output of
$ UCX SHOW SERVICE SMTP/FULL

Regards,
Murali

Re: Inbound SMTP

Allan Large — Tue, 04 May 2010 13:17:37 GMT

$ ucx sho service smtp/full

Service: SMTP
State: Enabled
Port: 25 Protocol: TCP Address: 0.0.0.0
Inactivity: 5 User_name: TCPIP$SMTP Process: TCPIP$SMTP
Limit: 10 Active: 0 Peak: 1

File: TCPIP$SYSTEM:TCPIP$SMTP_RECV_RUN.COM
Flags: Listen IPv6

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:[TCPIP$SMTP]TCPIP$SMTP_RECV_RUN.LOG

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
$

Re: Inbound SMTP

Allan Large — Tue, 04 May 2010 13:19:10 GMT

FYI .... outgoing SMTP works fine. It is incoming SMTP connections that won't work.

Re: Inbound SMTP

Volker Halle — Tue, 04 May 2010 13:35:38 GMT

Allan,

did you look at the contents of SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_RECV_RUN.LOG ?

Any OPCOM messages ?

Volker.

Re: Inbound SMTP

Steven Schweda — Tue, 04 May 2010 13:53:00 GMT

> [...]
> %TELNET-I-SESSION, Session 01, host localhost, port 25
> heloNET-I-ESCAPE, Escape character is ^]
> [...]

You're talking too soon. A normal session
looks like:

alp $ telnet /port = 25 localhost
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host localhost, port 25
220 alp.antinode.info V5.6-ECO5, OpenVMS V8.3 Alpha ready at Tue, 4 May 2010 09:
25:59 -0500 (CDT)
quit
221 alp.antinode.info Service closing transmission channel
%TELNET-S-REMCLOSED, Remote connection closed
-TELNET-I-SESSION, Session 01, host localhost, port 25

(The "%TELNET-I-ESCAPE" line gets overwritten
by the SMTP greeting ("220 [...]"). Around
here, that takes about 8 seconds. I assume
that it's checking the client IP address
against a large SMTP.CONFIG file.)

You're not getting the greeting, so I'd guess
that the SMTP receiver is slow/hung.

You might try defining TCPIP$SMTP_RECV_TRACE
(to "1"), and looking for useful info in the
resulting log file(s)
(SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_RECV_RUN.LOG).

In general, I'd look around for files with
";32767", as this high-quality software tends
to create log files without a care in the
world, until it can't any longer.

Could be just a busy CPU, too. I can't
remember the reason (like so many things),
but I added this (among other things) to my
TCPIP$SMTP_RECV_RUN.COM:

[...]
$ run:
$ prio = f$trnlnm( "TCPIP$SMTP_RECV_RUN_PRIORITY")
$ if (prio .NES. "")
$ then
$ set process /priority = 'prio'
$ endif
$ run 'f$edit("sys$system:tcpip$smtp_receiver.exe","upcase")'
[...]

And, around here:

ALP $ show logical TCPIP$SMTP_RECV_RUN_PRIORITY
"TCPIP$SMTP_RECV_RUN_PRIORITY" = "4" (LNM$SYSTEM_TABLE)

My off-hand guess is that if I started TCPIP
in a batch job, this thing inherited a lower
process priority than normal. But I may be
venting vapors there. You might get some
actual info from SHOW SYSTEM and/or SHOW
PROCESS while a session is active. (But I
clearly thought that there was some reason to
stick that in there, at some far-distant
time, for some long-forgotten reason.)

And I've been putting it back, too, every
time an upgrade/ECO (silently) overwrites my
customized procedure, which seems to be
pretty often. I can see seven versions of
SYS$COMMON:[SYSEXE]TCPIP$SMTP_RECV_RUN.COM_ORIG,
dating back to 22-MAY-1998. But I digress.

Re: Inbound SMTP

Allan Large — Tue, 04 May 2010 15:16:56 GMT

Steven:

You may have hit on something here. In 5 consecutive tries to TELNET LOCALHOST/PORT=25 it actually took a minimum of 1 minute 50 seconds to display the 220 banner line and to accept commands. I guess I was getting impatient as far as the manual telnet connection goes.

However, this long delay is apparently too long as real incoming SMTP connections are timing out.

TCPIP services have been stopped / restarted interactively so I don't think priorities are an issue.

And I have checked for files with version limits > 32000 and have found none related to any TCPIP services.

Re: Inbound SMTP

Allan Large — Tue, 04 May 2010 15:28:13 GMT

Steven:

Setting the TCPIP$SMTP_RECV_TRACE logical didn't provide any insight as to why the delay:

$ run:
$ run SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE
send buf=220 sisko.asub.edu V5.6-ECO5, OpenVMS V8.3 Alpha ready at Tue, 4 May 2â
recv buf=HELO sisko.asub.edu\0d\0a
send buf=250 sisko.asub.edu Hello sisko, pleased to meet you\0d\0a
recv buf=MAIL FROM:\0d\0a
send buf=250 ... Sender OK\0d\0a
recv buf=RCPT TO:\0d\0a
send buf=250 <>... Recipient OK\0d\0a
recv buf=DATA\0d\0a
send buf=354 Start mail input; end with .\0d\0a
recv buf=Received: from sisko (147.97.16.21)\0d\0a
recv buf=\09 by sisko.asub.edu (V5.6-ECO5, OpenVMS V8.3 Alpha);\0d\0a\09Tue, 4 â
send buf=250 OK\0d\0a
recv buf=QUIT\0d\0a
send buf=221 sisko.asub.edu Service closing transmission channel\0d\0a
$ !
$ ! completed smtp receiver execution

Re: Inbound SMTP

Steven Schweda — Tue, 04 May 2010 15:37:19 GMT

> [...] 1 minute 50 seconds [...]

That is slow. At least it's not dead.
Around here, the SMTP receiver process name
seems to be TCPIP$S_BGxxxxx, and "SHOW SYST
/PROC = TCPIP$S_BG*" seems to show something
whose "Pri" wanders between 4 and 5 (when
it's running).

("tcpip show devi /port = 25", look for "25"
under "Local", but not "*" under "Remote
Host", and then "show devi /full bgXXXXX",
and get the "Owner process".)

> [...] I don't think priorities are an
> issue.

I value evidence more highly than confidence.

MONITOR SYSTEM or MONITOR PROCESS /TOPCPU
might reveal a too-busy-to-care system.

I assume that your SMTP.CONFIG file is not
crazy-large. (My 16k lines there account for
most of the sloth around here.)

Re: Inbound SMTP

Steven Schweda — Tue, 04 May 2010 15:39:23 GMT

> [...] 1 minute 50 seconds [...]

On the bright side, that should give you
plenty of time to look around while it's
getting nowhere.

Re: Inbound SMTP

Steven Schweda — Tue, 04 May 2010 15:44:00 GMT

> $ set process /priority = 'prio'

Hmmm. AUTHORIZE says:

Username: TCPIP$SMTP
[...]
Prio: 5
[...]

So, it's possible that I was trying to slow
it down rather than speed it up by setting
the process priority to 4.

Trust no one, I always say.

Re: Inbound SMTP

Steven Schweda — Tue, 04 May 2010 16:04:00 GMT

It's hard to believe that it'd cause trouble
for "localhost", but a DNS problem could
cause trouble for the SMTP receiver, too.

As usual, many things are possible. (Many
of those are unlikely, too, but "unlikely"
and "impossible" are spelled differently for
a reason.)

Re: Inbound SMTP

Andy Bustamante — Tue, 04 May 2010 17:16:53 GMT

Just a WAG, try TCPIP SHOW SERVICE SMTP/FULL and check for maximum and peak connections. If memory serves, the default limit is on the low side.

Re: Inbound SMTP

Allan Large — Tue, 04 May 2010 17:18:14 GMT

Steven:

Your comment about the SMTP.CONFIG prompted a thought ....

The file only had 2 lines GOOD-CLIENTS and RELAY-ZONES. Doing a process of elimination I found that a reference to a GOOD-CLIENTS specification was causing the delay because of a DNS lookup.

Anyway, removing the reference solved the delay, even though the domain specification was valid.

Re: Inbound SMTP

EdgarZamora — Thu, 06 May 2010 11:58:00 GMT

I was going to suggest DNS problems usually cause these types of issues but because he mentioned localhost I thought Nah, highly unlikely...

I like that phrase Steven... about unlikely and impossible being spelled differently for a reason.