[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 <5692DAE2(_dot_)2050107(_at_)bluepopcorn(_dot_)net> 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp