Re: [perpass] draft-josefsson-email-received-privacy

["John Levine" <[e-mail]>]

>I agree with your recommendation to retain the Received header but
>modify what to put in it.  I believe the FROM clause should be removed
>completely, or we put in a "magic" (syntactically valid but semantically
>invalid) IPv4 or IPv6 address in it.  Similarily, implementations could
>put a magic time-stamp value in the field if they don't want to reveal
>when they received a particular message.

I was going to say it would make it impossible for me to send spam
reports, since I would have to way to tell who sent it, but then I
realized it would make no difference, since each received header my
system adds has a sequence number I can look up in the mail logs and
find out the connecting IP and time and a lot of other stuff.

But I'd like to back up a little.  You know how crypto people feel
when someone shows up with a wonderful new crypto scheme?  And then
when the someone says well, just tell me what's wrong with it?  Mail
is a lot like that.  It's much more complex and subtle than it
appears, even to people who've used it casually for a long time.

There are lots and lots of ways that a mail system can leak PII that
are unrelated to Received headers.  For example, MTAs look up the
connecting IP of each message in DNSBLs, they check SPF records, they
look up DKIM key records (which in my mail are unique for every
message), they look up DMARC records, they swap checksums with bulk
counting systems, they put stuff in Authentication-Results: headers,
and that's just what I can think of in two minutes.  When a mail system
is large enough that it has to spread the load across multiple MTAs,
there's more traffic among them to keep things in sync.

My suggestion would be to start by finding people who have experience
in large mail systems (Ned would be a good start if he has the time),
and then state clearly what you're trying to do.  It looks like it's
identifying and minimizing the amount of PII collected, reported (to
downstream consumers), and logged (for internal users) for incoming
mail.  Once you've done that, it'd be quite interesting to try and see
what gets collected, and what the tradeoffs are if you don't collect
it or don't report or log it.

R's,
John