Hi Stephen, On 6/7/14, 3:20 PM, Stephen Farrell wrote:
> I'm frankly amazed that that's not crystal clear to anyone who > has read all 2.5 non-boilerplate pages of the BCP. Or even just > the last two words of the 1-line abstract (hint: those say "where > possible.") > > Yes, source addresses leak information that affects privacy. But > we do not have a practical way to mitigate that. So therefore > BCP188 does not call for doing stupid stuff, nor for new laws of > physics (unlike -04 of the draft we're discussing;-) > > Adding new identifiers with privacy impact, as proposed here, is > quite different. This came up today in a discussion around spam and cybersecurity with at least one major service provider who has some pretty sophisticated cbyersecurity systems. Someone mentioned CGN and how entire groups of customers are blocked when a single IP address goes bad. We even experienced this on the IAB, by the way, when its MSP got blocked by an anti-spam site due to presumably someone else misusing them. Our architecture isn't really set up for IP address sharing or hiding. If your source address is naughty, the only back pressure I have at my disposal is to block it. If enough in an address range are bad, I might block a range, even if that means some small amount of good mail being blocked. Go to a lousy SP and this is what it gets you. But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I *might* do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Eliot
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
