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

[Stephen Hoffman]

On 2018-01-25 06:11:44 +0000, Phillip Helbig (undress to reply said:

> In article <p4batu$usj$1 at dont-email.me>, Stephen Hoffman
> <seaohveh at hoffmanlabs.invalid> writes:
> 
>>>>> Why not receive it on VMS?
>>>> 
>>>> Sure.
>>>> 
>>>> If you're willing to post your usernames and passwords to the whole 
>>>> Internet.  Because that's what remote mail clients will do, when  
>>>> accessing OpenVMS.
>>> 
>>> If you send an email to me, where is a username or password involved?
>> 
>> I'll ignore the lack of STARTTLS support here, but that's a whole 
>> 'nother issue.
>> 
>>> Passwords for sending  email to VMS?  I'm confused.
>> 
>> Mail clients use credentials to access mail servers.   If you decided 
>> to hook up that iPad to that OpenVMS server for instance, you'd have to 
>> use an insecure connection.
> 
> OK.  But if I log into VMS (from a terminal, or in DECwindows, or from 
> outside via SSH) and read email with VMS MAIL, there are no passwords 
> involved related to mail.  Similarly if someone sends me an email.  Of 
> course, if you want to read email stored on VMS with some sort of POP 
> client or whatever (with which I have no experience) then that is  
> something different.

Hence my "remote mail clients" reference.

Few folks are interested in having to establish a VPN nor to use 
command line access via ssh to access mail.  Not when existing clients 
allow direct access, and not when the OpenVMS native command-line 
client can't deal with MIME encoded messages without added effort and 
an external MIME tool.   Which means that most folks running a mail 
server seek to enable and use remote access via TLS-protected IMAP and 
TLS-protected ESMTP.   Neither of which is available with TCP/IP 
Services.

Various clients that have been ported to OpenVMS — Seahorse and 
Communicator, for example — also use the network (remote) path to 
access the mail server.

Once the updated VSI TCPIP stack is available, it'd be appropriate for 
VSI to disable unencrypted POP and IMAP access by default.   Along with 
other insecure protocols and tools.  While we're migrating to the new 
stack, might as well move (most) folks toward more security.   But then 
there's more than a little "fun" here getting the rest of certificate 
authentication to work on OpenVMS, and getting certificate chains 
configured and available, too.



-- 
Pure Personal Opinion | HoffmanLabs LLC