2009-02-09 5 views
7

Ich arbeite an einer App, die System.Net.Mail.MailAddress und Freunde zum Senden von E-Mails verwendet. Implementiert dieser Parser die vollständige RFC5322 oder eine Teilmenge oder was? Das MSDN ist zu diesem Thema nicht sehr präsent.Welches Format akzeptiert der Parser von System.Net.Mail.MailAddress?

Alle Hinweise geschätzt.

+0

Holen Sie sich RedGate's Reflector und installieren Sie es, navigieren Sie dann zum Namespace System.Net.Mail und sehen Sie sich den Code an, um zu sehen, was er tut. Ich würde das machen, aber ich bin jetzt zu Hause auf meinem Mac. – tvanfosson

+3

Vielleicht bin ich seltsam, aber ich würde lieber ein Dokument (vorzugsweise von MS oder ECMA) sehen, das besagt, dass das verdammte Ding "akzeptiert RFCs-und-wie Adressen mit Ausnahme der Abschnitte X, Y und Z, weil die IETF nicht weiß Sh * t über das Internet "als das Ding zerlegen zu müssen. –

+0

Einverstanden, aber ohne solche Dokumentation - und vielleicht sogar damit - würde der Code die Frage definitiv beantworten. – tvanfosson

Antwort

4

Ich habe einen kleinen Schnipsel schrieb die Funktion zu testen:

foreach (int i in Enumerable.Range(32,128-32)) 
{ 
    char c = (char)i; 
    string addr = String.Format("par.t1{0}pa.r{0}[email protected]", c); 
    try 
    { 
     var mailAddr = new MailAddress(addr); 
    } 
    catch 
    { 
     Console.WriteLine("MailAddress failed '{0}' ({1}): {2}", c, i, addr); 
    } 
} 

mit den folgenden Ergebnissen auf 3.5 SP1:

 
MailAddress failed ' ' (32): par.t1 pa.r [email protected] 
MailAddress failed '"' (34): par.t1"pa.r"[email protected] 
MailAddress failed '(' (40): par.t1(pa.r([email protected] 
MailAddress failed ')' (41): par.t1)pa.r)[email protected] 
MailAddress failed ',' (44): par.t1,pa.r,[email protected] 
MailAddress failed ':' (58): par.t1:pa.r:[email protected] 
MailAddress failed ';' (59): par.t1;pa.r;[email protected] 
MailAddress failed '<' (60): par.t1<pa.r<[email protected] 
MailAddress failed '>' (62): par.t1>pa.r>[email protected] 
MailAddress failed '@' (64): [email protected]@[email protected] 
MailAddress failed '[' (91): par.t1[pa.r[[email protected] 
MailAddress failed '\' (92): par.t1\pa.r\[email protected] 
MailAddress failed ']' (93): par.t1]pa.r][email protected] 
MailAddress failed '⌂' (127): par.t1⌂pa.r⌂[email protected] 

Auch ist es nicht zu unterstützen „scheint quoted-string "Local-Teile, wie "blah"@example.com.

Ich glaube nicht, dass ein Validator weniger akzeptieren könnte, bevor er unbrauchbar wird.

3

In der Diskussion über Dominic Sayers isemail article, sagte Jerry O'Brien, dass er Dominics RFC Compliance Testfälle gegen die System.Net.MailAddress Klasse lesen:

System.Net.MailAddress ist nur 59% entspricht den RFC-Spezifikationen. Follow-up-Kommentare notierten die spezifischen Fälle, wo es falsche positive und falsche negative erzeugt.

Die RFCs sind extrem schwach in Bezug auf eine gültige E-Mail-Adresse. Sie erlauben eine Reihe von ungewöhnlichen und unpopulären Formaten. Also ich denke die wirkliche Frage ist, ist System.Net.MailAddress gut genug in einer Mehrheit von realen Situationen?

+1

Danke für diesen interessanten Link! Auch eine gute Frage, ob der Parser "gut genug" ist. Die spezifische Implementierung, die ich getestet habe, war gut genug für die Anwendung, die ich gemacht habe. Wie ich versucht habe, in den Kommentaren zu der Frage zu erklären, ist das umfassendere Problem für mich, dass dies, wie viele andere Orte in der BCL, schrecklich unzureichende Dokumentation ist; Erstellen unnötiger Abhängigkeiten von Implementierungsdetails (siehe Reflektorkommentar). –

+0

Ich stimme Ihnen vollkommen zu. An Orten, an denen Standards existieren (Dinge wie Datumsformate, URIs, E-Mail-Adressen usw.), wäre es schön zu wissen, was die Designspezifikation für die Klasse ist - und auch veröffentlichte Unit-Tests! – dthrasher

+0

Ich benutze diese Methode, aber Test @ Test besteht Validierung. Bummel. – Scott