Jeśli to możliwe, czy powinienem akceptować takie e-maile od użytkowników i jakich problemów się spodziewać, kiedy będę wysyłać maile na takie adresy?
Jeśli to możliwe, czy powinienem akceptować takie e-maile od użytkowników i jakich problemów się spodziewać, kiedy będę wysyłać maile na takie adresy?
Odpowiedzi:
Aktualizacja 2015: użyj RFC 6532
Eksperymentalny 5335 został przestarzały przez: 6532, a
później został ustawiony na „Category: Standards Track”,
co czyni go standardem.
Sekcja 3.2 (Składnia Rozszerzenia RFC 5322 ) uaktualnił większości pól tekstowych do
include (prawidłowego) 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.
Zwróć uwagę na wyraźne uwzględnienie domen.
I jawne wykluczenie nazw nagłówków .
Uwaga również na temat 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.
I zaczyna się sekcja 3 :
Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
Problem polega na tym, że niektóre klienty pocztowe (narzędzia serwera i / lub narzędzia pulpitu) nie obsługują tego i generują wyjątek „nieprawidłowy e-mail”, gdy próbujesz wysłać wiadomość na adres, który zawiera na przykład umlauty.
Jeśli potrzebujesz pełnego wsparcia, możesz załatwić sprawę, konwertując części adresu e-mail na „punycode”. Pozwala to użytkownikom na wpisywanie adresów w zwykły sposób, ale zapisujesz je na obsługiwanym poziomie.
Przykład: müller.com »xn--mller-kva.com
Oba wskazują na tę samą rzecz.
Jeszcze nie. IEEE planuje to zrobić: Artykuł w H-Online: IEFT planuje międzynarodowe adresy e-mail , tutaj jest RfC: rozszerzenie SMTP dla międzynarodowych adresów e-mail
Cytat z H-Online (jak spadł):
Internet Engineering Task Force (IETF) opublikował trzy kluczowe dokumenty dotyczące standaryzacji nagłówków adresów e-mail, które zawierają symbole spoza zestawu znaków ASCII. Oznacza to, że wkrótce będziesz mógł używać chińskich znaków, francuskich akcentów i niemieckich umlautów w adresach e-mail, a także w samej treści wiadomości. Jeśli więc nazywasz się Zoë i pracujesz dla firmy zajmującej się produkcją fasad, możesz być zainteresowany nowym adresem e-mail. Ale przedstawiciele dostawców już narzekają. Twierdzą, że musiałaby zaistnieć „mania aktualizacji”, gdyby standard Unicode UTF-8 miał zastąpić amerykański Standard Code for Information Interchange (ASCII) używany obecnie jako ogólny język e-maili.
RFC 5335 określa użycie UTF-8 w praktycznie wszystkich nagłówkach wiadomości e-mail. Konieczne byłoby wprowadzenie zmian w klientach SMTP, serwerach SMTP, agentach pocztowych (MUA), oprogramowaniu do list mailingowych, bramach do innych mediów i wszędzie tam, gdzie poczta jest przetwarzana lub przekazywana. RFC 5336 rozszerza protokół transportu poczty e-mail SMTP. Na poziomie protokołu rozszerzenie jest oznaczone jako UTF8SMTP.
Nowe pole nagłówka zostanie dodane jako rodzaj „spadochronu awaryjnego”, aby zapewnić, że wiadomości e-mail UTF-8 będą miały miękkie lądowanie, jeśli zostaną wyrzucone przed dotarciem do odbiorcy przez systemy, które nie zostały zaktualizowane. „OldAddress” to adres wyłącznie w formacie ASCII. Ale OldAddress nie może być używany jako kanał dla drugiej próby transferu, ale raczej do upewnienia się, że informacje zwrotne są wysyłane do domu.
Wreszcie, RFC5337 zapewnia, że wysyłane są prawidłowe komunikaty dotyczące statusu dostarczenia wiadomości e-mail innych niż ASCII. Prawidłowy adres nieosiągalnego adresata należy odesłać, nawet jeśli odmówiono dalszego transportu. Grupa robocza ds. Internacjonalizacji adresów e-mail (EAI) również pracuje nad szeregiem „mechanizmów obniżenia wersji” dla różnych pól nagłówka i koperty. Jeśli to możliwe, oryginalne informacje nagłówka należy „spakować” i zachować.
Niemiecka firma DeNIC, rejestrator domeny „.de”, jednak podchodzi do tego w spokoju. „Naprawdę niewiele możemy zrobić”, wyjaśnił rzecznik DeNIC Klaus Herzig. Zamiast tego DeNIC zwraca większą uwagę na aktualizację, nad którą pracuje IETF w zakresie standardu domen międzynarodowych - RFC3490 lub IDNA2003, jak się czasem nazywa. „Nie jesteśmy z tego powodu zadowoleni, ponieważ nie ma wstecznej kompatybilności” - wyjaśnił Herzig. Kiedy nadejdzie aktualizacja, DeNIC twierdzi, że będzie kładł nacisk na symbol „ß” - znany również jako estzett - który do tej pory był przeoczany. Niemiecki rejestrator mówi również, że może trochę poczekać przed przełączeniem ze względu na brak kompatybilności wstecznej.
Z drugiej strony eksperci uważają, że chińscy rejestratorzy w Chinach i na Tajwanie szybko wprowadzą zmianę w umiędzynarodowieniu poczty e-mail. Przedstawiciele CNIC i TWNIC są autorami standardów. Chińscy użytkownicy muszą obecnie pisać e-maile w ASCII po lewej stronie znaku @ i chińskimi znakami po jego prawej stronie w przypadku domen chińskich, które zostały już umiędzynarodowione.
(Monika Ermert)
Odpowiedź brzmi: tak, ale muszą być specjalnie zakodowane.
Popatrz na to . Przeczytaj część, która odnosi się do nagłówków wiadomości e-mail i RFC 2047.