Re: [anti-abuse-wg] 2011-06 Review Phase Extension
Jørgen Hovland wrote:
At 10:42 31/07/2012 (UTC), Tobias Knecht wrote:
So I'm really interested in hearing more reasons for your objection here no matter if you are talking about the "abuse-c:" or the "abuse-mailbox:" attribute.
Just to make things clear about real consequences of mandatory abuse-c:
1. None of our customers have an abuse department or abuse contact (and often tech person). We will therefore bulk update the abuse-c with the value from the admin-c handle.
Well, its your decision, if you like to reveal personal data via the abuse-c. In fact, you shouldnt do this. You could either: - set the abuse contact email address to abuse@customerdomain.de automatically and inform your customers, that this email address has to be read from now on - inform and educate your customers to tell you another address - you could set it to something like abuse-inetnum-x-x-x-x@hovland.cx and forward incoming mail to your (and now hidden) customers email address and if your customer does not like to have incoming mails mixed with his other mails, well, he could tell you another address - or set it to your own abuse address and handle incoming reports for your customer
2. The e-mail field in the role object (abuse-c requires a role object) is mandatory. We actually have customers that do not have an email address or haven't provided one (probably also dont want to provide one). In these cases, I guess the e-mail field will be populated with a bogus email address in the form "there.is.no@email.address" and perhaps insert remarks: with company URL instead etc.
What is absolutly ok. The proposol is not forcing resource owners to have a working abuse department, its simply forcing all objects to have a single place where to store abuse addresses. But: the proposal is a nice starting point to educate resource owners, so it would be really nice, if you make your customers aware of abuse problems and how your customer should deal with them. Kind regards, Frank -- -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi,
1. None of our customers have an abuse department or abuse contact (and often tech person). We will therefore bulk update the abuse-c with the value from the admin-c handle.
Well, its your decision, if you like to reveal personal data via the abuse-c. In fact, you shouldnt do this.
You could either: - set the abuse contact email address to abuse@customerdomain.de automatically and inform your customers, that this email address has to be read from now on - inform and educate your customers to tell you another address - you could set it to something like abuse-inetnum-x-x-x-x@hovland.cx and forward incoming mail to your (and now hidden) customers email address and if your customer does not like to have incoming mails mixed with his other mails, well, he could tell you another address - or set it to your own abuse address and handle incoming reports for your customer
And there is another even better solution. Since the "abuse-c:" will not be required for all inet(6)nums only for the direct allocations you do not have to set one up for your customer. You just leave it empty and yours or the one of your the company above you can be used. So it is not mandatory for everybody. If you decide that you want to handle abuse for all your customers do it like I said before. If you want your customers or one of your customers wants to do it by him self set up the "abuse-c:" for your/this customer. So you have to make the decision on how you want to handle things, the proposal just gives you the right tools. Thanks, Tobias
On 31/07/2012 4:59 AM, Jørgen Hovland wrote:
At 10:42 31/07/2012 (UTC), Tobias Knecht wrote:
So I'm really interested in hearing more reasons for
your objection here
no matter if you are talking about the "abuse-c:" or the "abuse-mailbox:" attribute.
2. The e-mail field in the role object (abuse-c requires a role object) is mandatory. We actually have customers that do not have an email address or haven't provided one (probably also dont want to provide one). In these cases, I guess the e-mail field will be populated with a bogus email address in the form "there.is.no@email.address" and perhaps insert remarks: with company URL instead etc. If the customer refuses to give an abuse e-mail address,
-----8X------- then the onus should fall back on to his ISP to provide a contact and then pass on the information or take action on the customers behalf. It is not only the _customer_ who impacted by SPAM, but also the ISP and the ISP in reality is merely delegating some authority to the customer, so in the end, it ought to be the ISP who is responsible and should take action, if the customer can't or refused to. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml
it will bypass todays whois restriction.
The RIR's whois databases have already been harvested and the data is being resold in spite of the policies and procedures. The current restrictions only serve to disrupt security services that need the data.
participants (5)
-
Arnold -
Frank Gadegast -
Jørgen Hovland -
lists＠help.org -
Tobias Knecht