On Sat, Sep 14, 2013 at 04:55:56PM +0100, Sabahattin Gucukoglu wrote:
On 14 Sep 2013, at 16:40, keld(_at_)keldix(_dot_)com wrote:
There are not that many MTA implementations out there so if we can persuade
implementers to provide STARTTLS per default, I see this as a path
with good chances to succeed. We could even advise implementers to generate
an auto-signed
certificate. This guidance could be done in an RFC.
How do you propose that receivers verify self-signed certificates?
They should not verify the self-signed certificates, per default.
As you say below, a self-signed certificate is much more secure than
a server without any certificate.
Furthermore, admins could install a proper certificate on top of default
installation.
Note that many MTAs (Exchange, notably) will fail delivery if STARTTLS is
offered, but verification does not succeed. This is stupid because Exchange
will happily deliver to hosts if STARTTLS is not advertised, so it's an
inconsistent policy. (The solution for postmasters is then to either
maintain a table of known stupid hosts, or [as in my case] just turn off
server TLS.)
Well, it is expected that there are implementations that are counter-productive
to enhancing security,
also from big companies. We will probably also meet resistance from security
experts trying to
diverge succesful specifications.
Yes, we could meintain a table of known stupid hosts. This could be in the form
of a RBL,
and it could be generated by periodically traversing the full DNS tree and try
to send a message to all
of the hosts with a port 25 open.
Best regards
Keld
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp