On 02/Sep/11 21:03, Barry Leiba wrote: >> The first paragraph of 9.3. Privacy considerations is overly >> restrictive. If the recipient provided an e-mail for a specific >> purpose and the sender uses it for unauthorized purposes, then it is >> spam and should be reported as such. Example: an e-mail address >> provided to a car dealer strictly for service updates that is used for >> marketing. In such cases there is an involvement but there is not >> permission for the specific messages. > > Shmuel is absolutely right, and I think that first paragraph should be > re-thought and re-formulated. A few thoughts on that: > > 1. Replacing the recipient's email address with an opaque token is > reasonable advice.
Yes, but it's not always required, otherwise we'd have recommended it in marf-base. > 2. But if the token is the same every time, so that the side > processing the abuse reports can correlate different spam messages > reported by the same user, that's a privacy leak. We've seen how > "anonymized" search information can be used to identify the > individual, and there are other effects here as well. I agree this is an issue, but keeping the same token is recommended by the marf-redaction draft. Perhaps, automatic reporting from spam traps needs some randomization. > 3. It's not valid to assume that the recipient has no relationship to > the spam sender, and there might very well be privacy issues involved > with associating the sender to the recipient. There are many ways in > which one can have an established relationship with someone without > having given them permission to send marketing (or other) email. I see two ways out of this. One is that recipients should first try to solve the issue themselves by contacting the sender directly (e.g. opting out), and only resort to abuse reporting after breaking any relationship with the sender. This is compatible with reporting abuse to collaborative pools à la Vipul's Razor. The other is to report spam only in case there is a certain confidentiality, so that there is no need to redact, except for formally obeying some over-restrictive law in some cases. This is only compatible with feedback loops where subscriptions are only granted subject to suitable conditions. > Let's do some re-thinking here. Let me point to the bracketed sentence in 9.3 [Should these be moved to a BCP?] and match that with section 7 of my recently posted draft: TBD, possibly repeat privacy considerations from other marf drafts. > Barry, as participant (but my chair hat is very near) Gosh, expressing a role as a distance from the relevant hat makes a boolean isomorphic to real numbers... I like that, I'd also apply for a fuzzy charter :-) _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
