hi Linus, +1 to the chorus of "thanks for writing this up".
I can't believe I'm going to pick 2119 nits on a -00, but here goes: "If you care about X, MUST NOT" is a weird construct. MUST is "an absolute prohibition", so putting it next to a conditional isn't quite right. What I think you mean is covered exactly by SHOULD NOT: "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." Of course, this sounds weaker than the nice hefty MUST NOT. But unless we want to deprecate the Received header completely and replace it with a less privacy-odious method to achieve operational debugging of SMTP (which i'd be fully in favor of, though I'm not an SMTP geek so I'm not sure what would be involved), this is as good as it gets. What is unconditional, and can be specified as such for implementations, is that operators need a knob. So I'd suggest splitting this out, replacing section 2 in its entirety with: SMTP protocol entities, including transfer agents and submission agents, MUST provide operators with a mechanism to configure whether a Received header will be added to the messages they handle. Operators of these protocol entities SHOULD disable the Received header using this mechanism in order to reduce risks to the privacy of the submitting entity. Thanks again, cheers, Brian > On 20 Oct 2015, at 20:28, Linus Nordberg <[email protected]> wrote: > > Hi, > > draft-josefsson-email-received-privacy-00 has been submitted, see > https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ > > I'd be interested in hearing what people on the perpass list think of > this. > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
