OpenVMS Disable SMTP Listener but still send email

[Bryan Ross]

Maybe I'm missing the point, but the SMTP client is what sends mail.

The email "listener" is POP. Don't you just want to disable the POP server?

[Wim Van den Wyngaert]

If you only want to disable access to the listener, check ucx help set servi/acc.
You can limit the access.

Wim

[Joseph Huber_1]

Bryan,
the SMTP server is receiving the mail (and sends it to the destination mailbox).
POP has nothing to do with SMTP sending/receiving, it is a protocol to access user mailboxes on a remote node, wether it is a (the) SMTP or not.

[Steven Schweda]

> [...] set servi/acc [...]

Why didn't _I_ think of that? No, wait, ...

[Joseph Huber_1]

I stand claiming one can disable the SMTP receiver (TCPIP DISABLE SERVICE SMTP) at all, as long as the sender (the SMTP symbiont) is able to find a gateway.

I tried really hard on my system: removed general/alternate gateways, zone, local MX records, deassigned the TCPIP$SMTP_MX_IF_NOALTGATE logical: since my DNS server (not on VMS, so I can't remove it) still has an MX record, TCPIP$SMTP still can send.

The only question remains to be answered from Glyn after a test on his own system is: does it work like this ?

BTW: if there is no SMTP server on the sending system, then it should set a /substitute_domain, otherwise it sends out mails with un-replyable reply addresses.

[Joseph Huber_1]

Rethinking, it even has nothing to do with gateways, TCPIP services SMTP sender will directly contact the destination on port 25.

Only if the destination address is an MX domain name, it must be able to translate to a node address.

But sending turns out to be independent of any SMTP service connected to port 25 of the senders node.

But I wonder why Glyn wants to disable mail receiving at all ?

[Richard W Hunt]

I don't propose to speak for anyone else here, but having one-way SMTP is very common in an SMTP environment on a USA Dept. of Defense network, and it is done for security purposes.

I've got one for which the one-way setup was accomplished by our network team blocking STMP traffic coming towards my cluster at a firewall level. I have to use a mail relay server for outbound traffic and cannot pick up any inbound mail at all. It's a real pain, too, because the outbound relay servers remind me of cold molasses.

Before you ask... no, I don't know why they do that for OpenVMS, but then trying to tell a D.o.D. network guru that OpenVMS is not nearly as vulnerable as Windows is like talking to a brick wall. Except that the brick wall is probably far easier to recognize as such.

[Willem Grooters]

Just a blind guess - I cannot check at this very moment, but it might just do what you need.

Sending mail is done via queue(s) SMTP. Leave that in place.

Receiving mail _might_ be handled by a procedure behind port 25: if $ TCPIP SHOW SERVICE/PORT=25 shows a commandprocedure, that will be the one to handle incoming messages. What you might do is edit this file, or replace it with one that does _nothing_ else but EXIT (or read HELO - you'll ghet who's calling - and then drop).

Blunt but effective.

[Thomas Ritter]

Just to add to Richard W Hunt's note...we also only allow outbound SMTP and block all inbound at the firewalls.

2 cents.

[Willem Grooters]

On my previous mesage:

If a incoming coonect request is received on port 25, procedure TCPIP$SYSTEM:TCPIP$SMTP_RECV_RUN.COM is invoked (using TCPIP V 5.6) - in turn this runs program to process the message.
Not advisable - but you could think of changing this file, or replace it with another with the same name (or with another but you'd have to prepare TCPIP$CONFIGURE.COM for that. Not advisable either, for the same reason)).

If the system is behind a firewall, why not disable incoming mail on port 25, or transfer it to another port where you simply drop the message - or have no service defined at all. Big advantage: you don't have to mess around in the standard config ;)