Địa chỉ email có thể chứa các ký tự quốc tế (không phải tiếng Anh) không?

Nếu có thể, tôi có nên chấp nhận những email như vậy từ người dùng không và những vấn đề gì sẽ xảy ra khi tôi gửi thư đến những địa chỉ như vậy?

Chính thức, theo RFC 6532 - Có .

Để được giải thích nhanh, hãy xem wikipedia về chủ đề này.

Cập nhật 2015: Sử dụng RFC 6532

Thử nghiệm 5335 đã bị bỏ qua bởi: 6532 và
điều này sau đó đã được đặt thành "Danh mục: Theo dõi Tiêu chuẩn",
làm cho nó trở thành tiêu chuẩn.

Các Phần 3.2 (Cú pháp Extensions để RFC 5322 ) đã cập nhật hầu hết các lĩnh vực văn bản để
bao gồm (thích hợp) UTF-8.

The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
             ; note that this upgrades the body to UTF-8
dtext   =/  UTF8-non-ascii

The preceding changes mean that the following constructs now
allow UTF-8:
   1.  Unstructured text, used in header fields like
       "Subject:" or "Content-description:".
   2.  Any construct that uses atoms, including but not limited
       to the local parts of addresses and Message-IDs. This
       includes addresses in the "for" clauses of "Received:"
       header fields.
   3.  Quoted strings.
   4.  Domains.

Note that header field names are not on this list; these are still
restricted to ASCII.

Xin lưu ý việc bao gồm rõ ràng các Tên miền.
Và loại trừ rõ ràng các tên tiêu đề .

Cũng lưu ý về NFKC :

The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.

Và Phần 3 bắt đầu:

Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.

Vấn đề là một số ứng dụng thư khách (công cụ máy chủ và / hoặc công cụ máy tính để bàn) không hỗ trợ nó và đưa ra một ngoại lệ 'email không hợp lệ' khi bạn cố gắng gửi thư đến một địa chỉ có chứa âm sắc chẳng hạn.

Nếu bạn muốn được hỗ trợ đầy đủ, bạn có thể thực hiện thủ thuật chuyển đổi các phần địa chỉ email thành "punycode". Điều này cho phép người dùng nhập địa chỉ của họ theo cách thông thường nhưng bạn lưu nó theo cách cấp được hỗ trợ.

Ví dụ: müller.com »xn--mller-kva.com

Cả hai điểm giống nhau.

Tôi giả sử là có vì một số miền cấp cao nhất đã cho phép các ký tự không phải ascii cho các miền và vì miền là một phần của địa chỉ email nên điều đó hoàn toàn có thể xảy ra. Ví dụ cho một miền như vậy sẽ là www.öko.de

câu trả lời ngắn gọn: có

không chỉ trong tên người dùng mà còn trong tên miền được cho phép.

Chưa. IEEE có kế hoạch thực hiện điều này: Bài viết H-Online: IEFT lập kế hoạch cho các địa chỉ email được quốc tế hóa , đây là RfC: SMTP Extension cho các địa chỉ email được quốc tế hóa

Trích dẫn từ H-Online (khi nó đã đi xuống):

Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF) đã xuất bản ba tài liệu quan trọng để tiêu chuẩn hóa tiêu đề địa chỉ email bao gồm các ký hiệu bên ngoài bộ ký tự ASCII. Điều này có nghĩa là bạn sẽ sớm có thể sử dụng các ký tự Trung Quốc, giọng Pháp và âm sắc tiếng Đức trong địa chỉ email cũng như ngay trong nội dung thư. Vì vậy, nếu tên bạn là Zoë và bạn làm việc cho một công ty sản xuất mặt tiền, bạn có thể quan tâm đến một địa chỉ email mới. Nhưng đại diện của các nhà cung cấp đã rên rỉ. Họ nói rằng sẽ cần phải có một "cơn hưng cảm nâng cấp" nếu tiêu chuẩn Unicode UTF-8 để thay thế Mã tiêu chuẩn Mỹ cho Trao đổi Thông tin (ASCII) hiện đang được sử dụng làm ngôn ngữ email chung.

RFC 5335 chỉ định việc sử dụng UTF-8 trong thực tế tất cả các tiêu đề email. Các thay đổi sẽ phải được thực hiện đối với máy khách SMTP, máy chủ SMTP, tác nhân người dùng thư (MUA), phần mềm cho danh sách gửi thư, cổng vào phương tiện khác và mọi nơi khác nơi email được xử lý hoặc chuyển đi. RFC 5336 mở rộng giao thức truyền tải email SMTP. Ở cấp độ của giao thức, phần mở rộng được gắn nhãn UTF8SMTP.

Một trường tiêu đề mới sẽ được thêm vào như một loại "dù khẩn cấp" để đảm bảo rằng email UTF-8 có một điểm hạ cánh mềm nếu chúng bị văng ra ngoài trước khi đến tay người nhận bởi hệ thống chưa được nâng cấp. "OldAddress" là một địa chỉ ASCII hoàn toàn. Nhưng OldAddress không được sử dụng như một kênh cho nỗ lực chuyển giao lần thứ hai, mà là để đảm bảo rằng phản hồi được gửi về nhà.

Cuối cùng, RFC5337 đảm bảo rằng các thư chính xác được gửi liên quan đến trạng thái gửi của email không phải ASCII. Địa chỉ chính xác của người nhận không liên lạc được phải được gửi lại, ngay cả khi việc vận chuyển tiếp theo đã bị từ chối. Nhóm công tác Quốc tế hóa địa chỉ email (EAI) cũng đang nghiên cứu một số "cơ chế hạ cấp" cho các trường tiêu đề và phong bì khác nhau. Nếu có thể, thông tin tiêu đề gốc phải được "đóng gói" và bảo quản.

DeNIC của Đức, công ty đăng ký tên miền ".de", vẫn đang thực hiện điều này trong bước tiến của mình. Người phát ngôn của DeNIC, Klaus Herzig, giải thích: “Chúng tôi thực sự không thể làm được gì nhiều. Thay vào đó, DeNIC đang chú ý nhiều hơn đến bản cập nhật mà IETF đang thực hiện cho tiêu chuẩn của các miền quốc tế - RFC3490, hoặc IDNA2003 như đôi khi được biết đến. Herzig giải thích: “Chúng tôi không hài lòng về điều đó vì không có khả năng tương thích ngược. Khi bản cập nhật đến, DeNIC cho biết họ sẽ ném trọng lượng của nó ra sau biểu tượng "ß" - còn được gọi là estzett - vốn đã bị bỏ qua cho đến nay. Cơ quan đăng ký của Đức cũng nói rằng có thể đợi một chút trước khi chuyển đổi do thiếu khả năng tương thích ngược.

Ngược lại, các chuyên gia tin rằng các nhà đăng ký Trung Quốc ở Trung Quốc và Đài Loan sẽ nhanh chóng thực hiện thay đổi đối với email quốc tế hóa. Đại diện của CNIC và TWNIC là tác giả của các tiêu chuẩn. Người dùng Trung Quốc hiện phải viết email bằng ASCII ở bên trái ký tự @ và bằng ký tự Trung Quốc ở bên phải đối với các miền Trung Quốc, vốn đã được quốc tế hóa.

(Monika Ermert)

Câu trả lời là có, nhưng chúng cần được mã hóa đặc biệt.

Nhìn này . Đọc phần đề cập đến tiêu đề email và RFC 2047.