View Issue Details

IDProjectCategoryView StatusLast Update
0000984Main CAcert Websitemiscpublic2011-10-26 13:28
Reporterilluminat Assigned To 
Status newResolutionopen 
PlatformDefaultOSanyOS Versionany
Summary0000984: Requesting removal of admin@-Mailaddress
DescriptionMailaddress admin@domain.tld is suggested to confirm that a domain you like to add is under your control.
Admin is no common mail name, see RFC2142.
Additional InformationSee RFC2142:
TagsNo tags attached.
Reviewed by
Test Instructions



2011-10-25 01:10

reporter   ~0002636

RFC is only suggestion, not a standard.


2011-10-25 01:11

reporter   ~0002637

RFC is only suggestion, not a standard.


2011-10-25 15:25

administrator   ~0002639

RFC may not be named "standard XY" but it de facto is a standard. If you have a _good_ reason you may deviate from it but then you really should give a reasoning why you do. In our case it may be questionable whether we have such a good reason, because in contrast to the root@ which is well-known to be present on Linux systems I don't know if admin@ is used anywhere as default. Further it is questionable if all hosts have adequate measures to prevent a normal user from taking that address.


2011-10-25 16:10

reporter   ~0002640

You are just stupid if you think that removing admin@- will increase security of this (sorry for my bad language) shitty script.

If you want to talk about security you should remove silly guessing e-mail address of admin part of script and put whois database query instead.

Additionally - not always webmaster account belongs to domain owner.


2011-10-25 19:53

administrator   ~0002643

If we only restricted ourselves to the whois entries I would not be able to verify my domain because in the whois only my (admittedly not premium quality) hoster is present. Webmaster should only be assigned to the person who may control the web content so it's better than nothing definitely. The only address that really has to be present if there's a mail server is postmaster@ so maybe we should restrict ourselves to that, but then it would not work for many people who don't have postmaster set up because they're drowning in spam.

An actual improvement would be to do more than check as it's stated in the CPS but that won't happen right now, maybe in the not too distant future.

Just closing bugs without the core devs even have a look at it without a real consideration is not helpful however. If you want to help please be constructive, help us testing, write some actual improvements.


2011-10-26 09:52

reporter   ~0002658

reporters (like me) should not have the rights to change status or resolution (except closing own tickets).

admin is not commonly used on any system (neither *NIX nor Windows) and most mailers don't reserve that address for the postmaster/hostmaster/root/Administrator like it's done for webmaster/postmaster/hostmaster-addresses, so if you provide any form of freemail-like-service (completely open or just for a group (gamers-guild/friends/...)) someone could register such a address and misuse cacert.


2011-10-26 12:49

administrator   ~0002661

reporters having some extended access rights in the bug tracker is intentional. I don't want the system to get in the way, if someone abuses this trust we will notice, I will only have more restrictions if this happens excessively (basically like permissions in the wiki).


2011-10-26 12:55

reporter   ~0002662

Some constructive idea - why not to verify if user has a control over domain by request to add specific DNS record? How it would look like:

1. User want to add domain.tld.
2. System generates TOKEN: \w+{16}
3. User adds DNS CNAME record: cacert-[TOKEN].domain.tld that points to
4. User points his browser to cacert-[TOKEN].
5. System verify if CNAME record cacert-[TOKEN].domain.tld exist and points to


2011-10-26 13:28

administrator   ~0002663

That's what's I meant by multiple checks like it's defined in the CPS

Issue History

Date Modified Username Field Change
2011-09-24 22:30 illuminat New Issue
2011-10-25 01:10 MarekMazur Note Added: 0002636
2011-10-25 01:11 MarekMazur Note Added: 0002637
2011-10-25 01:11 MarekMazur Status new => closed
2011-10-25 01:11 MarekMazur Resolution open => won't fix
2011-10-25 15:25 NEOatNHNG Note Added: 0002639
2011-10-25 15:25 NEOatNHNG Status closed => new
2011-10-25 16:10 MarekMazur Note Added: 0002640
2011-10-25 19:53 NEOatNHNG Note Added: 0002643
2011-10-26 09:42 illuminat Severity major => minor
2011-10-26 09:42 illuminat Resolution won't fix => open
2011-10-26 09:52 illuminat Note Added: 0002658
2011-10-26 12:49 NEOatNHNG Note Added: 0002661
2011-10-26 12:55 MarekMazur Note Added: 0002662
2011-10-26 13:28 NEOatNHNG Note Added: 0002663