input_validation/email

13 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Email address RFC 5321 format complexity

The format of email addresses is defined by RFC 5321 and is far more complicated than most people realise. Valid email addresses include: ">\<script\>alert(1);\</script\>"@example.org, user+subaddress@example.org, user@[IPv6:2001:db8::1], and " "@example.org.

Email address regex complexity and real-world limitations

Although RFC 5321 defines a very flexible format for email addresses, most real world implementations such as mail servers use a far more restricted address format, meaning they will reject addresses that are technically valid. Although technically correct, these addresses are of little use if the application will not be able to actually send emails to them.

Email validation via mail server testing

The best way to validate email addresses is to perform some basic initial validation, then pass the address to the mail server and catch the exception if it rejects it. This means the application can be confident that its mail server can send emails to any addresses it accepts.

Email initial syntactic validation checks

Initial email validation should include: the email address contains two parts separated with an @ symbol; the email address does not contain dangerous characters such as backticks, single or double quotes, or null bytes (exactly which characters are dangerous depends on how the address will be used); the domain part contains only letters, numbers, hyphens (-) and periods (.); the local part (before the @) is no more than 63 characters; the total length is no more than 254 characters.

Email ownership verification with token

Semantic validation for email addresses is performed by sending an email to the user and requiring they click a link or enter a code. This provides assurance that the email address is correct, the application can successfully send emails to it, and the user has access to the mailbox. The verification token should be: at least 32 characters long; generated using a secure source of randomness; single use; time limited such as expiring after eight hours.

Post-verification authentication requirement

After validating the ownership of the email address, the user should then be required to authenticate on the application through the usual mechanism.

Disposable email addresses blocking is impractical

Blocking disposable email addresses is almost impossible as there are a large number of websites offering these services, with new domains being created every day. Although publicly available lists and commercial lists of known disposable domains exist, these will always be incomplete.

Disposable email blocking user messaging

If lists are used to block disposable email addresses, the user should be presented with a message explaining why they are blocked, although they are likely to simply search for another disposable provider rather than giving their legitimate address.

Disposable email prevention via allowlist

If it is essential that disposable email addresses are blocked, registrations should only be allowed from specifically-allowed email providers. However, if this includes public providers such as Google or Yahoo, users can simply register their own disposable address with them.

Email sub-addressing definition

Sub-addressing allows a user to specify a tag in the local part of the email address (before the @ sign), which will be ignored by the mail server. For example, if example.org domain supports sub-addressing, the following email addresses are equivalent: user@example.org, user+site1@example.org, user+site2@example.org.

Email sub-addressing provider support

Many mail providers (such as Microsoft Exchange) do not support sub-addressing. The most notable provider who does is Gmail, although many others also do.

Email sub-addressing for spam tracking

Some users will use a different tag for each website they register on, so that if they start receiving spam to one of the sub-addresses they can identify which website leaked or sold their email address.

Sub-addressing blocking not recommended

Some sites may wish to block sub-addressing by stripping out everything between the + and @ signs to prevent users from registering multiple accounts with a single email address. This is not generally recommended as it suggests the website owner is either unaware of sub-addressing or wishes to prevent users from identifying them when they leak or sell email addresses. Additionally, it can be trivially bypassed by using disposable email addresses or simply registering multiple email accounts.

Give your agent this brain