On Thu, Aug 01, 2019 at 12:54:07AM +0300, Scott Christopher wrote: > Rich Kulawiec wrote: > > > On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote: > > > Because it will get spammed if publicly listed in WHOIS. > > > > Yes. It will. Are you telling us that Amazon, with its enormous financial > > and personnel resources, doesn't have ANYBODY on staff who knows how to > > properly manage an abuse@ address -- part of which includes dealing > > with that exact problem? > > They do, but it's just time-consuming and inefficient. You can't spam-filter > the content of abuse@ obviously.
Actually, yes, you can -- but probably not in the way you're thinking, because if you do it *that* way you will break [some of the] required functionality. > But in addition to spam, random (read: non-technical) people will send > complaints outside of the usual purview of spam, network abuse, DMCA, > etc. They find some FAQ on the web telling them to determine the PoC on > whois.domaintools.com and then they start firing crap. This is not my first day on the job. I'm aware of what shows up at role addresses. However, handling the problems you enumerate here is a straightforward (albeit occasionally tedious) matter that any operations engineer above entry-level should be able to handle. Doubly so because people like me have done them the favor of writing about it (here and elsewhere), so they can use our experience without needing to repeat our numerous mistakes. > I prefer openness and transparency and the general spirit of WHOIS but, in > practice, > you really do need the limit the PoC information to a trusted group of > insiders. First, there's no such thing as a trusted group of insiders. Second, even if such a group existed, limiting PoC information to them is impossible. Think about it. Third, besides WHOIS PoC, RFC 2142 (and decades of best practices) specify abuse@, postmaster@, etc. My expectation is that anyone equipped with baseline competence will be fully prepared to handle traffic to those addresses (as applicable) effectively at whatever scale their operation requires. ---rsk
