[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stunnel-users
Subject:    [stunnel-users] Re: Is stunnel really compliant with RFC 2487 / RFC  3207 ?
From:       Javier <jamilist.stn () gmx ! es>
Date:       2022-05-13 0:01:34
Message-ID: 20220513020134.814169395a4e113deef4f241 () gmx ! es
[Download RAW message or body]

On Thu, 12 May 2022 05:23:07 +0000 (UTC)
Micha__ Trojnara via stunnel-users <stunnel-users@stunnel.org> 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.
_______________________________________________
stunnel-users mailing list -- stunnel-users@stunnel.org
To unsubscribe send an email to stunnel-users-leave@stunnel.org
[prev in list] [next in list] [prev in thread] [next in thread]