> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Tuesday, November 01, 2011 7:49 AM > To: [email protected] > Subject: Re: [marf] draft-jdfalk-marf-redaction > > > 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.
I don't see how referencing RFC5322 clarifies your proposed scheme much. You seem to concur below. > > 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. There's a lot of needless complexity here. The main point is that the agent receiving the report doesn't need to know exactly what's been redacted. All it cares about is that the content of the redacted From and the unredacted From are isomorphic, so that behavioural patterns could be detected and reported. So these rules only really apply to the agent generating the report, and then the only important point is that it do so consistently. I think the current text says that already. So rather than come up with complex redaction schemes including guidance on how to select redacted segments right down to specific atom patterns, we only need to advise that the report generator do so uniformly and consistently, and the goal is met. Let those agents do so however they want. > > 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. All of that sounds reasonable to me. JD? -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
