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
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]
On Thu, 12 May 2022 05:23:07 +0000 (UTC) Micha__ Trojnara via stunnel-users [email protected] wrote:
Hi Javier,
stunnel is an encryption tool, and *not* a MUA/MTA,
Hi Micha__,
I haven't said that it is any kind of mail sever. I know is just the tool to encrypt the traffic, after years I should know... ;)
so it is not expected to be RFC compliant.
Then, so, we must understand the docs phrasing that it just allows STARTTLS command when used as client/server service?
Stunnel only had a very basic understanding of some application protocols to negotiate TLS.
My point of view of the functionality (as server, as client differs a little), is that Stunnel listens to the mail server, captures the reply, sends it to the client and adds 250 STARTTLS after the EHLO.
True that it changes the server response, and so have some knowledge of the protocol, but once there isn't a STARTTLS command from a client, maybe could just pass the dialog between client and server.
Ok, ok, is beyond its functionality, but then it could be also compliant with that RFC paragraph.
Maybe is me that wanted to use it too far, or just I expected what I told, to transfer the server-client dialog to the peers and act as dummy in case of STARTTLS command absence.
While encryption may be an optional feature in other applications, Stunnel is specifically designed to ensure encryption for users who want their data encrypted.
I know and so I use it for, I just considered the option that could do what I explained. Place it in the middle of a mail server and not only encrypt but pass plain text traffic and so RFC compliant.
Have you considered using an email relay server instead?
Update to a mail server software with full encryption support should be the option, without discussion :)
My thoughts were more on a receiving server with the old mail server I use, accepting connections, not relying, and wait for STARTTLS from other MTAs if they wish, and so be RFC compliant, as not every MTA out there (mabye to date yes, who knows) encrypts SMTP traffic between MTAs as the preferred option, or even not implemented.
Another story would be acting as relay server with encryption for every MX out there. The same problem as those who intend using Stunnel as an HTTP proxy server (can't work dynamically).
Without discussion, then you need another mail server software.
Also, to date, is almost impossible to use a home server for relay. Accept, no problem, but relay... it is almost impossible, unless a fixed IP. Two decades ago was another story. Talking just plain text.
So an external relay server is a must, for a home server.
In the end I see why I was wrong in my assumption. Hope this thread helps others solve the same doubt :)
Regards.
Hi Javier,
Becase the MTA-MTA case differs from the MUA-MSA case, what we really would need is another "protocol option" eg smtp-with-optional-starttls or perhaps a shorter name like smtp-mx. It wouldn't be a general solution to try and automatically distinguish solely by port-number.
Although there are use-cases for this, are they enough to add what is (a bit of) proxying logic into what was originally intended to be a transparent transport-level tunnel? Is there anyone else on the list wanting to use stunnel for MX-MX communication?
-- Mike
On Thu, 12 May 2022 09:18:19 +0000 (UTC) Mike Spooner [email protected] wrote:
Is there anyone else on the list wanting to use stunnel for MX-MX communication?
Hi,
probably not, just me ;)
I just made an assumption and now all is clear :)
Regards.
Javier,
On the logging front, stunnel logs for such a optional-STARTTLS MX-MX connection could still be useful, eg: when the parties cannot agree on a cipher spec, etc.
-- Mike
-
Javier -
Michał Trojnara -
Mike Spooner