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

[Simon Josefsson <[e-mail]>]

"Christian Huitema" <[e-mail]> writes:

> On Saturday, October 24, 2015 3:46 PM, John Levine wrote:
>> ...
>> 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.
>
> That sounds like a reasonable plan. Let's start, then. What about having
> interested parties meet at a bar in Yokohama, say Monday evening, and start
> drafting the first solution? I would be happy to pay the first round of
> drinks, if that speeds up consensus...

Sounds like a good idea, thanks for suggesting it.  I'm hoping Linus
will be able to make it since I won't be there.

I am concerned about taking on a too wide scope.  I think it may be
possible to reach closure on improving the Received header wrt privacy.
I'm not against taking on the larger problems mentioned above, however I
feel that it should not stand in the way of progress of fixing some
identified problems of the Received header, and I worry that a wider
task may not reach closure.

To have a starting point for a problem statement for what I'd like to
focus on, the Received header, I would propose:

1) The Problem: SMTP agents add IP addresses and timestamp information
   about its clients in the Received header, in a way that clients
   aren't able to influence.

2) Deployment Consideration: Received headers are useful for mail loop
   detection and debugging by humans, and must continue to serve that
   purpose as good possible, so as long as it doesn't violate the
   privacy problem identified in 1).

3) Work-together Consideration: If there are deployment of related ideas
   already, we want to follow and describe them as long as it solves the
   problem in 1) and retain the useful properties in 2).

4) Simplicity: Pick the simplest solution that meets the requirements.

I'd like to get away from the focus on SMTP submissions, the privacy
violation affects all SMTP relaying.  Submission may be the most
critical part, but there are other situations when you don't want your
client's IP address or time of communication to leak.

/Simon