>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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
