ID e-mail con trattino alla fine della parte locale


19

È un'e-mail valida se l'e-mail ha un trattino (-) alla fine della parte locale di un'e-mail? Per esempio,

an.unusual.email-@mydomain.com

O per generalizzare, uno qualsiasi di questi caratteri ( Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)), che sono validi per essere nella parte locale dell'email all'inizio e / o alla fine dell'ID email?

Google afferma che non è valido, quindi per il momento lo presumo anche come non valido, sebbene RFC escluda solo il carattere [punto] dall'inizio e / o della fine della parte locale.

Errore GMail per il caso precedente

Nota: non sono preoccupato per la parte del dominio, perché diventa più coinvolta a causa del modo DNS, che complica la domanda e le risposte.

https://social.technet.microsoft.com/Forums/ie/en-US/69f393aa-d555-4f8f-bb16-c636a129fc25/what-are-valid-and-invalid-email-address-characters


Buona domanda. Hai guardato questa domanda Stack Overflow e thread di risposta ? Un sacco di info-gran parte fuori della data a questo punto, ma ancora buon punto di partenza /
JakeGould

buon collegamento di riferimento, sembra che Google tratti quell'e-mail come non valida, mentre Microsoft non ha alcun problema.
Jimson Kannanthara James,

1
Condividendolo da quando hai visualizzato Google: Gmail ignora tutti i punti in un indirizzo e-mail, quindi se la tua e-mail fosse "anunusualemail@gmail.com", riceveresti anche la posta inviata a "an.unusual.email@gmail.com". Ignora anche i vantaggi alla fine dell'indirizzo e-mail: "anunusualemail+something@gmail.com".
mowwwalker,

1
Sul mio servizio di posta posso vietare la lettera "u" dai nomi utente. Solo perché.
Agent_L

Risposte:


60

È un'e-mail valida se l'e-mail ha un trattino (-) alla fine della parte locale di un'e-mail? [...] Google afferma che non è valido, quindi per il momento lo presumo anche come non valido, sebbene RFC escluda solo il carattere [punto] dall'inizio e / o dalla fine della parte locale.

È valido Lo stai vedendo rifiutato da Google solo perché esegue un controllo completamente diverso: hanno le loro politiche su ciò che può essere la parte locale , così come molti altri fornitori.


Google, o chiunque altro, sarebbe obbligato ad accettare tutti gli indirizzi e-mail eventualmente validi solo se il modulo richiedesse effettivamente un indirizzo e-mail valido e esistente (possibilmente dal provider). Ad esempio, sarebbe un errore se il campo A: / Cc: di Gmail rifiutasse un indirizzo valido.

Ma il campo che hai evidenziato non ti chiede un indirizzo email esistente; richiede un nome account sui sistemi Google, che sarà la base per un indirizzo email solo dopo la creazione dell'account. Non c'è nulla che possa impedire a Google o a chiunque altro di limitare l'insieme di nomi di account validi (o, in realtà, anche i nomi di cassette postali) sul proprio sistema .

Oppure, in altre parole, definire i caratteri consentiti per "parte locale" significa solo che i server SMTP delle applicazioni di posta devono accettare tali indirizzi nelle intestazioni RFC 822 e nei comandi SMTP, ma non dice nulla sulla possibilità di creare tali cassette postali. (In effetti, quando i primi RFC e-mail venivano scritti e la maggior parte delle cassette postali erano ancora legate ad account a livello di sistema operativo, i loro nomi avevano limiti simili o persino più severi.)

Ad esempio, questa parte di RFC 5321 (sezione 4.1.2, sotto ABNF) afferma esplicitamente che un host ricevente è autorizzato e in effetti dovrebbe avere limiti molto più severi su come vengono denominate le proprie caselle postali:

Mentre la definizione sopra per Local-part è relativamente permissiva, per la massima interoperabilità, un host che si aspetta di ricevere posta DOVREBBE evitare di definire le caselle di posta in cui il Local-part richiede (o utilizza) il modulo di stringa tra virgolette o dove il Local-part è il caso -sensibile.

Quindi, sebbene anunusualemail-@gmail.com sia sintatticamente valido, questo da solo non significa che Google debba permetterti di crearlo.


6
Come nota a margine interessante, google ignora i periodi negli indirizzi e-mail ( gmail.googleblog.com/2008/03/… ), che inoltre non è specificato nella RFC. Quindi, myname@gmail.com va nello stesso posto di my.name@gmail.com o myname@gmail.com.
figlio del

4
@JimsonKannantharaJames In generale, se si desidera verificare se un'e-mail è valida, è necessario inviare un'e-mail a tale indirizzo e forzare l'utente ad agire. Qualsiasi controllo basato solo sulla sintassi dell'indirizzo dovrebbe davvero essere quello di catturare l'utente facendo errori di battitura.
Michael Mior,

1
@grawity Oh lo so - stavo commentando per dare un esempio di un'altra cosa che non è stata specificata nella RFC ma è consentita.
bambino del

1
@ user71659 Se non riesci a sfuggire correttamente ai caratteri di controllo dove necessario, hai un problema più grande. Alla fine l'email è stata inserita dall'utente e l'input dell'utente deve essere sempre considerato pericoloso. Supporre che un campo nel database sia sicuro a causa di alcune regole di convalida può essere piuttosto pericoloso. Cosa succede quando qualche mese dopo qualcun altro popola quel campo da un'altra forma che non ha la stessa validazione?
Michael Mior,

2
@ user71659 stai fondendo due problemi diversi e confondendo l'argomento. MichaelMior è perfettamente corretto affermare che a verificare che un indirizzo di posta elettronica esiste , si sarà necessario inviare una e-mail a questo indirizzo, che richiede l'intervento dell'utente.
Kumarharsh,

7

G Suite (formalmente Google Apps per il tuo dominio) consente trattini (trattini) all'interno degli indirizzi email, anche come ultimo carattere.

I nomi utente possono contenere lettere (az), numeri (0-9), trattini (-), trattini bassi (_), apostrofi (') e punti (.).

Fonte: linee guida per nome e password

Come hai notato, Gmail non consente trattini negli indirizzi e-mail.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.