System.Net.MailMessage autorise certains formats d’adresse électronique non valides.

Comme de nombreuses personnes le savent peut-être déjà, la validation correcte des adresses e-mail peut être un peu un cauchemar. Vous pouvez rechercher toute la journée une expression rationnelle C # conforme aux normes RFC en vigueur, et vous obtiendrez différentes expressions regex donnant des résultats différents.

Si vous regardez http://en.wikipedia.org/wiki/Email_address#Local_part , vous verrez qu’une période au début ou à la fin de la partie locale n’est pas autorisée. Deux périodes consécutives ne sont également pas autorisées. Toutefois, le test NUnit suivant prouve que System.Net.MailMessage vous permet d’instancier un object MailMessage pour certains formats d’adresse électronique non valides.

[Test] [TestCase(@"foobar@exampleserver")] //technically valid from the wiki article [TestCase(@"jsmith@[192.168.2.1]")] //technically valid from the wiki article [TestCase(@"[email protected]")] //vanilla email address [TestCase(@"[email protected]")] //also standard [TestCase(@"[email protected]")] //long with lots of periods [TestCase(@"[email protected]")] //disposable with the + symbol [TestCase(@"[email protected]")] //period and dash in local part [TestCase(@"[email protected]")] //lots of hyphens [TestCase(@"!#$%&'*+-/=?^_`{|}[email protected]")] //all these symbols are allowed in local part [TestCase(@"ër_%لdev@gكňil.com")] //characters outside the ascii range are permitted [TestCase(@"""abcdefghixyz""@example.com")] //technically valid //[TestCase(@"abc.""defghi""[email protected]")] //technically valid, but .NET throws exception public void CanCreateMailMessageObjectTest(ssortingng emailAddress) { var mailMessage = new System.Net.Mail.MailMessage("[email protected]", emailAddress); } 

Tous les cas de test ci-dessus réussissent sauf le dernier.

 [Test] [TestCase(@"[email protected]")] //leading period [TestCase(@"[email protected]")] //period at end of local part <---FAIL [TestCase(@"[email protected]")] //double period in local part <---FAIL [TestCase(@"foobar@example!#$%^&*()=server.com")] //special characters in domain part [TestCase(@"Abc.example.com")] //No @ separating local and domain part [TestCase(@"A@b@[email protected]")] //more than one @ symbol [TestCase(@"just""not""[email protected]")] //quoted strings must be dot separated [TestCase(@"a""b(c)d,e:f;gi[j\k][email protected]")] //special symbols "(),:;@[\] not inside quotes [TestCase(@"[[email protected]")] //leading special symbol in local part [TestCase(@"this is""not\[email protected]")] //spaces not in quotes [TestCase(@"this\ still\""not\\[email protected]")] //backslashes not in quotes [ExpectedException(typeof (System.FormatException))] public void CannotCreateMailMessageObjectTest(string emailAddress) { var mailMessage = new System.Net.Mail.MailMessage("[email protected]", emailAddress); } 

Pourquoi [email protected] [email protected] et [email protected] ne parviennent-ils pas à générer une exception System.FormatException? Qui a tort ici, Microsoft ou Wikipedia? Existe-t-il des adresses électroniques bénéficiant d’une clause de droits acquis pour permettre une période de suivi ou une double période? Ma validation doit-elle les permettre? J’ai la gestion des exceptions appropriée en place pour permettre à mon service de livraison par courrier électronique de continuer à fonctionner le même jour si une exception se produit, mais j’aimerais supprimer les adresses électroniques qui sont soit non valides, soit garanties de générer une exception.

Il n’y a aucune explication à cela, mais la documentation de MSDN sur System.Net.Mail.MailAddress que ce format d’adresse est pris en charge:

La classe MailAddress prend en charge les formats d’adresse de messagerie suivants:

  • Points consécutifs et finaux dans les noms d’utilisateur. Par exemple, utilisateur … nom .. @ hôte.

Donc, ce n’est pas un bogue dans la classe MailAddress – ce formulaire est explicitement supporté. Mais je ne sais pas pourquoi on les soutient. Je suppose que certains systèmes les acceptent peut-être et MS ressent le besoin de prendre en charge ce scénario.

D’autre part, bien que je comprenne la nécessité de fournir une validation des adresses électroniques, mon opinion personnelle est qu’il n’y a pas besoin d’être super ssortingct dans la validation. Le système doit quand même gérer les adresses mauvaises, mais syntaxiquement valables. D’un autre côté, il semble qu’une période doublée ou une période à la fin de la partie locale puisse être une faute de frappe courante. Je peux donc comprendre pourquoi vous pourriez vouloir que leur validation échoue.

Étant donné que les RFC définissent la norme, l’implémentation de Microsoft serait incorrecte.

Si vous voulez faire une meilleure validation, essayez le validateur que j’ai posté dans cette réponse à la question C # Email Address validation .

Il devrait correctement (et ssortingctement) valider à peu près toutes les adresses e-mail “normales” du format local-part @ domain que vous pourriez rencontrer, bien que cela ne traite pas les nouveaux éléments de style non-ASCII autorisés. Je ne garantis pas qu’un peu de pourriture ne se soit pas installée depuis quelques années et que les RFC sur les courriels ont été mis à jour depuis que je les ai écrites.

La partie locale ne doit pas être citée: elle ne prend pas en charge les parties locales ou les libellés cités.

En ce qui concerne la partie domaine, mon validateur ne prend pas en charge les littéraux IPv4 ou IPv6 (bien qu’il ne soit pas difficile de l’append).

Si vous souhaitez autoriser toutes les adresses conformes à la RFC, cela devient beaucoup plus difficile.