EmailCanonicalization Class
The one email transformation RFC 9493 settles, offered for comparing addresses rather than for storing them.
public static class EmailCanonicalizationInheritance System.Object → EmailCanonicalization
Remarks
RFC 9493 Section 3.2.2.1 records the situation plainly: providers differ over whether the local part is case-sensitive and whether dots in it are significant, email canonicalisation is not standardised, and a receiver has no way to learn the sending provider's algorithm. It therefore puts the choice on the receiver, which is why nothing here runs automatically.
What the specification does settle is the domain: it is case-insensitive per RFC 1034, always, for every provider. ToComparableForm(string) folds that and nothing else, so applying it can never merge two addresses that are genuinely distinct. Anything beyond it - folding the local part, dropping dots, stripping a "+" qualifier - is a guess about one provider's rules and belongs in the application that knows which provider it is talking to.
Methods
EmailCanonicalization.ToComparableForm(string) Method
Returns the address with its domain lowercased, leaving the local part untouched.
public static string ToComparableForm(string email);Parameters
email System.String
The address to fold. May be any string; nothing is validated here.
Returns
System.String
The address with the part after the last "@" lowercased using the invariant culture. When
the value holds no "@", it is returned unchanged - deciding what a domain-less string means
is the caller's business, not this method's.
Remarks
The split is on the LAST "@" because RFC 5322 permits a quoted local part to contain one,
as in "odd@name"@example.com; splitting on the first would lowercase part of the
local part and change the address.