Hi Javier,
stunnel is an encryption tool, and *not* a MUA/MTA, so it is not expected to be RFC compliant. stunnel only had a very basic understanding of some application protocols to negotiate TLS.
While encryption may be an optional feature in other applications, stunnel is specifically designed to ensure encryption for users who want their data encrypted.
Have you considered using an email relay server instead?
Best regards, Mike
12 May 2022 00:17:10 Javier [email protected]:
Hi,
first of all, I still use a 32-bit release (the latest, I think), so maybe things have changed on Stunnel since.
But the statement that the protocol smtp option for a service is compliant with RFC 2487, should be 3207 (it is from 2002!), has been in the docs for ages, even in the latest version, 5.64:
smtp
Based on RFC 2487 - SMTP Service Extension for Secure SMTP over TLS
Long ago I tested the protocol=smtp options as both, clients and server service, and I noticed that, and I think I told here to the list confirming it (maybe for some user using it on client mode), the option implied STARTTLS.
Back then I didn't pay much attention to it.
BUT the other day I was re-testing for a server service (own mail server sometimes I run) and... I said to my self that this shouldn't be like it was and well, I read the RFC and what tells is the following:
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.
https://datatracker.ietf.org/doc/html/rfc3207#section-4
So, if we use Stunnel to provide THE OPTION of secure TLS connections to other MTAs (MTA to MTA, or server to server) we are against the RFC itself as every connection to port 25 must be encrypted, or nothing, because, as Stunnel is the door to the port and only accepts the STARTTLS command, without redirecting any data to the mail server, no traffic on plain text reaches the server.
Acting as a MSA (users - servers) there is no problem because, even if it hadn't/hasn't been widely supported, there are two ports 587 for plain text and 465 for TLS. So Stunnel could be set up to listen on 465 port only, directly accepting TLS sessions or after STARTTLS command (rejecting, in this case, those that don't want a secure channel).
We have told several times, specially to newcomers (asking for http proxy, basically), that Stunnel isn't proxy, and it isn't, but in the case of a mail server it should act as is if we use it for a MTA mail server.
It acts as is sending the welcome message from the mail server to the other MTA, but once the other MTA doesn't send a STARTTLS command, it closes the connection when, actually, what should do is pass all the dialog between MTAs.
I think that is what Stunnel should do. And when just passing messages from mail server to the other MTA, just disable the logging for that connection. After all, the mail severs have already their own logs and there is no reason to log it on Stunnel, nor on the log screen/Stunnel window. Maybe just a line like "redirecting connection to the mail server".
Said all the above, do latest versions behave differently?
Do you think is a change that should be made to Stunnel to comply with the RFC, if on latest versions don't do yet, or am I wrong somewhere in my statement?
Regards.
P.S.: MTA: Mail Transfer Agent MSA: Mail Submission Agent MUA: Mail User Agent
stunnel-users mailing list -- [email protected] To unsubscribe send an email to [email protected]