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.