[liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[Rich Kulawiec]

On Mon, Nov 02, 2015 at 09:13:08PM +0100, carlo von lynX wrote:
[ a bunch of good points and one thing I'd like to expand/elaborate on ]

> Correct. Still it makes no sense for benevolent nodes to fabricate
> false warnings about insecure TLS usage. Question is if it makes
> sense for malevolent nodes to do so, maybe in order to distract
> from something else.. or if it doesn't make sense for them either.
> If it doesn't, then warnings in "Received" headers are useful even
> if they aren't securely delivered.

In the sense that those warnings indicate a "best case", and that
reality might be worse, yes, it does make sense to consider them.

But let me return to the first sentence above.  No, it doesn't make
any sense for benevolent (or let's say, neutral) nodes, to fabricate
false warnings, but those same nodes exhibit broken behavior all day,
every day...thus furnishing us with an ongoing stream of evidence
that we shouldn't trust their expressed opinions on *anything*.

The sad reality is that in the race to the bottom (in terms of
incompetence and negligence) the 500-pound gorillas of the email
world are leading.  (Which is another reason why I counsel everyone
to avoid them: security/privacy aside, they're junk.)  We see
erratic, aberrant, and abusive behavior emanating from these
operations constantly.  So presuming that their "Received" headers
are somewhere between "right" and "fiction" is actually a
pretty good working assumption.

One of the points that I've made for many years is that competently
managed operations do NOT emit abuse on a systemic and chronic basis.
Point problems?  Sure.  Temporary problems?  Sure.  But when the abuse
goes on for years and clearly pervades the operation, we are left with
only two possible conclusions:

	1. They're doing it on purpose.
	2. They're not doing it on purpose.

If it's (1), then they're malevolent and cannot be trusted.
If it's (2), then they're incompetent and cannot be trusted.

Either outcome has the same operational impact: we can't believe
anything their servers tell us, because it might be correct or might
be a mistake or it might be a deliberate fabrication.  Absent
evidence not available to us, we not only don't know, we can't know.

It's a pity, really, that we've arrived at this situation.  But here
we are, and there is no sign that it'll change -- why should it?

---rsk