나는 전자 우편의 표준 첫 번째 부분에서 나는 전자 메일을 보내려고했습니다하지만, 대소 문자를 구분 읽었습니다 name@example.com, Name@example.com그리고 NAME@example.com- 그것은 각각의 경우에 도착했습니다.
메일 서버는 사용자 이름을 어떻게 처리합니까? 사례를 놓칠 수 있으며 해당 메시지가 전달되지 않습니까? 이메일 주소를 제공 할 때 등록 할 때 기록 된 것과 정확히 동일한 소문자를 사용하는 것이 정말로 중요합니까?
답변:
에서 RFC 5321, 섹션 2.3.11 :
표준 사서함 이름 지정 규칙은 "local-part @ domain"으로 정의됩니다. 현대적인 사용법은 단순한 "사용자 이름"보다 훨씬 광범위한 응용 프로그램을 허용합니다. 결과적으로 중간 호스트가 전송을 수정하여 최적화를 시도했을 때 오랜 문제가 발생했기 때문에 로컬 부분은 반드시 주소의 도메인 부분에 지정된 호스트에 의해서만 의미를 해석하고 할당해야합니다.
따라서 "@"앞 부분은 모두 호스트 시스템의 통제하에 있기 때문에 대소 문자를 구분할 수 있습니다. 그러나 실제로 널리 사용되는 메일 시스템은 대소 문자에 따라 다른 주소를 구별하지 않습니다.
그러나 @ 기호 다음 부분은 도메인이며 RFC 1035 , 섹션 3.1,
"이름 서버와 확인자는 대소 문자를 구분하지 않고 [도메인]을 비교해야합니다"
요컨대, 이메일 주소는 대소 문자를 구분하지 않는 것이 안전합니다.
나는 이것이 오래된 질문이라는 것을 알고 있지만 여기에 의견을 남기고 싶습니다 : 이메일 주소는 대소 문자를 구분합니다. 대부분의 사용자는 대문자가 필요한 이메일 주소를 적극적으로 사용하는 것이 "현명하지 못합니다". 메일이 많이 없어서 주소 사용을 곧 중단 할 것입니다. (물건을 어렵게 만드는 특별한 이유가없는 한, 자신이 알고있는 특정 발신자의 메일 만 기대합니다.)
불완전한 사람뿐만 아니라 불완전한 소프트웨어가 존재하기 때문에 (Surprise!) 모든 이메일이 소문자로 간주되므로 이러한 사람과 소프트웨어는 제공된 방법에 관계없이 주소의 "소문자가 낮은 버전"을 사용하여 메시지를 보냅니다. 그들에게. 수신자가 그러한 메시지를 수신 할 수없는 경우, 메시지가 많이 누락되었음을 알리고 소문자 전용 전자 메일 주소로 전환하거나 서버가 대소 문자를 구분하지 않도록 설정하는 데 오래 걸리지 않습니다.
이 게시물에 늦었지만, 조금 다른 말이 있습니다 ...
>> "Are email addresses case sensitive?"
글쎄, "그것은 달려있다 ..." (TM)
실제로 일부 조직에서는 이것이 좋은 생각이라고 생각하며 전자 메일 서버는 대 / 소문자를 구분합니다.
따라서 그 미친 장소의 경우 "예, 이메일은 대소 문자를 구분합니다."
참고 : 사양에 따르면 무언가를 할 수 있다고해서 그렇게하는 것이 좋은 것은 아닙니다.
KISS의 원칙은 제안 우리의 시스템은 대소 문자를 구분 이메일을 사용합니다.
견고성 원칙에 따라 대소 문자를 구분하는 이메일을 수락하는 것이 좋습니다.
해결책:
이는이 이메일이 이미 존재하는 경우 user@x.com을 의미합니다.
... 다른 사용자가 와서이 이메일을 사용하려고합니다 : USER@x.com
... 대소 문자를 구분하지 않는 검색 로직이 "이메일이 이미 존재합니다"오류 메시지를 반환합니다.
이제 결정을 내 렸습니다 : 귀하의 경우에 그 솔루션이 적절합니까?
그렇지 않은 경우 대소 문자 구분 이메일 지원이 필요한 클라이언트에게 편의 수수료를 청구하고 user@x.com이 이미 존재하더라도 USER@x.com을 시스템에 허용하는 사용자 정의 논리를 구현할 수 있습니다.
이 경우 이메일 검색 / 검증 로직은 다음 의사 코드와 유사 할 수 있습니다.
if (user.paidEmailFee) {
// case sensitive email
query = "select * from users where email LIKE ' + user.email + '"
} else {
// case insensitive email
query = "select * from users where email ILIKE ' + user.email + '"
}
이런 방식으로, 대부분 대소 문자를 구분하지 않지만 고객이 이러한 무의미한 이메일 시스템을 사용하는 경우이 지원에 대한 비용을 지불 할 수 있습니다.
ps ILIKE는 PostgreSQL 키워드입니다 : http://www.postgresql.org/docs/9.2/static/functions-matching.html
%하거나 더 가능성이 있는 이메일을 상상해보십시오_
query = ...줄로 대체하여 해결할 수 있습니다. query = // Insert case-sensitive/insensitive search hereSQL 주입 주제에서 대화를 멀리하고 표시하려는 내용에 중점을 둔 간단한 의견. 즉, 구현이 아닌 논리에 유지하십시오. 비평가들을 침묵시킬 것이다.
IETF 공개 표준 RFC 5321 2.4. 일반적인 구문 원칙 및 트랜잭션 모델
SMTP 구현은 사서함 로컬 부분의 경우를 보존해야합니다. 특히 일부 호스트의 경우 사용자 "smith"는 사용자 "Smith"와 다릅니다.
사서함 도메인은 일반적인 DNS 규칙을 따르므로 대소 문자를 구분하지 않습니다.
@ l3x에 따라 다릅니다.
정답이 다를 수있는 일반적인 상황에는 분명히 두 가지가 있으며, 세 번째는 일반적인 경우와 다릅니다.
a) 귀하는 개인 메일을 보내는 사용자입니다 .
당신은 그래서 거의 현대의 이메일 시스템은 대소 문자 구분을 구현하는 아마 케이스를 무시하고 사용 기분이 어떤 경우 선택 잘. 모든 메일이 배달된다는 보장은 없습니다. 그러나 메일에 부정적인 영향을 미쳐 걱정할 필요 가없는 메일은 거의 없습니다 .
b) 메일 소프트웨어를 개발 중입니다 .
하단의 RFC5321 2.4 발췌 부분을 참조하십시오.
메일 소프트웨어를 개발할 때 RFC를 준수 하려고 합니다. 원하는 경우 자신의 사용자 전자 메일 주소를 대소 문자를 구분하지 않도록 만들 수 있습니다 . 그러나 RFC를 준수하려면 외부 주소를 대소 문자를 구분하여 처리해야합니다 .
c) 업무용 이메일 주소 목록을 직원으로 관리 :
동일한 이메일 수신자가 목록에 두 번 이상 추가 될 수 있지만 다른 경우를 사용할 수 있습니다. 이 경우 주소가 기술적으로 다르지만받는 사람이 중복 전자 메일을받을 수 있습니다. 당신이 치료 방법이 상황은 당신이 점에서) 상황 A와 비슷합니다 아마 중복으로 그들을 치료하고 중복 항목을 제거하는 미세. 그러나 두 주소에 "알림"메일을 보내 서로 중복되는지 묻거나 수신자가 선호하는 전자 메일 주소를 지정하여 이러한 경우를 특별한 경우로 처리하는 것이 좋습니다.
법적인 관점에서 두 주소에서 확인 / 허가없이 복제본을 제거하면 실제로 분리 된 두 수신자 가 서로 다른 주소를 가진 동일한 주소를 가지기 때문에 개인 정보 / 인증 을 무단 주소 로 유출 하는 책임 이 있습니다 .
RFC5321에서 발췌 2.4 :
우편함의 로컬 부분은 대소 문자를 구분해야합니다. 따라서 SMTP 구현에서는 사서함 로컬 부분의 경우를 보존해야합니다. 특히 일부 호스트의 경우 사용자 "smith"는 사용자 "Smith"와 다릅니다. 그러나 사서함 로컬 부분의 대 / 소문자 구분을 활용하면 상호 운용성이 방해되고 사용하지 않는 것이 좋습니다.