On 01.11.2011 10:55, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> Actually, I meant >> >> "redacted-encoding1" "@" "redacted-encoding2" "." "redacted-encoding3" > > So now we have to say which atoms get encoded and which don't. It's > getting pretty complicated.
RFC 5322 is complicated, using its ABNF we simplify our text. > We also have to consider that user full-names might need redaction. > "Murray S. Kucherawy" is six atoms, for example, and we'd have to specify > rules there too. Not necessarily, it can be replaced by "BCDEFGHI.KLMNOPQRST", ignoring quoted strings. > I think this way lies madness. As long as the redaction procedure is > applied consistently, both sides get what they want. I think that's as > far as we should go. Consider this string: To: "Murray S. Kucherawy" <[email protected]> and a possible redaction of it: To: "BCDEFGHI.KLMNOPQRST" <[email protected]> Is that sufficiently protective and non-disruptive? I agree it is uselessly difficult to specify how to do something like that, but I would at least add some (possibly real) examples. > Are there any other points to cover here, or is a WGLC in order? Perhaps, it is useful to mention that An abuse-reporting policy should specify the concept of "recipient(s)" of abusive messages, clarifying how that may depend upon who signaled the abuse and relevant domain names. Usually, it is the recipient's data that needs to be concealed, not the sender's. In particular, the following header fields contain mailbox or addr-spec tokens, and hence are likely to need redaction: * To, * CC, * the "for" clause of Received, * Delivered-To, * [add to taste]. If the From: header field contains a recipient's address, it may need redaction as well. In this case, it is important to replace it consistently so that the matching can still be recognized. In addition, unstructured fields, like Subject:, and the body may be searched for strings that match the recipient's name, surname, the local-part, or other private data that the server knows and thus might appear to be leaking from it if not redacted. Finally, the I-D lacks a one-liner section for terminology, e.g. 2. Terminology The terms local-part, addr-spec, [more?], are defined in [MESSAGE]. Where [MESSAGE] would point to RFC 5322, to be added. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
