On Sun, Nov 29, 2015 at 09:25:47AM -0800, Dave Crocker wrote:
I've seen essentially no public discussions, here or anywhere else,
about the technical aspects of this policy tradeoff.
Absent some community-based sense of the underlying technical issues
here, targeting a specification is, in my view, not ready for prime time.
I find myself in strong concurrence with this, and will add/augment
it, if I might, by saying that in the contemporary environment, we rely
on header-carried information far more than we once did.
To explain: once upon a time, many mail system operators made at least
a good-faith effort to support the "postmaster" role address, and to
at least read -- if not answer -- messages sent there. With the advent
of mega-providers, we've seen that disappear. I happen to think that
this is unprofessional and unethical: one should never build something
that one isn't capable of running properly. But my sentiments aside,
this is the reality we face.
And because we face it, we no longer operate in an environment where
queries to postmaster personnel will likely generate a response. We're
left with either (a) figuring it out on our own (b) consulting other
email people and hoping one of them has already figured it out or
(c) trying to page someone via the mailop or nanog mailing lists.
The approach of "Hey, could you grep this message-id through
your logs and tell me what just happened?" is pretty much dead.
I find myself learning about and using as much header-carried
data as I can in order to diagnose problems, or -- in some cases --
to try to ascertain if a problem even exists or where it might be.
So to borrow a word from part of Dave's message that I elided,
I find this "premature".
Let me also add that John Levine isn't the only one who has used
heuristics derived from knowledge of local mail patterns to build
anti-abuse systems. (See John's discussion in re how he handles
email from Cornell.) I do that everywhere I go because it's an
extremely powerful approach, it scales, and it yields systems with
excellent FP/FN performance while using few resources. It does
require having detailed knowledge of local inbound (and outbound)
traffic patterns, and it also requires using header information,
sometimes on a case-by-case basis. (And this approach is quite
often tractable even if on first glance it doesn't appear so.
Most operations exchange the bulk of their email with relatively
few other operations.)
I'm thus less than sanguine about removing header information
without a very carefully considered discussion about what's there,
why it's there, how it's used (by humans and software) and what
the privacy implications, if any, are.
As an aside: I think this kind of approach is becoming more useful
by the day, as I'm firmly convinced that [most] message-body scanning
is becoming less useful by the day.
One other thing to factor in (not related to Dave's or John's points):
Many spammers-for-hire and other unethical mail system operators now
embed tracking links in their messages. These are unique URLs keyed
to some tuple of {recipient address, message, etc.} and of course
their activation reveals recipient IP address, mail/web client version,
possibly recipient OS type/version, timestamp, etc. This form of spyware
is becoming increasing pervasive, to the point where I think it's worth
noting that all the header redaction in the world (and all the on-the-wire
and message-body encryption) will fail to protect recipient privacy as
long as this technology is extent and as long as recipients insist on
using web-capable mail clients.
---rsk
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp