Hi! On 12/07/2011 07:43 PM, Frank Gadegast wrote:
Usally people have different mailboxes or mail addresses for different purposes.
I.e. your idea is to require every admin-c to have different mailboxes.
The proposal even helps here a lot to seperate personal email addresses from abuse email addresses, simply because the abuse-c has to be defined now.
There already is an admin-c. To force admin-cs to use different/multiple mailboxes, another attribute is necessary. That would be abuse-mailbox. This already exists, so everybody who wants to use it, can use it. It's just that currently nobody is forced to use it, if you don't want/need to use it, you don't have to.
So, everybody thats has to complain simply knows now who to contact
...that would be the admin-c. And following the proposal: in some cases following weird, diffuse, and sparsely defined policies maybe also an abuse-c.
and will nevermore bother somebodys personal email address like the email named in the admin-c (see an example below).
The email address listed in my admin-c object is not my private personal email, but the email address chosen for the admin-c - for being contacted in case of administrative issues. This is true for both role and person objects. If you don't want to be emailed personally, use a role object. If you don't want people to use a specific email - don't list it in your contact objects! Even if you chose for whatever strange reason to enter into a role or person object an email you don't want people querying the db to know/use, what you would need following that rationale is an abuse-mailbox attribute for that admin-c object. Not another -c object. (Actually I guess a new 'secret-email' attribute would fit best for your needs)
The other places will fanish just in the moment the abuse-c is introduced, simply because because every resource owner has to re-think, how a complaint should reach him.
Sorry, no. According to the proposal, there will be additional objects and attributes. And people are forced to 'accept' being bulk-spammed. That's it. The rest is prophecy (and experience suggests the opposite - see the remarks on contradicting abuse-mailbox and other attributes in this very same thread). Btw, a short hint for resource owners on how to be contacted: - list your postal address in the way you'd wish to be contacted by postal service - list the phone number you'd wish to be contacted by by phone - list the fax number you'd wish to be contacted by by fax, or leave it out if you don't want to be contacted by fax - list the email address you'd wish to be contacted by, or leave it out if you don't want to be contacted by email - list the abuse-mailbox email address you'd wish to be contacted by in case of abuse complaints in case you wish to have a special mailbox for those, or leave it out if you don't
If the resource owner does not like any confusion, he will have to remove abuse contacts from the remark section.
Non-sequitur. I'd say: to minimize confusion, let's not add the proposed stuff. :)
Its the usual reaction from somebody who likes to hide his personal responsibility:
Well I think my explanation was quite comprehensive. On the other hand I think trying to go ad personam in a technical discussion should not be accepted. ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. I'm working for ConSol*, and domain registration is not in my areas of responsibility or influence. Having said that - while wondering why, I mean it's not (well - it shouldn't be) your business - you might want to return to on-topic, non-ad-personam discussion. And what responsibility are you referring to? I mean, this sounds like I'm supposed to "take the responsibility to disagree with you"? Spooky...
hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ...
Thanks for providing the opportunity to point that out. There is no abuse-c (well...), there is no abuse-mailbox, but there's no no nothing: there is an admin-c, and that admin-c has (among other contact data) an e-mail.
And a personal email address, thats obviously not related to your company (mabye simple because a lot of spam and wrong complains is arriving there).
Again, all this is pulled out of thin air (much like the 'substance' of the proposal, if you ask me). It's a person object, in that regard 'personal email address' is probably formally right. And also: not surprising. :) I don't see how that is 'obviously not related to the company'. And regarding the rest of your statement, I don't quite understand what you're trying to say there.
You should really support the proposal, it will help you a lot.
Well actually, as I already explained, at least for the broad majority this proposal doesn't help, but complicates things and causes partly severe problems. So I don't really see a future for it... And this also doesn't really seem to change, it actually gets worse: in your reply I didn't find a single argument explaining or clarifying on the issues I mentioned, or bringing forward any new or neglected aspects. And experience shows that being attacked personally when trying to discuss a technical issue is a red flag regarding the subject and/or the motivation of the attacking party... I still failed to see who might be 'helped' by the proposed stuff, and how... I mean, I'm convinced the authors at least had to think this will somehow help them, but I don't see how... Regards, Chris