In my opinion, the problem isn’t that great. As others have stated, you can locally enforce only STARTTLS on the receive connector or send connector locally to ensure that only encrypted transmission occurs. If the MTA doesn’t send/accept STARTTLS send an error message. That the host name is given, doesn’t really matter as most MiTM will still see IP SRC and IP DST so that’s given that transmission occurred. DNSSEC already will ensure the same IP, and RPKI can help on BGP hijacks, given this is still an ongoing process. In my opinion, the major issue is data at rest which would rely on PGP, S/MIME, et al. Another option would be DMTP, like I emailed off list which encrypts even headers. My guess though is that if this gains traction, there will be a corresponding law like CALEA for LEO to intercept. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Jan 12, 2019, at 5:09 PM, Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
I'm not sure why are being angry here.
For the record, this conversation isn't about TLS on port 26. It's about STARTTLS downgrade protection on port 25.
On Sun, Jan 13, 2019 at 3:33 AM Brian Kantor <Brian@ampr.org <mailto:Brian@ampr.org>> wrote: From this point forward, all mail containing the phrase "TLS on port 26" in the Subject line will be shunted into my junk mail box, unread, because I do not wish to see any more correspondence on this matter.
'procmail' is my friend. - Brian
On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote:
Hello Mr. Levine, [...]
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.