18

I am in the process of conceiving this idea of a webApp when can be termed as a completely new take for providing Email Service to the consumers on Domains that I own. The idea is similar to what Yahoo does by providing me myname@yahoo.com email address or the same with gmail etc. Apart from the whole infrastructure the main concern I have is how to have a list of critical / important and security related email addresses that are not given out to the consumer.

For Example:

  • admin@example.com
  • administrator@example.com
  • webmaster@example.com
  • root@example.com

Is there any kind of exhaustive list of this kind available.

MrWhite
  • 42,784
  • 4
  • 49
  • 90
Maharshi Raval
  • 183
  • 1
  • 5

4 Answers4

22

Here is a list of addresses that you may want to treat as reserved:

  • abuse 1,4
  • admin 2,3,4
  • administrator 2,3,4
  • hostmaster 1,2,3,4
  • info 1,3
  • is 3
  • it 3
  • list 1
  • list-request 1
  • majordomo 4
  • marketing 1
  • mis 3
  • news 1
  • postmaster 1,2,3,4,5
  • root 3,4
  • sales 1
  • security 1
  • ssl-admin 4
  • ssladmin 3
  • ssladministrator 3
  • sslwebmaster 3
  • support 1
  • sysadmin 3
  • trouble 1
  • usenet 1
  • uucp 1
  • webmaster 1,2,3,4
  1. Listed in RFC 2142 as a mailbox name for a common purpose
  2. Used by Comodo to issue SSL certificates
  3. Incorrectly used by RapidSSL to issue SSL certificates
  4. Treated as a reserved group name by Google Groups
  5. Listed in RFC 822 -- Standard for ARPA Internet Text Messages as a reserved address

This article suggests that you reserve all mailboxes that start with "admin", "administrator", "webmaster", "hostmaster", or "postmaster". If I were doing that, I would also add "ssl" to my starts with rule. Based on what RapidSSL did, it would make sense to implement an "ends with" rule as well.

RFC 822 also has the reminder that mailboxes are generally case insensitive. You should reserve lower-case, upper-case, and mixed-case versions:

Note: This reserved local-part must be matched without sensitivity to alphabetic case, so that "POSTMASTER", "postmaster", and even "poStmASteR" is to be accepted.

Stephen Ostermiller
  • 98,758
  • 18
  • 137
  • 361
3

This might be slightly related list, although its not for Gmail, but for Google Groups for G Suite:

https://support.google.com/a/answer/6093413?hl=en

Reserved group names:
We reserve certain names that cannot be used if you are creating a group using Google Groups or Google Groups for Business. However, you can use these names if you are creating a group using the Groups control in the Admin console.

abuse
admin
administrator
hostmaster
majordomo
postmaster
root
ssl-admin
webmaster

The names abuse and postmaster are reserved. You can, however, subscribe to them and receive all mail sent to these addresses.

Community
  • 1
DavChana
  • 330
  • 1
  • 10
  • Thanks alot mate just the answer I needed. Just wondering, what majordomo stands for. Apart from the systesm names, I would also add the generic once like, sales, info, ceo , manager etc. But it is a long process. – Maharshi Raval Mar 23 '17 at 09:07
  • 1
    You are welcome :).. Just a long thought, do users have email addresses from single common english words also at Gmail? Like lion@, or aeroplane, or car. Am sure many of these can be instantly stopped if you enforce a minimum 7 letters username policy. Also, what about foul words? 7 word will stop dick@, but will not dickhead@ – DavChana Mar 23 '17 at 09:30
  • 1
    @MaharshiRaval majordomo = https://en.wikipedia.org/wiki/Majordomo_(software) – Steve Mar 23 '17 at 10:22
  • 1
    @DavChana yupp.. that makes a lot of sense. Would look into it , thanks a lot for bringing it up. Appreciate your time. – Maharshi Raval Mar 30 '17 at 10:24
2

Based off previous answers and my research elsewhere, I have compiled this GitHub repository which has an updated JSON file, as well as JavaScript/Node.js based code example for implementation.

https://github.com/forwardemail/reserved-email-addresses-list

List of 1250+ email addresses reserved for security concerns

npm install reserved-email-addresses-list email-addresses

The string you are comparing with must be converted to lowercase and trimmed of whitespace. The reason we are converting to lowercase is because the dictionary of words we are comparing with are all lowercase, and in order to compare for strict equality, we must have matching case.

It is also highly recommended that you check for strict equality, and for a list of admin-related usernames, you should check for strict equality, starts with, or ends with comparisons as well.

const reservedEmailAddressesList = require('reserved-email-addresses-list');
const reservedAdminList = require('reserved-email-addresses-list/admin-list.json');
const emailAddresses = require('email-addresses');

const email = '"Admin***!!!"@example.com';
const parsed = emailAddresses.parseOneAddress(email);

if (parsed === null)
  throw new Error('Email was not a valid address');

const str = parsed.local.toLowerCase();

let reservedMatch = reservedEmailAddressesList.find(addr => addr === str);

if (!reservedMatch)
  reservedMatch = reservedAdminList.find(
    addr => addr === str || str.startsWith(addr) || str.endsWith(addr)
  );

if (reservedMatch)
  throw new Error(
    'User must be a domain admin to create an alias with a reserved word (see https://forwardemail.net/reserved-email-addresses).'
  );

References:

  • "The string you are comparing with must be converted to lowercase, trimmed of whitespace, and strictly converted to alphanumeric characters only." Technically the left hand side of an email address is under control of the receiving MTA and can be case sensitive, if that MTA so decides, so lowercasing email addresses by default can be a problem. Also now email addresses are internationalized, so not only ASCII. The regex in your code example would even disallow - or . in the email address! – Patrick Mevzek Jan 29 '20 at 21:33
  • I have fixed the example so it uses punycode toASCII. –  Feb 03 '20 at 22:15
  • "I have fixed the example so it uses punycode toASCII." That handles only the RHS (that is the domain part), so it has no impact to the LHS, which is governed by EAI rules. – Patrick Mevzek Feb 03 '20 at 22:18
  • If you note in the example I have removed the conversion to A-Z,0-9 only. And the localpart is obvious in const str declaration. –  Feb 03 '20 at 22:21
  • Also @PatrickMevzek - this is for comparison only to find the most accurate/likely match given people may try to abuse systems, such as writing admin1 or admin_. –  Feb 03 '20 at 22:21
  • No matter what, toLowerCase is wrong here. You CAN NOT take any assumption on the LHS that is under control of the remote MTA. – Patrick Mevzek Feb 03 '20 at 22:21
  • No Patrick, you are incorrect. It is not wrong. The comparison is against a list of lowercased words. You cannot compare the two for strict equality or starts/ends with unless you either check for case insensitivity or convert it to lowercase. –  Feb 03 '20 at 22:23
  • "The comparison is against a list of lowercased words." Which is wrong. Or cite a reference saying that the LHS is case insensitive (which it isn't). Until you find such reference, there is nothing else to debate. – Patrick Mevzek Feb 03 '20 at 22:24
  • See https://github.com/forwardemail/reserved-email-addresses-list/blob/master/index.json. This list is of lowercase words. –  Feb 03 '20 at 22:26
  • Also, "test@test.test"@example.com is a valid email address, and your split will not handle it properly. – Patrick Mevzek Feb 03 '20 at 22:27
  • This was just an basic example. I did not put in full validation or anything. I will go ahead and add validator in the example now to handle your issue. –  Feb 03 '20 at 22:28
  • "This was just an basic example." The problem is that people copy and paste code without understanding the constraints and limits. So I am pointing what is wrong, so that people know in which cases this can work or not. A good example can either explicitely states what are its limits/edge cases, or just be improved to handle really all cases. Handling email addresses, like domains, nowadays is not a simple task covered by one regular expression, things are more complicated, which is the only point I want to raise. – Patrick Mevzek Feb 03 '20 at 22:30
  • I am updating the example so that it has a full blown example that has complete edge case handling. One moment, thanks @PatrickMevzek! –  Feb 03 '20 at 22:48
  • @PatrickMevzek This code appears to implement the other answers for a local MTA. It isn't lower casing and email address and then sending and email to the all lower case version. It is lower casing the email address to check if a local email account can be created for it or not based on a list of reserved keywords. toLowerCase looks very appropriate to me in this situation, especially since RFC 822 says that the "postmaster" mailbox must be case insensitive. – Stephen Ostermiller Feb 03 '20 at 23:00
  • @StephenOstermiller "especially since RFC 822 says that the "postmaster" mailbox must be case insensitive." while not saying anything about case insensitive for other cases... My point is just that, contrary to many people belief, admin@example.com and Admin@example.com are two separate email addresses and the owner of example.com may wish, or not, to treat them separately, or not. Any code that blindly does regex matches (see first version of the post), split on @ (that can appear multiple times), does lowercasing, forgets about IDNA and EAI, is bound to have problems. That is all. – Patrick Mevzek Feb 03 '20 at 23:05
  • I could not find a single npm package nor JavaScript RegExp/Function that exists to properly parse and/or validate an email address correctly according to spec. Even the most popular ones, failed 40%+ of the tests when ran against the ones found at https://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/, such as isemail (failed 6/12 tests), @hapi/address (fork of isemail, failed 6/12 of the tests), and validator (failed 5/12 tests). @hapi/address also failed "Joe.\\Blow"@example.com per https://en.m.wikipedia.org/wiki/International_email. –  Feb 04 '20 at 08:02
  • @PatrickMevzek I have updated my answer/code snippet above - can you please review it? –  Feb 04 '20 at 08:32
  • I'm actually going to swap out the lastIndexOf usage to a more generic solution that handles all edge cases (and use email-addresses package per https://www.npmjs.com/package/email-addresses). The only bug that I found is when you're parsing multiple addresses (e.g. in the MAIL TO envelope or TO header of an email) at https://github.com/jackbearheart/email-addresses/issues/12 - and this example/code snippet is simply validating one address at a time. –  Feb 04 '20 at 08:44
  • I further looked into email-addresses and it is THE Node.js/JavaScript solution for email address parsing and validation. It seems to pass all the tests as well. –  Feb 04 '20 at 08:56
0

I have spent some time to organize the information that I found online and I have created this repository:

https://github.com/collimarco/reserved-email-addresses

Compared to other repositories I took a different approach: the list is minimal and organized by sources, so that you always know why an email address is present and you can also choose what sources to use (e.g. someone may want to consider only the RFC and not another sources).

This prevents the repository from becoming too large, messy or opinion-based.

If you find a reliable source (standard, documentation, research) that is not in the list, feel free to contribute.

Community
  • 1
collimarco
  • 101
  • 1