[Info-vax] "SEND MAIL" doesn't send mail, mail stays in queue

[Stephen Hoffman]

On 2018-01-22 22:16:48 +0000, Marco Beishuizen said:

> On Mon, 22 Jan 2018, the wise Stephen Hoffman via Info-vax wrote:
> 
>> The existing mail server logs will usually give some details on why the 
>> connections are being rejected.  Start there.  Probably an 
>> authentication error, as a guess.  While it's usually easiest to use 
>> the gateway settings to route all outbound mail to a "newer" mail 
>> server, there's no authentication support available with that, short of 
>> add-on (replacement) software, or (easier) setting up a local relay via 
>> Postfix or some other mail server and from there along to the ISP.
> 
> The smtp configuration shows:
> 
> [...]
> TCPIP> show config smtp
> ...
> Log file:           SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_LOGFILE.LOG

What's in that log?   Or in whatever any reference in the 
TCPIP$SMTP.CONF file is pointing at?

>> Though I suspect it's not the case here, if you're trying to send SMTP 
>> mail directly, please post your domain and somebody can check DNS 
>> forward and reverse and MX settings for you.  That information is 
>> already known to anybody watching DNS, and the spammers and the rest of 
>> the gremlins routinely scan for and already already have those and 
>> other details and are already poking at any open TCP port 25 they find 
>> on the 'net.  Usually within minutes, lately.  If you're shy about 
>> posting that domain data, verify that forward and reverse DNS are valid.
> 
> The PWS is behind a modem/router with a firewall. First thing I would 
> like to do is to be able to send mail, with the mail server of my ISP 
> as the smart host. Receiving mail I'll try to config later using IMAP, 
> so the OpenVMS machine won't receive mail by itself.

That's a relay, and — if it's an authenticated relay, or requires (as 
many do) use of TCP 587 or maybe TCP 465, you're out of luck with 
OpenVMS.  You'll need a different stack or a relay via a different 
local mail server with relay capabilities, or remote mail server that 
allows wide-open connections.

>> Be aware that the default behavior for TCP/IP Services SMTP with either 
>> problems in the configuration file or no configuration file is as an 
>> open relay and with no errors displayed.
> 
> The smtp config shows a "NORELAY" so that's ok right?'

OpenVMS stopped using the TCPIP utility configuration tool a while 
back, and the documentation on the new file-based implementation is 
sparse.    In V5.7 and later, SMTP is largely managed via the 
under-documented configuration file TCPIP$SMTP_COMMON:TCPIP$SMTP.CONF.  
 It's basically documented by the comments in the template 
configuration file.

In general, I don't trust any mail server to correctly report, and 
would externally verify whether or not it's possible to relay through 
any SMTP server.  The gremlins will provide that testing service for 
free too, but that's not the best approach.

>> There are issues with the installation, as well.  TCP/IP Services lacks 
>> encryption support for client access, lacks STARTTLS and other details, 
>> and contending with spam invariably involves add-on pieces; there's 
>> little that's integrated.
> 
> True, the OpenVMS software isn't the latest and greatest. 

Much of it is antique.   And insecure.  VSI is working to resolve much 
of that, but even once the VSI TCPIP product — a VSI-branded version of 
Process Multinet — becomes available there's still the never-ending 
requirements for updates.

I wouldn't bother spending a great deal of time and effort learning 
much about TCP/IP Services, either.   This as it's soon all being 
replaced by VSI TCPIP, with a migration period provided for the folks 
moving applications and procedures from the current product.

Related: http://vmssoftware.com/pdfs/VSI_Roadmap_20171215.pdf

> But the Alpha is used to play with and learn OpenVMS with, and maybe as 
> backup. The system is behind a router so the security isn't that bas I 
> guess.

More than a few techniques are available that can bypass firewalls.    
And open ports to vulnerable servers is another discussion. 

Something to ponder around where we're probably headed with networks 
and firewalls and security: 
https://research.google.com/pubs/pub43231.html





-- 
Pure Personal Opinion | HoffmanLabs LLC