로컬 부분 끝에 대시가있는 전자 메일 ID

전자 메일의 로컬 부분 끝에 대시 (-)가 있으면 유효한 전자 메일입니까? 예를 들어,

an.unusual.email-@mydomain.com

또는 일반화하기 위해 이러한 문자 ( Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126) ), 전자 메일 ID의 처음과 / 또는 끝에 전자 메일의 로컬 부분에 올 수 있습니까?

Google은 그것이 무효라고 말합니다. 당분간은 RFC는 무효로 간주합니다. 단, RFC는 [점] 문자 만 시작 및 / 또는 끝 부분에서 로컬 부분을 제외합니다.

참고 : 도메인 부분에 대해서는 신경 쓰지 않습니다. DNS가 질의 응답을 복잡하게 만드는 방식 때문에 더 복잡해지기 때문입니다.

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

— Jimson Kannanthara James
소스

좋은 질문. 봤어? 이 스택 오버플로 질문 및 답변 스레드 ? 많은 정보 -이 시점에서 구식 정보가 많습니다. - 그러나 여전히 좋은 출발점 /

— JakeGould

좋은 참조 링크, 구글은 그 이메일을 무효로 취급하는 것처럼 보이지만 Microsoft는 문제가 없습니다.

— Jimson Kannanthara James

Google에서 광고를 시작한 이후 공유 : Gmail은 이메일 주소의 모든 기간을 무시하므로 이메일이 'anunusualemail@gmail.com'인 경우 'an.unusual.email@gmail.com'으로 전송 된 메일도 받게됩니다. 또한 전자 메일 주소 끝의 "anunusualemail+something@gmail.com"의 내용을 무시합니다.

— mowwwalker

내 메일 서비스에서 사용자 이름에서 "u"문자를 금지 할 수 있습니다. 으니까.

— Agent_L

답변:

전자 메일의 로컬 부분 끝에 대시 (-)가 있으면 유효한 전자 메일입니까? [...] Google은 그것이 무효라고 말합니다. 당분간은 RFC는 무효로 간주합니다. 단, [dot] 문자는 시작 및 / 또는 로컬 부분 만 제외합니다.

그것은 유효합니다. Google은 완전히 다른 수표를 수행하기 때문에 Google이 거부 한 것을 볼뿐입니다. 지방 부분 다른 많은 공급자와 마찬가지로 될 수 있습니다.

Google 또는 다른 누구도 양식이 실제로있는 경우에만 가능한 모든 유효한 이메일 주소를 수락 할 의무가 있습니다 ~를 요구하는 기존의 유효한 전자 메일 주소 (공급자가 제공 한 것일 수도 있음). 예를 들어 Gmail의 받는 사람 : / Cc : 필드가 유효한 주소를 거부했습니다.

그러나 강조 표시된 필드는 기존 이메일 주소를 묻지 않습니다. 그것은 Google 시스템의 계정 이름 계정이 만들어지면 이메일 주소의 기초가됩니다. Google이나 다른 사람이 유효한 계정 이름 (또는 실제로는 사서함 이름)을 제한하는 것을 금지하는 것은 없습니다. 그들 자신의 시스템에 .

즉, 'local-part'에 허용되는 문자를 정의한다는 것은 메일 응용 프로그램 SMTP 서버가 RFC 822 헤더 및 SMTP 명령에서 이러한 주소를 받아 들여야 함을 의미합니다. 몹시 떠들어 대다 그러한 사서함. (실제로 초기 전자 메일 RFC가 작성되고 대부분의 사서함이 여전히 OS 수준 계정과 연결되어 있었을 때 이름은 비슷하거나 더 엄격했습니다.)

예를 들어 RFC 5321의이 부분 (섹션 4.1.2, ABNF 아래)은 수신 호스트가 실제로 할까요 자체 사서함의 이름 지정 방법에 훨씬 더 엄격한 제한이 있습니다.

로컬 부분에 대한 위의 정의가 상대적으로 허용되지만, 최대 상호 운용성을 위해 메일을 수신 할 호스트 로컬 부분에 필요한 메일 함을 정의하지 않아야합니다 (또는 quoted-string 형식을 사용하거나 Local-part가 대소 문자를 구분하는 경우).

그래서, 비록 anunusualemail-@gmail.com ~이다. 구문 론적으로 유효하다. 그렇다고해서 Google이 귀하의 정보를 작성할 수 있도록 허용해야한다는 의미는 아닙니다.

— grawity
소스

흥미로운 측면 노트로서, 구글은 이메일 주소의 마침표를 무시합니다 ( gmail.googleblog.com/2008/03/... ) 또한 RFC에 지정되지 않았습니다. 따라서 myname@gmail.com은 my.name@gmail.com 또는 m.y.n.a.m.e@gmail.com과 같은 위치로 이동합니다.

— childofsoong

@JimsonKannantharaJames 일반적으로 전자 메일이 유효한지 확인하려면 실제로 해당 주소로 전자 메일을 보내 사용자가 강제로 조치를 취해야합니다. 주소의 구문을 기반으로하는 모든 검사는 오타를 만드는 사용자를 잡아야합니다.

— Michael Mior

@grawity 오, 저도 알고 있습니다. 저는 RFC에 명시되지 않았지만 허락 된 또 다른 것을 보여주기 위해 논평했습니다.

— childofsoong

@ user71659 필요한 경우 제어 문자를 제대로 이스케이프 처리하지 않으면 더 큰 문제가 발생합니다. 궁극적으로 전자 메일은 사용자가 입력했으며 사용자 입력은 항상 위험한 것으로 간주되어야합니다. 일부 유효성 검사 규칙 때문에 데이터베이스의 일부 필드가 안전하다고 가정하면 상당히 위험 할 수 있습니다. 몇 달 후 다른 사람이 동일한 유효성 검사가없는 다른 양식에서 해당 필드를 채우면 어떻게됩니까?

— Michael Mior

@ user71659 당신은 두 가지 다른 문제를 논쟁하고 논쟁을 muddying 있습니다. MichaelMior는 다음과 같이 말하기에 완벽합니다. 확인 그 이메일 주소 존재하다 , 너 의지 해당 주소로 전자 메일을 보내 사용자 조치가 필요합니다.

— kumar_harsh

G Suite (공식적으로 Google 도메인 용 애플리케이션)는 전자 메일 주소에서 마지막 문자 인 하이픈 (대시)을 허용합니다.

사용자 이름은 문자 (a-z), 숫자 (0-9), 대시 (-), 밑줄 (_), 아포스트로피 ( ') 및 마침표 (.)를 포함 할 수 있습니다.

출처: 이름 및 비밀번호 가이드 라인

언급 한 바와 같이 Gmail은 이메일 주소에 하이픈을 허용하지 않습니다.

— davidmneedham
소스