2009-02-09 8 views
7

Estoy trabajando en una aplicación que usa System.Net.Mail.MailAddress y amigos para enviar correos electrónicos. ¿Ese analizador implementa el RFC5322 completo o un subconjunto o qué? MSDN no es muy comunicativo sobre este tema.¿Cuál es el formato aceptado por el analizador System.Net.Mail.MailAddress?

Cualquier sugerencia apreciada.

+0

Obtenga e instale Reflector de RedGate, luego navegue hasta el espacio de nombres System.Net.Mail y mire el código para ver qué hace. Haría esto pero estoy en casa en mi Mac ahora mismo. – tvanfosson

+3

Tal vez soy extraño, pero prefiero ver un documento (preferiblemente por MS o ECMA) que indique que la maldita cosa "acepta direcciones RFCsuch-such, excepto las secciones X, Y y Z porque el IETF no sabe sh * t sobre internet "que tener que desmontar la cosa. –

+0

De acuerdo, pero ausente esa documentación, y tal vez incluso con ella, mirando el código respondería la pregunta definitivamente. – tvanfosson

Respuesta

4

he escrito un pequeño fragmento para probar la función:

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); 
    } 
} 

con los siguientes resultados en 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] 

Además, no parecen apoyar "cita de cadena "piezas locales, como "blah"@example.com.

No creo que un validador pueda aceptar menos antes de quedar inutilizable.

3

En el hilo de discusión en Dominic Sayers isemail article, Jerry O'Brien dijo que había leído casos de prueba RFC cumplimiento de Dominic contra la clase System.Net.MailAddress:

System.Net.MailAddress es sólo el 59% cumple con las especificaciones RFC. Los comentarios de seguimiento señalaron los casos específicos en los que se generaron falsos negativos positivos y falsos negativos.

Los RFC son extremadamente débiles en lo que constituye una dirección válida de correo electrónico. Permiten una gama de formatos inusuales e impopulares. Así que supongo que la verdadera pregunta es, ¿es System.Net.MailAddress lo suficientemente bueno en la mayoría de las situaciones del mundo real?

+1

¡Gracias por este interesante enlace! Además, una buena pregunta acerca de que el analizador es "lo suficientemente bueno". La implementación específica que probé fue lo suficientemente buena para la aplicación que hice. Como traté de explicar en los comentarios a la pregunta, el problema más amplio para mí es que esto, como muchos otros lugares en el BCL, es lamentablemente una documentación inadecuada; creando dependencias innecesarias en los detalles de implementación (ver el comentario del reflector). –

+0

Estoy totalmente de acuerdo contigo. En los lugares donde existen estándares (como formatos de fecha, URI, direcciones de correo electrónico, etc.) sería bueno saber cuáles son las especificaciones de diseño para la clase, ¡y también las pruebas unitarias publicadas! – dthrasher

+0

Uso este método, pero prueba @ prueba pasa la validación. Gorrón. – Scott

Cuestiones relacionadas