2012-03-30 10 views
8

RFC 5321, 5322 e 6531 hanno regole complesse per la convalida degli indirizzi di posta elettronica. Essi:Storicamente, perché le RFC sugli indirizzi e-mail sono state così complicate?

  • permettono creating comments all'interno di un indirizzo di posta elettronica
  • offrono complicate regole di restrizione per i simboli: "() ,:;<>@[\]
  • trattare postmaster localpart come case-insensitive, ma tutti gli altri come
  • permettono groups of email addresses
maiuscole e minuscole

Grazie a queste complicate regole, testare se una determinata stringa è un indirizzo email sintatticamente valido secondo e RFC can't be performed utilizzando solo espressioni regolari.

Apparentemente, molte di queste regole non sono supportate dai principali provider di posta elettronica.

Storicamente parlando, quali erano le motivazioni per la creazione di regole così complesse per gli indirizzi e-mail? Lo Wikipedia article on the origins of email sembrerebbe implicare che lo standard moderno dei primi anni '80 intendeva riguardare tutti i sistemi di posta elettronica preesistenti con i loro standard e sintassi particolari.

Tuttavia, gli implementatori di standard, provider di posta elettronica e utenti finali di e-mail hanno tutti interesse per un sistema di lavoro, che è più facile da ottenere quando le regole non sono troppo arcane e possono essere facilmente inserite in un software che supera un numero di test, quindi perché oggi abbiamo uno standard così complicato che nessuno lo utilizza fino in fondo?

Ancora una volta, in termini storici, l'XML è stato in gran parte sostituito da JSON, il cui successo può essere parzialmente attribuito alla semplicità della sua grammatica.

+0

Perché le RFC devono coprire tutti i casi limite, non solo i "principali fornitori"? – ceejayoz

+3

credo che questa sia una domanda ragionevole e valida che dovrebbe essere discussa meglio con un giudizio storico a posteriori. le RFC sopra menzionate non sono le uniche colpevoli; anche le RFC che regolano i modi validi per trascrivere gli indirizzi IP sono contorte. È interessante notare che, nel mondo reale, vengono utilizzate attivamente solo piccole parti di questi RFC, praticamente tutti gli indirizzi e-mail assomigliano a 'name @ exxample.com' e tutti gli indirizzi IP come' 123.234.231.132'. se questa domanda non fosse stata chiusa prematuramente, ora potremmo godere di una vivace discussione sui meriti, i demeriti e gli sfondi storici di queste RFC estremamente complesse. – flow

+0

Anche se questa è una domanda interessante e valida (nella più ampia comunità di software), non è adatta a StackOverflow. – JasonMArcher

risposta

1

L'unico modo sicuro per vedere se un indirizzo di posta elettronica fornito è autentico è quello di inviare una e-mail ad esso e vedere se l'utente lo riceve. L'utile controllo che può essere eseguito su un indirizzo è quello di verificare che l'indirizzo email sia sintatticamente valido. Questo è ciò che fa questo modulo.

I sistemi che inviano posta devono essere in grado di gestire la posta in uscita per tutti gli indirizzi validi. Contrariamente agli standard pertinenti, alcuni sistemi difettosi trattano alcuni indirizzi legittimi come non validi e non riescono a gestire la posta a questi indirizzi. ! Hotmail, ad esempio, si rifiuta di inviare una mail a qualsiasi indirizzo contenente uno dei caratteri seguenti standard ammissibili: # $% */^ `{|} ~

solo diversi livelli di standard, in cui alcuni sono? molto severo, quindi complesso.

+0

mentre la risposta è tecnicamente corretta, non risponde alla domanda (che riguarda la sintassi degli indirizzi e-mail). sapere che un indirizzo stradale è o non è sintatticamente corretto è una cosa, sapere se c'è un edificio in quel punto o no è qualcos'altro. – flow