[Ach] Fwd: E-Mail Protocol Security Measurements

Aaron Zauner azet at azet.org
Tue Jul 28 15:00:58 CEST 2015


Hi,

Pepi Zawodsky wrote:
>> If it could be proved that there are indeed no MTAs that
>> support 465, but no 25/STARTTLS, I would recommend removing 465 from
>> the exim config.
> 465/tcp is an _inofficial_ port used for SMTP with implicit TLS rather than STARTTLS. While that has benefits it’s mostly ignored in my experience. I haven’t seen any default configs where that is still enabled, if configured at all but commented out.
> 

From a recent scan:
7,114,171 - port 25 SMTP
2,931,512 - port 25 STARTTLS
3,417,165 - port 465 TLS (may be another service announcing TLS on this
port)
2,631,662 - port 587 SMTP
1,864,029 - port 587 STARTTLS

> 
> Azet and me talked about this recently and this is about the conclusion we came to. Azet, please correct me should I have made a mistake in concluding.
> 
> Forcing STARTTLS over 25 for MTAs is the only way we can improve this situation in the short term. That requires the common large Email providers to require it by a certain date. Unless we see companies like Google/Gmail, GMX, United Internet (Web.de), Yahoo!, Microsoft Live Email (Hotmail), Apple (iCloud) and Facebook require it, I don’t have any hope to raise that to a global requirement since everyone must play with them.
> 

Yep. It's about the big providers. But they don't want to loose
customers, right? So they can't really enforce anything if the small
mail provider a certain percentage of their customers write to does not
support it. Mail will not be delivered, customers will be angry and all
that.

There was also talk about penalizing mail providers that don't offer
strong encryption. But I don't really see how this is going to work in
the end -- because of the above. I don't think delaying mail for these
hosts is a viable option.

Recently an interesting proposal for the MUA<->MTA traffic came up
within the IETF, it's called DEEP (Deployable Enhanced E-Mail Privacy):
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

It's an excellent draft and I'd really like to see it deployed.

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150728/f60d5624/attachment.sig>


More information about the Ach mailing list