Địa chỉ email có nhạy cảm không?


305

Tôi đã đọc rằng phần đầu tiên của e-mail tiêu chuẩn là trường hợp nhạy cảm, tuy nhiên tôi đã cố gắng gửi e-mail đến name@example.com, Name@example.comNAME@example.com- nó đã đến trong mỗi trường hợp.

Làm thế nào để máy chủ mail xử lý tên người dùng? Có thể bỏ lỡ với trường hợp và tin nhắn đó sẽ không được gửi? Có thực sự rất quan trọng để sử dụng chính xác cùng một trường hợp thư, như đã được viết trong khi đăng ký khi đưa địa chỉ e-mail của bạn?


Câu trả lời:


366

Từ RFC 5321, phần 2.3.11 :

Quy ước đặt tên hộp thư tiêu chuẩn được định nghĩa là "local-part @ domain"; sử dụng hiện đại cho phép một bộ ứng dụng rộng hơn nhiều so với "tên người dùng" đơn giản. Do đó, và do lịch sử lâu dài của các vấn đề khi các máy chủ trung gian đã cố gắng tối ưu hóa vận chuyển bằng cách sửa đổi chúng, phần PHẢI cục bộ chỉ được giải thích và gán ngữ nghĩa bởi máy chủ được chỉ định trong phần miền của địa chỉ.

Vì vậy, có, phần trước "@" có thể phân biệt chữ hoa chữ thường, vì nó hoàn toàn nằm dưới sự kiểm soát của hệ thống máy chủ. Trong thực tế, không có hệ thống thư được sử dụng rộng rãi phân biệt các địa chỉ khác nhau dựa trên trường hợp.

Tuy nhiên, phần sau dấu @ là tên miền và theo RFC 1035 , phần 3.1,

"Máy chủ tên và trình phân giải phải so sánh [tên miền] theo cách không phân biệt chữ hoa chữ thường"

Nói tóm lại, bạn an toàn khi coi địa chỉ email là không phân biệt chữ hoa chữ thường.


81
'Nói tóm lại, bạn an toàn khi coi địa chỉ email là không phân biệt chữ hoa chữ thường.' Tôi muốn nói rõ hơn: "bạn không an toàn khi coi địa chỉ email là cách phân biệt chữ hoa chữ thường" Đặc biệt là khi kiểm tra các bản sao trong cơ sở dữ liệu người dùng, v.v.
Geert-Jan

61
Tôi không đồng ý với kết luận này. Nếu bạn đang tìm kiếm các bản sao trong cơ sở dữ liệu - có, một trường hợp không nhạy cảm có lẽ là cách tốt nhất để đi, nhưng tôi đã thấy mã nơi địa chỉ email được chuyển đổi thành chữ thường trước khi gửi. Đó không phải là một ý tưởng tốt, vì có một cơ hội nhỏ nó sẽ không được giao. Vì vậy, cách bạn xử lý nó phụ thuộc vào hậu quả của lỗi là gì và bạn đang làm gì với các địa chỉ email tại thời điểm đó (đối chiếu danh sách các địa chỉ duy nhất, gửi email, v.v.).
Peter Bagnall

11
Có ai biết danh sách các sản phẩm thư sẽ (a) từ chối John.Doe@company.com khi người dùng john.doe@company.com hợp lệ không, hoặc (b) sẽ cho phép hai hộp thư riêng biệt được tạo: John .Doe @ company.com và john.doe@company.com?
MSC

51
Tôi làm việc tại một công ty lớn và có một người khác có cùng họ và tên. Hôm nay tôi phát hiện ra rằng phần địa phương của anh ta khác với phần vốn của tôi. Điều này đã hoạt động tốt, vì vậy tôi rất ngạc nhiên khi thấy "không có hệ thống thư được sử dụng rộng rãi nào phân biệt các địa chỉ khác nhau dựa trên trường hợp". Chúng tôi sử dụng MS Exchange mà tôi sẽ gọi là "được sử dụng rộng rãi".
Matthew James Briggs

7
RFC 5321 2.4. Các nguyên tắc cú pháp chung và mô hình giao dịch - Việc triển khai SMTP PHẢI cẩn thận để bảo vệ trường hợp hộp thư cục bộ. Đặc biệt, đối với một số máy chủ, người dùng "smith" khác với người dùng "Smith". Các miền hộp thư tuân theo các quy tắc DNS thông thường và do đó không phân biệt chữ hoa chữ thường.
Adam111p

43

Tôi biết đây là một câu hỏi cũ nhưng tôi chỉ muốn bình luận ở đây: Ở bất kỳ địa chỉ email nào có phân biệt chữ hoa chữ thường, hầu hết người dùng sẽ "rất không khôn ngoan" khi chủ động sử dụng một địa chỉ email yêu cầu viết hoa. Họ sẽ sớm ngừng sử dụng địa chỉ vì họ sẽ thiếu rất nhiều thư. (Trừ khi họ có một lý do cụ thể để gây khó khăn và họ chỉ mong đợi thư từ những người gửi cụ thể mà họ biết.)

Đó là bởi vì con người không hoàn hảo cũng như phần mềm không hoàn hảo tồn tại, (Thật ngạc nhiên!) Sẽ cho rằng tất cả email là chữ thường và vì lý do này, những người và phần mềm này sẽ gửi tin nhắn bằng cách sử dụng "phiên bản có vỏ thấp" của địa chỉ bất kể nó được cung cấp như thế nào đối với họ. Nếu người nhận không thể nhận được những tin nhắn như vậy, sẽ không lâu sau khi họ nhận thấy họ thiếu rất nhiều và chuyển sang địa chỉ email chỉ viết thường hoặc để máy chủ của họ được thiết lập không phân biệt chữ hoa chữ thường.


14
Đây là ứng dụng sâu sắc của luật Postel en.wikipedia.org/wiki/Robustness_principl . Việc viết phần mềm giả định các phần cục bộ của địa chỉ email là không phân biệt chữ hoa chữ thường, nhưng đúng vậy, cho rằng có rất nhiều phần mềm sai ở đó, nó cũng không đủ mạnh để yêu cầu phân biệt chữ hoa chữ thường nếu bạn là người chấp nhận thư .
zigg

1
Một trong những điều tôi thất vọng nhất là các trang web buộc tôi phải viết email bằng mọi cách. Chỉ cần đưa ra một bình luận tức giận cho Twitch.tv về điều đó liên quan đến trang web hỗ trợ của họ. Họ chặn bạn thậm chí nhập chữ hoa trên trang web của họ. Vì vậy, trong khi tôi biết máy chủ email của mình coi chúng là không phân biệt chữ hoa chữ thường và tôi biết RFC tuyên bố nó phân biệt chữ hoa chữ thường, các trang web KHÔNG BAO GIỜ đưa ra bất kỳ giả định nào và chỉ nên chuyển qua những gì người dùng nhập vào. MAN thật là khó chịu !!!
Đánh dấu A. Donohoe

Cá nhân, khi tôi gõ email của mình ở đâu đó, tôi thích sử dụng trường hợp hỗn hợp hơn để nó dễ đọc hơn. Ví dụ: JamesTKirk@domain.com (Không phải địa chỉ thật của tôi.) Tôi làm điều này mặc dù tôi nhận được email mà không cần viết hoa.
PaulOTron2000

Tuy nhiên, là một tác giả phần mềm, bạn muốn dịch vụ của mình là một trong số ít những công việc phù hợp với người này với email phân biệt chữ hoa chữ thường.
Klesun

31

Đến cuối bài này, nhưng tôi có vài điều hơi khác để nói ...

>> "Are email addresses case sensitive?"

Chà, "Nó phụ thuộc ..." (TM)

Một số tổ chức thực sự nghĩ rằng đó là một ý tưởng tốt và máy chủ email của họ thực thi phân biệt chữ hoa chữ thường.

Vì vậy, đối với những nơi điên rồ đó, "Có, Email rất phân biệt chữ hoa chữ thường".

Lưu ý: Chỉ vì một đặc điểm kỹ thuật nói rằng bạn có thể làm điều gì đó không có nghĩa là đó là một ý tưởng tốt để làm như vậy.

Nguyên tắc của KISS cho thấy các hệ thống của chúng tôi sử dụng email không phân biệt chữ hoa chữ thường.

Trong khi đó, nguyên tắc Robustness cho thấy rằng chúng tôi chấp nhận các email nhạy cảm.

Giải pháp:

  • Lưu trữ email với phân biệt chữ hoa chữ thường
  • Gửi email với phân biệt chữ hoa chữ thường
  • Thực hiện tìm kiếm nội bộ với trường hợp không nhạy cảm

Điều này có nghĩa là nếu email này đã tồn tại: user@x.com

... Và một người dùng khác xuất hiện và muốn sử dụng email này: USER@x.com

... Rằng logic tìm kiếm không nhạy cảm trong trường hợp của chúng tôi sẽ trả về thông báo lỗi "Email đó đã tồn tại".

Bây giờ, bạn có một quyết định để đưa ra: Giải pháp đó có đầy đủ trong trường hợp của bạn không?

Nếu không, bạn có thể tính phí tiện lợi cho những khách hàng cần hỗ trợ cho các email nhạy cảm với trường hợp của họ và triển khai logic tùy chỉnh cho phép USER@x.com vào hệ thống của bạn, ngay cả khi user@x.com đã tồn tại.

Trong trường hợp đó, logic tìm kiếm / xác thực email của bạn có thể trông giống như mã giả này:

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 + '"
}

Bằng cách này, bạn chủ yếu thực thi sự vô cảm trong trường hợp nhưng cho phép khách hàng trả tiền cho hỗ trợ này nếu họ đang sử dụng các hệ thống email hỗ trợ vô nghĩa như vậy.

ps ILIKE là một từ khóa PostgreSQL: http://www.postgresql.org/docs/9.2/static/fifts-matching.html


8
THÍCH / ILIKE cho một trận đấu chính xác là một ý tưởng khủng khiếp. Hãy tưởng tượng một email có chứa %hoặc nhiều khả năng_
ThiefMaster

18
Điểm của bạn rất tuyệt! Nhưng tiêm sql trong ví dụ của bạn làm hỏng nó :(
epelc

6
@epelc NÀY. Không thể đồng ý nhiều hơn. Kiểu xây dựng truy vấn đó không nên được viết ở bất cứ đâu ngay cả khi đó chỉ là một ví dụ.
xDaizu

1
@ l3x, trong khi tôi không mạnh mẽ chống lại mã ví dụ trên như các mã khác, cụ thể là vì bạn đã gọi nó là mã giả và nó chỉ nhằm mục đích minh họa, có lẽ tất cả các ý kiến ​​trên có thể được giải quyết bằng cách thay thế các query = ...dòng của bạn bằng những query = // Insert case-sensitive/insensitive search herebình luận đơn giản vì điều đó giúp cuộc trò chuyện tránh xa chủ đề tiêm SQL và tập trung vào những gì bạn đang cố gắng thể hiện. Nói cách khác, giữ nó trên logic, không phải việc thực hiện. Nó sẽ làm câm lặng các nhà phê bình.
Đánh dấu A. Donohoe

10

Tiêu chuẩn mở IETF RFC 5321 2.4. Nguyên tắc tổng hợp và mô hình giao dịch

Việc triển khai SMTP PHẢI cẩn thận để bảo vệ trường hợp hộp thư cục bộ. Đặc biệt, đối với một số máy chủ, người dùng "smith" khác với người dùng "Smith".

Các miền hộp thư tuân theo các quy tắc DNS thông thường và do đó không phân biệt chữ hoa chữ thường


3

Mỗi @ l3x, nó phụ thuộc.

Rõ ràng có hai bộ tình huống chung trong đó câu trả lời đúng có thể khác nhau, cùng với một bộ thứ ba không chung chung:

a) Bạn là người dùng gửi thư riêng :

Rất ít hệ thống email hiện đại thực hiện phân biệt chữ hoa chữ thường, vì vậy bạn có thể ổn để bỏ qua trường hợp và chọn bất kỳ trường hợp nào bạn cảm thấy thích sử dụng. Không có gì đảm bảo rằng tất cả các thư của bạn sẽ được gửi - nhưng rất ít thư sẽ bị ảnh hưởng tiêu cực mà bạn không nên lo lắng về nó.

b) Bạn đang phát triển phần mềm thư :

Xem đoạn trích RFC5321 2.4 ở phía dưới.

Khi bạn đang phát triển phần mềm thư, bạn muốn tuân thủ RFC. Bạn có thể làm cho trường hợp địa chỉ email của người dùng của bạn không nhạy cảm nếu bạn muốn (và có lẽ bạn nên). Nhưng để tuân thủ RFC, bạn PHẢI coi các địa chỉ bên ngoài là trường hợp nhạy cảm .

c) Quản lý danh sách các địa chỉ email thuộc sở hữu doanh nghiệp với tư cách là nhân viên :

Có thể cùng một người nhận email được thêm vào danh sách nhiều lần - nhưng sử dụng trường hợp khác nhau. Trong tình huống này mặc dù các địa chỉ khác nhau về mặt kỹ thuật, nó có thể dẫn đến việc người nhận nhận được email trùng lặp. Cách bạn xử lý tình huống này tương tự như tình huống a) ở chỗ bạn có thể ổn khi coi chúng là bản sao và loại bỏ một mục trùng lặp. Tuy nhiên, tốt hơn là coi đây là những trường hợp đặc biệt, bằng cách gửi thư "nhắc nhở" đến cả hai địa chỉ để hỏi xem chúng có phải là bản sao của nhau không và nếu có thì địa chỉ email nào người nhận sẽ thích bạn sử dụng.

Từ quan điểm pháp lý, nếu bạn xóa một bản sao mà không có sự thừa nhận / cho phép từ cả hai địa chỉ, bạn có thể phải chịu trách nhiệm về việc rò rỉ thông tin cá nhân / xác thực đến một địa chỉ trái phép chỉ vì hai người nhận thực sự tách biệtcùng một địa chỉ với các trường hợp khác nhau .

Trích từ RFC5321 2.4:

Phần cục bộ của hộp thư PHẢI được coi là trường hợp nhạy cảm. Do đó, việc triển khai SMTP PHẢI cẩn thận để bảo vệ trường hợp hộp thư cục bộ. Đặc biệt, đối với một số máy chủ, người dùng "smith" khác với người dùng "Smith". Tuy nhiên, việc khai thác độ nhạy trường hợp của các bộ phận cục bộ hộp thư cản trở khả năng tương tác và không được khuyến khích.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.