Tôi đang tự hỏi mọi người nên xác nhận địa chỉ email đến mức nào. Lĩnh vực của tôi chủ yếu là phát triển web, nhưng điều này áp dụng ở bất cứ đâu.

Tôi đã thấy một vài cách tiếp cận:

• chỉ cần kiểm tra xem có hiện tại "@" không, điều này thật đơn giản nhưng tất nhiên là không đáng tin cậy.
• một bài kiểm tra regex phức tạp hơn cho các định dạng e-mail tiêu chuẩn
• một regex đầy đủ chống lại RFC 2822 - vấn đề với điều này là thường địa chỉ email có thể hợp lệ nhưng có lẽ đó không phải là ý của người dùng
• Xác thực DNS
• Xác thực SMTP

Như nhiều người có thể biết (nhưng nhiều người không biết), địa chỉ email có thể có nhiều biến thể lạ mà hầu hết mọi người thường không xem xét (xem RFC 2822 3.4.1 ), nhưng bạn phải suy nghĩ về các mục tiêu của xác thực của bạn: bạn chỉ đang cố gắng đảm bảo rằng một tin nhắn e-mail có thể được gửi đến một địa chỉ, hoặc đó là những gì người dùng có thể muốn đưa vào (rất khó xảy ra trong nhiều trường hợp khó hiểu hơn 'hợp lệ 'Địa chỉ).

Một tùy chọn tôi đã xem xét chỉ đơn giản là đưa ra cảnh báo với một địa chỉ bí truyền hơn nhưng vẫn cho phép yêu cầu được thực hiện, nhưng điều này làm tăng thêm sự phức tạp cho một biểu mẫu và hầu hết người dùng có thể bị nhầm lẫn.

Mặc dù xác thực DNS / xác thực SMTP có vẻ như không có trí tuệ, tôi thấy trước các vấn đề trong đó máy chủ DNS / máy chủ SMTP tạm thời ngừng hoạt động và người dùng không thể đăng ký ở đâu đó hoặc máy chủ SMTP của người dùng không hỗ trợ các tính năng cần thiết.

Làm thế nào một số nhà phát triển có kinh nghiệm ở đây xử lý điều này? Có cách tiếp cận nào khác ngoài những cách tôi đã liệt kê không?

Chỉnh sửa: Tôi hoàn toàn quên mất điều rõ ràng nhất trong tất cả, gửi e-mail xác nhận! Cảm ơn người trả lời đã chỉ ra rằng một trong những. Vâng, điều này là khá dễ dàng, nhưng nó đòi hỏi thêm rắc rối về phía tất cả mọi người liên quan. Người dùng phải tìm nạp một số e-mail và nhà phát triển cần nhớ dữ liệu người dùng trước khi chúng được xác nhận là hợp lệ.

Không có cách nào đáng tin cậy 100% để xác nhận địa chỉ email hợp lệ ngoài việc gửi email cho người dùng và chờ phản hồi, như hầu hết các diễn đàn.

Tôi sẽ sử dụng quy tắc xác thực "@" đơn giản và sau đó gửi email cho người dùng để xác nhận địa chỉ email của họ.

Mặc dù, đây là ý kiến ​​cá nhân của tôi ... Tôi chờ đợi những gợi ý khác.

Một đề xuất: không từ chối địa chỉ có dấu + trong đó. Việc từ chối chúng là rất khó chịu, nhưng đó là một ký tự hợp lệ và người dùng gmail có thể sử dụng địa chỉ+label@gmail.com để gắn nhãn và sắp xếp thư đến dễ dàng hơn.

Trong bài đăng của bạn, dường như khi bạn nói "Xác thực SMTP", bạn có nghĩa là kết nối với máy chủ và thử RCPT TO để xem nó có được chấp nhận hay không. Vì bạn phân biệt nó với việc thực sự gửi email xác nhận, tôi giả sử bạn muốn thực hiện nội tuyến với hành động của người dùng. Ngoài các vấn đề như sự cố mạng, lỗi DNS, v.v., danh sách màu xám có thể tàn phá phương pháp này. Phương thức khác nhau, nhưng về cơ bản, danh sách màu xám luôn trì hoãn nỗ lực đầu tiên để phân phối đến người nhận trên mỗi IP kết nối. Như tôi đã nói, điều này có thể khác nhau, một số máy chủ có thể từ chối các địa chỉ không hợp lệ ở lần thử đầu tiên và chỉ trì hoãn các địa chỉ hợp lệ, nhưng không có cách nào đáng tin cậy để sắp xếp các triển khai khác nhau theo chương trình.

Cách duy nhất bạn sẽ chắc chắn rằng một địa chỉ hợp lệ và được gửi bởi chủ sở hữu của nó, người thực sự muốn nó được sử dụng cho ứng dụng của bạn là gửi email xác minh. Chà, miễn là nó không bị lọc spam tôi đoán =).

Một điểm yếu khác của việc sử dụng biểu thức chính quy để xác thực email là hầu như không thể bắt được tất cả các tên miền cấp cao hợp lệ trong khi từ chối tất cả các tên miền không hợp lệ.

Chẳng hạn, biểu thức email cơ bản trong câu trả lời của Jeff Atwood:

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

sẽ chấp nhận bất kỳ TLD nào có từ hai đến bốn ký tự. Vì vậy, ví dụ: .spam sẽ được chấp nhận, nhưng .museum và .travel (cả hai TLD hợp lệ) sẽ bị từ chối.

Chỉ một lý do nữa là tốt hơn là chỉ cần tìm @ và gửi email xác nhận.

Với tên miền quốc tế, hầu hết mọi thứ đều có thể:

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

Nếu bạn muốn thực hiện bất kỳ thử nghiệm nào, trước tiên bạn nên chuyển đổi nó thành Punycode.

Không có Punycode, tất cả những gì bạn nên làm là kiểm tra xem có:

• ít nhất một @
• có ít nhất một ký tự trong phần cục bộ
• là ít nhất một dấu chấm trong phần tên miền
• có ít nhất bốn ký tự trong miền (giả sử rằng không ai có địa chỉ tại tld, rằng tld có ít nhất 2 ký tự)

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

Tốt nhất bạn chỉ nên kiểm tra những thứ đơn giản như @ và. trong JavaScript và sau đó thực sự gửi cho họ một xác minh đến email của họ. Nếu họ xác minh tài khoản của họ, bạn có cho mình một địa chỉ email hợp lệ. Bằng cách đó, bạn biết chắc chắn mình có địa chỉ làm việc và bạn không cần phải quá hách dịch trong mẫu đơn.

Sử dụng trình xác nhận nguồn mở không đưa ra các phủ định sai. Không có nỗ lực cho bạn và xác nhận mạnh mẽ cho ứng dụng của bạn.

Bây giờ tôi đã đối chiếu các trường hợp kiểm tra từ Cal Henderson, Dave Child, Phil Haack, Doug Lovell và RFC 3696. 158 địa chỉ kiểm tra tất cả.

Tôi đã chạy tất cả các bài kiểm tra này chống lại tất cả các trình xác nhận mà tôi có thể tìm thấy. So sánh ở đây: http://www.dominicsayers.com/isemail

Tôi sẽ cố gắng cập nhật trang này khi mọi người nâng cao trình xác nhận của họ. Cảm ơn Cal, Dave và Phil đã giúp đỡ và hợp tác trong việc biên soạn các bài kiểm tra này và phê bình mang tính xây dựng của người xác nhận của riêng tôi .

Mọi người nên biết về lỗi sai đối với RFC 3696 nói riêng. Ba trong số các ví dụ kinh điển trên thực tế là các địa chỉ không hợp lệ. Và độ dài tối đa của một địa chỉ là 254 hoặc 256 ký tự, không phải 320.

Khi xem xét từ các câu trả lời (vì tôi hoàn toàn quên mất email xác nhận), có vẻ như tôi là một sự thỏa hiệp phù hợp cho một giải pháp ma sát thấp sẽ là:

1. Sử dụng regex để kiểm tra xem địa chỉ e-mail có hợp lệ không và đưa ra cảnh báo nếu nó tối nghĩa hơn nhưng tránh từ chối hoàn toàn.
2. Sử dụng xác thực SMTP để đảm bảo rằng địa chỉ email là hợp lệ.
3. Nếu xác thực SMTP không thành công thì - và chỉ sau đó - sử dụng e-mail xác nhận như là phương sách cuối cùng. Email xác nhận dường như yêu cầu quá nhiều tương tác bên ngoài ứng dụng của bạn để chúng được coi là ma sát thấp, nhưng chúng là một dự phòng hoàn hảo.

RegexBuddy cung cấp các biểu thức chính quy liên quan đến email sau đây từ thư viện của nó:

Địa chỉ email (cơ bản)

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

Địa chỉ email (RFC 2822, được đơn giản hóa)

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

Nhưng tôi có xu hướng đồng ý với câu trả lời của Peter và SuperJoe; "thử nghiệm" thực sự duy nhất là thực sự gửi một email xác nhận.

Tôi đã làm việc tại 4 công ty khác nhau, nơi một người nào đó tại bàn trợ giúp đã bị ai đó tên là O'Malley hoặc O'Brien hoặc một số địa chỉ e-mail khác với dấu nháy đơn. Như đã đề xuất trước đây, không phải tất cả các regex sẽ nắm bắt mọi thứ, nhưng hãy tự cứu mình một số rắc rối và chấp nhận dấu nháy đơn mà không tạo ra cảnh báo.

-
bmb

Bạn vẫn có thể xác thực email để tiếp tục kiểm tra nếu hộp thư tồn tại. Kỹ thuật này có nhược điểm của nó (thời gian phát triển và cũng có khả năng bị đưa vào danh sách đen vì lạm dụng). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-seinating-an-email/

Nếu bạn muốn xác minh e-mail (nghĩa là đảm bảo rằng người dùng sở hữu địa chỉ e-mail), e-mail xác nhận là điều duy nhất bạn có thể làm. Sau đó, một lần nữa, nhiều người có địa chỉ spam chuyên dụng hoặc sử dụng các dịch vụ như OneWayMail và nếu họ không muốn cung cấp cho bạn địa chỉ e-mail thực tế của họ, họ sẽ không làm thế. Vì vậy, về cơ bản bạn đang tạo ra sự cản trở người dùng.

Khi nói đến xác nhận , để đảm bảo rằng người dùng không vô tình nhập sai địa chỉ e-mail, đó chắc chắn là động lực đúng đắn. Tuy nhiên, ít nhất là đối với các biểu mẫu HTML (cho đến nay là cách thu thập địa chỉ email phổ biến nhất), nó hầu như không phải là công cụ phù hợp.

Đối với một, bạn sẽ không thể nhận ra lỗi chính tả trong "từ" thực tế của địa chỉ email. Bạn không có cách nào để tìm ra điều đó back2dso@example.comlà sai, chỉ dựa trên định dạng.
Nhưng quan trọng hơn, từ quan điểm người dùng, chỉ có một (hoặc một bàn tay đầy đủ) địa chỉ email bạn có thể muốn nhập. Và có lẽ bạn đã nhập nó.
Vì vậy, thay vì cố gắng xác thực một địa chỉ, bạn nên tập trung vào việc đảm bảo rằng tất cả các trình duyệt nhận ra trường email và do đó loại bỏ nhu cầu nhập địa chỉ email ở vị trí đầu tiên. Tất nhiên, điều này không áp dụng, nếu bạn đang xây dựng loại trang web có khả năng bị tấn công bởi những người dùng chưa bao giờ nhập địa chỉ e-mail của họ vào trình duyệt của họ trước đó. Nhưng tôi cho rằng ít nhất chúng ta ở vị trí như vậy.

Tôi nghĩ nó phụ thuộc vào bối cảnh bạn đang sử dụng email. Các dự án nghiêm trọng hơn yêu cầu xác nhận chặt chẽ hơn nhưng tôi nghĩ rằng đối với hầu hết mọi thứ, việc gửi email đến địa chỉ được cung cấp với một liên kết thông tin sẽ đảm bảo địa chỉ email là hợp lệ.

@ Mike - Tôi nghĩ rằng một phần lý do tại sao email xác nhận được gửi không chỉ để đảm bảo rằng địa chỉ email hợp lệ mà còn có thể truy cập được bởi người dùng đã gửi nó. Một người có thể dễ dàng đặt một lỗi đánh máy một chữ cái trong địa chỉ email sẽ dẫn đến một địa chỉ email hợp lệ khác, nhưng đó vẫn là một lỗi vì đó là địa chỉ sai .

Regex đầy đủ và chính xác nhất mà tôi từng gặp để xác thực email là một tài liệu được ghi lại ở đây . Nó không dành cho người yếu tim; nó đủ phức tạp để nó được chia thành nhiều phần để giúp con người dễ dàng phân tích cú pháp hơn (mã mẫu là trong Java). Nhưng trong trường hợp tất cả các cách với xác nhận là có công, tôi không nghĩ rằng nó sẽ tốt hơn nhiều.

Trong mọi trường hợp, tôi sẽ đề nghị bạn sử dụng thử nghiệm đơn vị để xác nhận rằng biểu thức của bạn bao gồm các trường hợp mà bạn cảm thấy là quan trọng. Bằng cách đó, khi bạn tìm hiểu kỹ về nó, bạn có thể chắc chắn rằng mình chưa phá vỡ một số trường hợp hoạt động trước đây.

Dù bạn lựa chọn, tôi nghĩ rằng bạn cần phải sai lầm về phía của tin rằng 99% thời gian, người dùng không thực sự biết địa chỉ email của họ là gì. Là một người đến từ Úc, thỉnh thoảng tôi vẫn thấy một xác thực email rất thông minh cho tôi biết rằng tôi không thể có một tên miền .com.au. Nó được sử dụng để xảy ra nhiều hơn trong những ngày đầu của internet tâm trí bạn.

Gửi email xác nhận những ngày này được người dùng chấp nhận và cũng hữu ích về mặt chọn tham gia cũng như xác thực địa chỉ được cung cấp của họ.

Trên một số trang web được phát triển tại những nơi tôi đã làm việc, chúng tôi luôn sử dụng email xác nhận. Tuy nhiên, thật đáng ngạc nhiên khi người dùng gõ nhầm địa chỉ email của họ theo những cách không thể thực hiện được, và sau đó tiếp tục chờ email xác nhận sẽ không đến. Thêm mã ad-hoc (hoặc, cho phần tên miền, xác minh DNS) để cảnh báo người dùng trong những trường hợp này có thể là một ý tưởng hay.

Các trường hợp phổ biến tôi đã thấy:

• Thả một chữ cái ở giữa tên miền hoặc một số biến thể lỗi chính tả đơn giản khác.
• Sự nhầm lẫn TLD (ví dụ: thêm .brmột .comtên miền hoặc thả .brtừ một .com.brtên miền).
• Thêm một www.ở đầu phần địa phương của một địa chỉ email (Tôi không tạo ra điều này; tôi thấy một số địa chỉ email của biểu mẫu www.username@example.com).

Thậm chí còn có những trường hợp kỳ quái hơn; những thứ như một tên miền hoàn chỉnh như một phần cục bộ, địa chỉ với hai @(một cái gì đó giống như username@domain.tld@example.com), v.v.

Tất nhiên, hầu hết trong số chúng vẫn là các địa chỉ RFC-822 hợp lệ, vì vậy về mặt kỹ thuật, bạn chỉ có thể để MTA xử lý chúng. Tuy nhiên, cảnh báo người dùng rằng địa chỉ email được nhập hoàn toàn có thể là không có thật có thể hữu ích, đặc biệt nếu đối tượng mục tiêu của bạn không biết nhiều về máy tính.

Tất cả xác thực regex trên thế giới sẽ không ngăn ai đó nhập địa chỉ email giả hoặc không chính xác. Thật là khó chịu, thật đấy.

Phụ thuộc vào mục tiêu. Nếu bạn là một ISP và bạn cần xác thực rằng người dùng đang tạo địa chỉ email hợp lệ, hãy truy cập Regex xác thực theo mọi thứ có thể. Nếu bạn chỉ muốn bắt lỗi người dùng, làm thế nào về mẫu sau:

[Tất cả các ký tự, không có dấu cách] @ [chữ cái và số] (. [Chữ cái và số]) trong đó nhóm cuối cùng xuất hiện ít nhất một lần.

RegEx cho điều này sẽ xuất hiện một cái gì đó như thế này:

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

Và sau đó gửi email xác nhận để chắc chắn.

@ Yaakov (có thể trả lời làm với một số loại 'trả lời' ở đây)

Tôi nghĩ rằng một phần lý do tại sao email xác nhận được gửi không chỉ để đảm bảo rằng địa chỉ email hợp lệ mà còn có thể truy cập được bởi người dùng đã gửi nó. Một người có thể dễ dàng đặt một lỗi đánh máy một chữ cái trong địa chỉ email sẽ dẫn đến một địa chỉ email hợp lệ khác, nhưng đó vẫn là một lỗi vì đó là địa chỉ sai.

Tôi đồng tình, nhưng tôi không chắc nó có giá trị. Chúng tôi cũng có các trường xác nhận cho mục đích đó (lặp lại địa chỉ e-mail của bạn). Một tình huống khác mà loại trang web có thể đảm bảo các cách tiếp cận khác nhau.

Ngoài ra, việc tự gửi e-mail xác nhận sẽ không có cách nào cho người dùng ban đầu biết rằng địa chỉ họ đã nhập sai. Sau khi không nhận được email xác nhận, họ có thể cho rằng ứng dụng / trang web của bạn bị lỗi; ít nhất bằng cách cho phép người dùng bắt đầu sử dụng ngay tài khoản của họ, họ có thể sửa địa chỉ email của mình, đặc biệt nếu nó được hiển thị ở một nơi rõ ràng phù hợp.

Ngựa cho các khóa học.

Tất cả những hệ thống này là hợp lệ, hoàn chỉnh các hệ thống xác minh email trong và của chính họ, và đối với một trang web nhất định, một trang web sẽ phù hợp hơn (hoặc tốt như được bảo hành) so với các trang web khác. Trong nhiều trường hợp, một số bước xác minh có thể hữu ích.

Nếu bạn đang phát triển một trang web cho một ngân hàng, bạn sẽ muốn xác nhận thư điện tử hoặc điện thoại trên tất cả những thứ này.

Nếu bạn đang phát triển một trang web cho một cuộc thi, bạn có thể không muốn bất kỳ ai trong số họ - xác minh các email trong quá trình xử lý bài đăng và nếu thất bại thì điều đó quá tệ đối với người tham gia cuộc thi - bạn có thể đánh giá cao hiệu suất của máy chủ với số lượng người rất lớn ( Ví dụ, cuộc thi trên TV) đảm bảo rằng mọi người đều được xác thực nội tuyến chính xác.

Làm thế nào xa một người nên xác minh email?

Khi cần thiết và bảo hành.

Và không còn nữa (KISS)

Tôi đã thấy các trang web cũng bảo vệ chống lại mọi người bằng cách sử dụng các trang web xô thư rác tạm thời như Mailinator hoặc MyTrashMail , xung quanh điều xác nhận email. Tôi không nói rằng bạn nên lọc chúng ra, tôi chỉ nói.

Bạn đang cố gắng để xác nhận email của bạn là gì?

Xác nhận chính xác các địa chỉ email có thể, tốt nhất, có thể xác minh rằng địa chỉ đó là chính xác về mặt cú pháp và tương đối hợp lý. Nó cũng có nguy cơ (như đã được đề cập nhiều lần) về việc có thể từ chối các địa chỉ thực tế, có thể giao được nếu regex không hoàn toàn chính xác.

Xác minh SMTP có thể xác định rằng địa chỉ có thể phân phối được, tuân theo các giới hạn được áp đặt bởi trình duyệt hoặc máy chủ được định cấu hình để cung cấp càng ít thông tin càng tốt về người dùng của họ. Bạn không có cách nào để biết liệu MTA chỉ tuyên bố chấp nhận thư cho một địa chỉ không có thật, sau đó chỉ bỏ nó trên sàn như một phần của chiến lược chống thư rác.

Tuy nhiên, gửi một tin nhắn xác nhận là cách duy nhất để xác minh rằng một địa chỉ thuộc về người dùng đã nhập nó. Nếu tôi điền vào biểu mẫu của bạn, tôi có thể dễ dàng nói với bạn rằng địa chỉ email của tôi là president@whitehouse.gov. Một regex sẽ cho bạn biết nó có hiệu lực về mặt cú pháp, một RC RCPT TO sẽ cho bạn biết đó là một địa chỉ có thể giao được, nhưng chắc chắn đó không phải là địa chỉ của tôi .

Với sự xuất hiện của HTML5, ít nhất một cách tiếp cận mới được thêm vào các khả năng: việc sử dụng kiểu nhập ' email ' cho phép xác thực ở phía máy khách. Các phiên bản hiện tại của Firefox, Chrome, Safari và Opera đều hỗ trợ điều này (và các trình duyệt khác chỉ coi nó như type = text, vì vậy nó có thể được sử dụng mà không gặp vấn đề gì vì vậy bạn không có xác nhận tất nhiên.)

Nó không bao giờ có thể (như được chỉ ra một vài lần) đảm bảo một địa chỉ khả thi, nhưng nó có thể rất có lợi (và cuối cùng thay thế kiểm tra phía máy chủ) ở những nơi bạn chỉ cần bắt lỗi người dùng.

Ba cấp độ xác thực email chính:

1) kiểm tra biểu thức chính quy cho một địa chỉ email được định dạng chính xác email@email.com

2) kiểm tra tên miền email đối với các bản ghi MX để xem tên miền có dịch vụ email không

3) gửi email xác nhận với một liên kết xác nhận hoặc mã

Cấp độ 1:

Trong Visual Studio, bạn có thể sử dụng "Trình xác thực biểu thức chính quy". Và trong thuộc tính "Xác thựcExpression", bạn có thể nhấp vào nút "..." có trình hướng dẫn để thêm vào định dạng biểu thức chính quy cho địa chỉ email.

Cấp độ 2:

Dưới đây là mã C # của tôi dưới đây để sử dụng nslookup để xác minh xem tên miền email có bản ghi MX hợp lệ hay không. Chạy nhanh và ok trên Win 2008 R2 và 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

Một tùy chọn khác là sử dụng gói nuget Arsofttools nhưng nó có thể chậm trên Windows Server 2008 R2 như tôi đã trải nghiệm nhưng chạy nhanh trên Win 7.

Cấp 3:

Để xác nhận email, bạn có thể tạo url hex cụ thể cho email (sử dụng chức năng mã hóa), v.v ... http://domain.com/validateEmail?code=abcd1234 để xác thực địa chỉ email khi người dùng nhấp vào nó. Không cần lưu trữ url này trong bộ nhớ.