cancel
Showing results for 
Search instead for 
Did you mean: 

Inbound SMTP

SOLVED
Go to solution
Allan Large
Frequent Advisor

Inbound SMTP

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

14 REPLIES
P Muralidhar Kini
Honored Contributor

Re: Inbound SMTP

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
Let There Be Rock - AC/DC
Allan Large
Frequent Advisor

Re: Inbound SMTP

$ 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
$
Allan Large
Frequent Advisor

Re: Inbound SMTP

FYI .... outgoing SMTP works fine. It is incoming SMTP connections that won't work.
Volker Halle
Honored Contributor

Re: Inbound SMTP

Allan,

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

Any OPCOM messages ?

Volker.
Steven Schweda
Honored Contributor

Re: Inbound SMTP

> [...]
> %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.
Allan Large
Frequent Advisor

Re: Inbound SMTP

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.
Allan Large
Frequent Advisor

Re: Inbound SMTP

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
Steven Schweda
Honored Contributor

Re: Inbound SMTP

> [...] 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.)
Steven Schweda
Honored Contributor

Re: Inbound SMTP

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

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

Re: Inbound SMTP

> $ 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.
Steven Schweda
Honored Contributor
Solution

Re: Inbound SMTP

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.)
Andy Bustamante
Honored Contributor

Re: Inbound SMTP

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.

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Allan Large
Frequent Advisor

Re: Inbound SMTP

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.
EdgarZamora
Trusted Contributor

Re: Inbound SMTP

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.