"Christian Huitema" <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
