사람들이 전자 메일 주소를 얼마나 멀리 확인해야하는지 궁금합니다. 내 분야는 주로 웹 개발이지만 이것은 어느 곳에서나 적용됩니다.

몇 가지 접근 방식을 보았습니다.

• 단순히 "@"가 있는지 확인하는 것은 간단하지만 당연히 신뢰할 수는 없습니다.
• 표준 이메일 형식에 대한보다 복잡한 정규식 테스트
• 전체 정규식 에 대한 RFC 2822 -이 문제는 자주 전자 메일 주소가 유효 할 수도 있지만 그것은 아마도 사용자가 무엇을 의미하지 않습니다
• DNS 검증
• SMTP 유효성 검사

많은 사람들이 알고 있지만 (많은 사람들이 모르는 경우) 전자 메일 주소는 대부분의 사람들이 일반적으로 고려하지 않는 많은 이상한 변형을 가질 수 있지만 ( RFC 2822 3.4.1 참조 ) 귀하의 확인 : 단순히 전자 메일 메시지를 주소로 보낼 수 있는지 또는 사용자가 입력하려고 한 것일 수 있는지 확인하려고합니까 (다른 모호한 경우가 아닌 모호한 경우는 거의 없습니다) '주소).

내가 생각한 옵션은 더 난해한 주소로 경고를하지만 여전히 요청이 통과되도록 허용하는 것이지만 양식에 더 복잡성을 가중시키고 대부분의 사용자는 혼란 스러울 수 있습니다.

DNS 유효성 검사 / SMTP 유효성 검사는 당연한 것으로 보이지만 DNS 서버 / SMTP 서버가 일시적으로 다운되어 사용자가 어딘가에 등록 할 수 없거나 사용자의 SMTP 서버가 필요한 기능을 지원하지 않는 문제가있을 것으로 예상됩니다.

여기에 경험이 풍부한 일부 개발자가이를 어떻게 처리 할 수 ​​있습니까? 내가 설명한 것 이외의 다른 방법이 있습니까?

편집 : 나는 확인 이메일을 보내는 모든 것을 가장 분명하게 잊어 버렸습니다! 그것을 지적 해준 답변자에게 감사드립니다. 그렇습니다. 이것은 아주 무모하지만 관련된 모든 사람들의 번거 로움이 필요합니다. 사용자는 전자 메일을 가져와야하며 개발자는 유효한 것으로 확인되기 전에 사용자 데이터를 기억해야합니다.

대부분의 포럼과 같이 사용자에게 이메일을 보내고 응답을 기다리는 것 외에는 유효한 이메일 주소를 확인하는 100 % 신뢰할 수있는 방법이 없습니다.

간단한 "@"유효성 검사 규칙을 사용하여 전자 메일 주소를 확인하도록 사용자에게 전자 메일을 보냅니다.

그러나 이것은 내 개인적인 의견이지만 다른 제안을 기다립니다.

한 가지 제안 : +가 포함 된 주소는 거부하지 마십시오. 그것들을 거부하는 것은 성가신 일이지만, 유효한 캐릭터이며, gmail 사용자는 address+label@gmail.com을 사용하여 수신 메일을 더 쉽게 분류하고 분류 할 수 있습니다.

귀하의 게시물에서 "SMTP 유효성 검사"라고 말하면 서버에 연결하고 RCPT TO가 허용되는지 확인하는 것입니다. 실제로 확인 이메일을 보내는 것과 구별하기 때문에 사용자 작업에 따라 수행한다고 가정합니다. 네트워크 문제, DNS 오류 등과 같은 문제 외에도 그레이리스트는이 방법을 혼란스럽게 할 수 있습니다. 방법은 다양하지만 기본적으로 회색 목록은 항상 연결 IP 당 수신자에게 전달하려는 첫 번째 시도를 지연시킵니다. 내가 말했듯이, 이것은 다양 할 수 있지만 일부 호스트는 처음 시도 할 때 유효하지 않은 주소를 거부하고 유효한 주소 만 연기 할 수 있지만 프로그래밍 방식으로 다른 구현을 정렬하는 신뢰할 수있는 방법은 없습니다.

주소가 유효하고 응용 프로그램에 실제로 사용하기를 원하는 소유자가 제출 한 유일한 방법은 확인 이메일을 보내는 것입니다. 스팸이 필터링되지 않는 한 =) 같아요.

이메일 유효성 검사에 정규식을 사용하는 것의 또 다른 약점은 유효 하지 않은 도메인 을 모두 거부하면서 유효한 모든 최상위 도메인 을 잡는 것이 거의 불가능하다는 것입니다.

예를 들어 Jeff Atwood의 답변에 나오는 기본 이메일 정규식은 다음과 같습니다.

\ b [A-Z0-9 ._ % +-] + @ [A-Z0-9 .-] +. [AZ] {2,4} \ b

2 ~ 4 자의 TLD를 허용합니다. 예를 들어 .spam은 허용되지만 .museum 및 .travel (유효한 TLD)은 거부됩니다.

@를 찾아서 확인 이메일을 보내는 것이 더 좋은 이유 하나만 더.

국제 도메인 이름을 사용하면 거의 모든 것이 가능합니다.

• Håkan.Söderström@malmö.se
• punnycode@XN--0ZWM56D.XN--HGBK6AJ7F53BBA
• 试 @ 例子. 测试 .مثال.آزمایشی

테스트를하려면 먼저이를 퓨니 코드로 변환해야합니다.

퓨니 코드 없이는 다음을 테스트해야합니다.

• 하나 이상의 @
• 로컬 부분에서 하나 이상의 문자
• 도메인 부분에서 하나 이상의 점입니다.
• 도메인에서 4 자 이상 (tld에 주소가없고 tld가 2 자 이상이라고 가정)

function isEmail(address) {
    var pos = address.lastIndexOf("@");
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}

@ 및과 같은 간단한 것을 확인하는 것이 가장 좋습니다. JavaScript로 보낸 다음 실제로 확인 이메일을 이메일로 보냅니다. 그들이 그들의 계정을 확인하면, 당신은 자신에게 유효한 이메일 주소가 있습니다. 그렇게하면 근무지 주소가 있다는 것을 확실히 알 수 있으며 양식에 너무 강력 할 필요는 없습니다.

허위 부정을주지 않는 오픈 소스 유효성 검사기를 사용하십시오. 귀하를위한 노력과 앱을위한 강력한 검증.

저는 이제 Cal Henderson, Dave Child, Phil Haack, Doug Lovell 및 RFC 3696의 테스트 사례를 정리했습니다. 158 개의 테스트 주소가 모두 있습니다.

내가 찾은 모든 유효성 검사기에 대해 이러한 모든 테스트를 실행했습니다. 비교는 여기에 있습니다 : http://www.dominicsayers.com/isemail

사람들이 유효성 검사기를 향상시킬 때이 페이지를 최신 상태로 유지하려고합니다. 이 테스트를 컴파일하고 내 검증 자의 건설적인 비판에 도움을 주신 Cal, Dave, Phil에게 감사의 말을 전 합니다.

사람들은 특히 RFC 3696 에 대한 정오표를 알고 있어야합니다 . 정식 예제 중 3 개는 실제로 잘못된 주소입니다. 주소의 최대 길이는 320이 아닌 254 자 또는 256 자 입니다.

답변을 고려할 때 (확인 전자 메일을 완전히 잊어 버렸기 때문에) 저 마찰 솔루션의 적절한 타협은 다음과 같습니다.

1. 정규식을 사용하여 전자 우편 주소가 유효한지 확인하고, 더 모호하지만 명확하게 거부하지 않는 경우 경고를 표시하십시오.
2. SMTP 유효성 검증을 사용하여 전자 우편 주소가 유효한지 확인하십시오.
3. SMTP 검증이 경우 실패 하고 - 다음 에만 다음 - 최후의 수단으로 확인 전자 메일을 사용합니다. 확인 전자 메일은 응용 프로그램 외부에서 상호 작용을 너무 많이 요구하여 마찰이 적은 것으로 간주되지만 완벽한 폴백입니다.

RegexBuddy 는 라이브러리에서 다음과 같은 이메일 관련 정규식을 제공합니다.

이메일 주소 (기본)

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

이메일 주소 (RFC 2822, 단순화)

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

그러나 저는 Peter와 SuperJoe의 답변에 동의하는 경향이 있습니다. 유일한 "테스트"는 실제로 확인 이메일을 보내는 것입니다.

나는 헬프 데스크의 누군가가 O'Malley 또는 O'Brien이라는 이름의 사람이나 아포스트로피가있는 다른 이메일 주소에 의해 소리 치는 4 개의 다른 회사에서 근무했습니다. 이전에 제안했듯이 모든 정규 표현식이 모든 것을 잡을 수는 없지만 경고를하지 않고 번거 로움을 줄이고 아포스트로피를 받아들입니다.

-
BMB

실제로 사서함이 있는지 테스트하기 위해 전자 메일 유효성 검사를 더 수행 할 수 있습니다. 이 기술에는 단점이 있습니다 (개발 시간 및 오용으로 블랙리스트에 올 가능성도 있음). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

전자 메일 을 확인 하려면 (즉, 사용자가 전자 메일 주소를 소유하고 있는지 확인) 확인 전자 메일 만 할 수 있습니다. 그런 다음 많은 사람들이 전용 스팸 주소를 가지고 있거나 OneWayMail 과 같은 서비스를 사용 하며 실제 전자 메일 주소를 제공하지 않으려는 경우에는 그렇지 않습니다. 기본적으로 사용자 방해물을 만들고 있습니다.

이에 관해서 검증 , 사용자가 실수로 잘못 입력 전자 메일 주소가하지 않는 것을 보장하기 위해, 그것은 확실히 올바른 동기입니다. 그러나 적어도 전자 메일 주소를 수집하는 가장 일반적인 방법 인 HTML 양식의 경우 올바른 도구가 아닙니다.

하나, 당신은 이메일 주소의 실제 "단어"에서 오타를 인식 할 수 없습니다. back2dso@example.com형식을 기반으로 잘못된 것을 찾는 방법은 없습니다 .
그러나 더 중요한 것은 사용자 관점에서 입력 할 수있는 전자 메일 주소가 하나만 있다는 것입니다. 그리고 이미 입력했을 것입니다.
따라서 주소를 확인하지 않고 모든 브라우저가 전자 메일 필드를 인식하여 전자 메일 주소를 먼저 입력 할 필요가 없도록하는 데 집중해야합니다. 물론 이전에 브라우저에 전자 메일 주소를 입력하지 않은 사용자가 공격 할 가능성이있는 사이트를 구축하는 경우에는 적용되지 않습니다. 그러나 나는 우리 중 최소한이 그런 입장에 있다고 생각합니다.

이메일을 사용하는 환경에 따라 다릅니다. 더 심각한 프로젝트는 더 엄격한 유효성 검사가 필요하지만 대부분의 경우 적합성 링크를 사용하여 제공된 주소로 이메일을 보내면 이메일 주소가 유효하다고 생각합니다.

@ Mike- 확인 이메일이 전송되는 이유 중 일부는 이메일 주소가 유효한지 확인하는 것뿐만 아니라 이메일 주소를 제출 한 사용자가 액세스 할 수 있다고 생각합니다. 사람이 이메일 주소에 한 글자 오타를 입력하면 다른 유효한 이메일 주소로 이어질 수 있지만 잘못된 주소 일 수 있으므로 여전히 오류가됩니다 .

내가 전자 메일 유효성 검사에 대해 가장 완벽하고 정확한 정규식은 여기에 문서화되어 있습니다 . 그것은 희미한 마음을위한 것이 아닙니다. 인간이 구문 분석하기 쉽도록 여러 부분으로 나눌 정도로 복잡합니다 (샘플 코드는 Java로되어 있음). 그러나 유효성 검사를 계속하는 것이 좋은 경우에는 더 나아질 것이라고 생각하지 않습니다.

어쨌든, 단위 테스트를 사용하여 자신의 표현이 중요하다고 생각되는 경우를 다루고 있는지 확인하는 것이 좋습니다. 그런 식으로, 당신이 그것에 대해 생각하면서, 당신은 당신이 전에 일했던 어떤 사건을 겪지 않았 음을 확신 할 수 있습니다.

당신이 무엇을 선택하든 99 %의 시간을 믿고 있다고 생각하는 사용자 는 자신의 이메일 주소가 무엇인지 실제로 알고 있어야합니다. 호주의 누군가 인 저는 여전히 .com.au 도메인을 보유하고 있지 않다는 사실을 알려주는 전자 메일 검증을 매우 자주 발견합니다. 인터넷의 초기에는 더 많은 일이 발생했습니다.

요즈음 확인 이메일을 보내는 것은 사용자에게 허용되며, 옵트 인 및 제공된 주소의 유효성 검사에도 유용합니다.

내가 근무했던 곳에서 개발 된 일부 사이트에서는 항상 확인 이메일을 사용했습니다. 그러나 사용자가 이메일 주소를 잘못 입력하여 확인 이메일을 기다리지 않은 경우가 종종있었습니다. 이러한 경우 사용자에게 경고하기 위해 임시 코드 (또는 도메인 이름 부분의 경우 DNS 확인)를 추가하는 것이 좋습니다.

내가 본 일반적인 경우 :

• 도메인 이름 중간에 편지를 떨어 뜨리거나 다른 간단한 오타 변형.
• TLD 혼란 (예를 들어, 추가 .br(A)에 .com도메인 또는 적하 .brA로부터 .com.br도메인).
• www.이메일 주소의 로컬 부분의 시작 부분에를 추가하십시오 (이것은 작성하지 않습니다 . 양식의 여러 이메일 주소를 보았습니다 www.username@example.com).

더 기괴한 경우가 있었다. 로컬 부분으로 완전한 도메인 이름 , 두 개로 주소 지정 @(같은 것 username@domain.tld@example.com) 등.

물론 대부분은 여전히 ​​유효한 RFC-822 주소 였으므로 기술적으로 MTA가 처리하도록 할 수 있습니다. 그러나 사용자가 입력 한 전자 메일 주소가 허위 일 가능성이 높다는 경고는 특히 대상 사용자가 컴퓨터에 익숙하지 않은 경우 유용 할 수 있습니다.

세계의 모든 정규식 유효성 검사는 누군가가 부정확하거나 가짜 전자 메일 주소를 입력하는 것을 방해하지 않습니다. 정말 성가시다.

목표에 달려 있습니다. ISP이고 사용자가 유효한 이메일 주소를 작성하고 있는지 확인해야하는 경우 가능한 모든 항목에 대해 유효성 검증을 수행하는 정규식으로 이동하십시오. 사용자 오류를 잡으려면 다음 패턴은 어떻습니까?

[모든 문자, 공백 없음] @ [문자 및 숫자] (. [문자 및 숫자]) 마지막 그룹은 한 번 이상 나타납니다.

이에 대한 정규식은 다음과 같이 나타납니다.

[\S]+@[\w]+(.[\w-]+)+

그런 다음 확인 이메일을 보내 확인하십시오.

@ Yaakov (여기서 일종의 '답변'으로 답장 할 수 있음)

확인 이메일이 전송되는 이유 중 일부는 이메일 주소가 유효한지 확인하는 것뿐만 아니라 이메일 주소를 제출 한 사용자가 액세스 할 수 있다고 생각합니다. 사람은 이메일 주소에 한 글자 오타를 쉽게 입력하여 다른 유효한 이메일 주소로 이어질 수 있지만 잘못된 주소 일 수 있으므로 여전히 오류가됩니다.

나는 동의하지만 그만한 가치가 있는지 확실하지 않습니다. 또한 해당 목적을위한 확인 필드가 있습니다 (이메일 주소를 다시 반복). 사이트 유형에 따라 다른 접근 방식이 필요한 다른 상황도 있습니다.

또한 확인 전자 메일을 보내면 원래 사용자에게 자신이 입력 한 주소가 잘못되었음을 알 수 없습니다. 확인 이메일을받지 못하면 앱 / 사이트에 결함이 있다고 가정 할 수 있습니다. 적어도 사용자가 자신의 계정을 즉시 사용할 수있게함으로써 이메일 주소, 특히 적절한 위치에 표시되는 경우 이메일 주소를 수정할 수 있습니다.

코스 말.

그것들은 모두 유효하고 완전한 이메일 검증 시스템이며 그 자체로 주어진 웹 사이트에 대해 다른 웹 사이트보다 더 적합합니다 (또는 보증 된 것입니다). 많은 경우에 여러 단계의 검증이 유용 할 수 있습니다.

은행 용 웹 사이트를 개발하는 경우 달팽이 메일이나 전화 확인을 원할 것입니다.

컨테스트를위한 웹 사이트를 개발하는 경우 웹 사이트를 원하지 않을 수 있습니다. 후 처리에서 이메일을 확인하고 실패한 경우 입력 한 사람에게 너무 나쁘면 서버 성능을 높이 평가할 수 있습니다. 예를 들어 TV 콘테스트는 모든 사람이 올바르게 인라인으로 확인되도록하는 것입니다.

이메일 확인은 얼마나 걸립니까?

필요한만큼 보증합니다.

그리고 더 이상 (KISS)

Mailinator 또는 MyTrashMail 과 같은 임시 버리기 스팸 버킷 사이트를 사용하는 사람들을 확인하는 전자 메일 사이트도 보았습니다 . 나는 당신이 그것들을 걸러 내야한다고 말하지 않고 단지 말하고 있습니다.

이메일 검증에서 무엇을 찾으려고합니까?

전자 메일 주소의 정규식 유효성 검사는 주소가 구문 적으로 정확하고 상대적으로 그럴듯한 지 확인할 수 있습니다. 또한 정규 표현식이 정확하지 않으면 실제 전달 가능한 주소를 거부 할 수있는 위험이 있습니다 (이미 여러 번 언급 했음).

SMTP 확인은 사용자에 대해 가능한 한 적은 정보를 제공하도록 구성된 그레이 리스팅 또는 서버에 의해 부과 된 제한 사항에 따라 주소를 전달할 수 있는지 확인할 수 있습니다. MTA가 가짜 주소에 대해서만 메일을 수락한다고 주장했는지 여부를 알 방법이 없습니다. 그런 다음 스팸 방지 전략의 일환으로 바닥에 떨어 뜨립니다.

그러나 확인 메시지를 보내는 것이 주소를 입력 한 사용자의 주소인지 확인하는 유일한 방법입니다. 양식을 작성하는 경우 내 이메일 주소가임을 쉽게 알 수 있습니다 president@whitehouse.gov. 정규식은 그것이 구문 적으로 유효하다는 것을 알려주고, SMTP RCPT TO는 그것이 전달 가능한 주소라고 말하지만, 내 주소 가 아닌 것은 확실 합니다.

HTML5가 등장함에 따라 클라이언트 측에서 유효성 을 검증 할 수있는 ' email ' 유형의 입력을 사용하는 가능성이 추가되었습니다 . Firefox, Chrome, Safari 및 Opera의 현재 버전은 이것을 지원합니다 (그리고 다른 브라우저는 type = text처럼 취급하므로 문제없이 사용할 수 있습니다. 물론 확인하지 않아도됩니다).

(몇 번 지적한 것처럼) 실제로 주소를 보장 할 수는 없지만 가능한 사용자 오류를 잡아야하는 곳에는 매우 유용 할 수 있습니다 (결과적으로 서버 측 검사를 대체 함).

이메일 유효성 검사의 세 가지 주요 수준 :

1) 올바른 형식의 이메일 주소 email@email.com에 대한 정규식 확인

2) MX 레코드에 대해 이메일 도메인 확인 도메인 이름에 이메일 서비스가 있는지 확인

3) 확인 링크 또는 코드가 포함 된 확인 이메일 보내기

레벨 1:

Visual Studio에서는 "Regular Expression Validator"를 사용할 수 있습니다. "ValidationExpression"속성에서 마법사가있는 "..."버튼을 클릭하면 이메일 주소에 대한 정규식 형식으로 추가 할 수 있습니다.

레벨 2:

다음은 이메일 도메인에 유효한 MX 레코드가 있는지 확인하기 위해 nslookup을 사용하는 C # 코드입니다. Win 2008 R2 및 Win 7에서 빠르고 올바르게 실행됩니다.

using System.Net.Mail;
using System.Diagnostics;

public static bool checkMXRecords(string email) 
    {
        MailAddress addr = new MailAddress(email);
        string domain = addr.Host;

        string command = "nslookup -querytype=mx " + domain;
        ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + command);

        procStartInfo.RedirectStandardOutput = true;
        procStartInfo.UseShellExecute = false;

        procStartInfo.CreateNoWindow = true;

        Process proc = new Process();
        proc.StartInfo = procStartInfo;
        proc.Start();
        string result = proc.StandardOutput.ReadToEnd();

        if (result.ToLower().Contains("mail exchanger"))
        {
            return true;
        }
        else return false;

     } // checkMXRecords

또 다른 옵션은 Arsofttools nuget 패키지를 사용하는 것이지만 경험 한 것처럼 Windows Server 2008 R2에서는 느릴 수 있지만 Win 7에서는 빠르게 실행됩니다.

3 단계 :

전자 메일 확인을 위해 전자 메일 별 16 진수 URL (암호화 기능 사용) 등 http://domain.com/validateEmail?code=abcd1234 를 생성하여 사용자가 전자 메일 주소를 클릭 할 때 전자 메일 주소를 확인할 수 있습니다. 이 URL을 메모리에 저장할 필요가 없습니다.