On 10/23/15, Simon Josefsson <[email protected]> wrote: > Hi Ned, > > Thanks for looking at the document! > > We are happy to make this more inline with what you and others are doing > or suggest to do. With the -00 we wanted to get the ball rolling, to be > able to discuss what to do about the problem. We don't care strongly > what the particlar approach is as long is it does its job. Given the > responses so far, I believe we even have some work to do on getting the > problem statement itself right, let alone the proposed solution. > > I agree with you about the problem related to loop detection (RFC 5321 > section 6.1), so agree that it is a valid argument for not making the > header optional. > > Jacob Appelbaum brought up that the trace information about what > authentication parameters were used can be interesting and does not > appear to be a significant privacy violation. So that's another > argument for retaining the header. He also mentioned that timestamp > information are problematic due to netflow related data. >
I think it should be possible to produce a general timing and to state the crypto (or lack of crypto) used for transmission. > 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. > Those both seem reasonable. > When I look at the ABNF for Received in RFC 5322 I'm confused as I don't > see how the normally used Received: headers on the Internet (i.e., with > 'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token > or the 'obs-received' token. Is this a RFC 5322 bug? The BNF in RFC > 822 and RFC 2822 appears to work. A feature!. ;-) All the best, Jacob _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
