[not sure if this is germane to the shutup list if I understand the charter there correctly, but I'll go along with it for now]
On 01/10/2016 05:36 PM, John Levine wrote: > In article <[email protected]> you write: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> Below is the announcement of a draft I just submitted that may be of >> interest to this list. The approach here is complementary to the other >> proposals I have seen along these lines (e.g., smtp-sts). >> >> Thoughts, reviews, etc. welcomed. > Interesting idea. I implemented it on my server mail1.iecc.com. That was quick :) > PS: Of course, there's no way you can tell whether it'll actually do > anything different if you set requiretls. The inability to detect, > much less penalize, lying strikes me as a problem. You're describing a mail server that not just hasn't deployed TLS and REQUIRETLS, but one that is being actively deceptive. There are more fundamental undetected issues even without REQUIRETLS. As a mail originator sending messages I consider sensitive, my biggest concern would be that my outgoing mail operator isn't lying about REQUIRETLS. There could easily be test reflectors that fail REQUIRETLS in various ways, i.e., not supporting TLS at all, not supporting REQUIRETLS, and offering certificates that don't meet various verification requirements. If the messages go through, the user knows that someone is lying. The more general cases of REQUIRETLS deception, particularly within an administrative management domain, may be hard to test, but those probably aren't the biggest areas of concern for TLS deployment either. -Jim _______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
