555 5.5.4 Unsupported option: SMTPUTF8

Lord_Icon

Member
Moin,

ich müsste eine Mail an jm. senden, der ein Umlaut (***-golßen@domain.de) in der Domain hat.

Leider verlässt die Mail nicht mein Outlook.
Ich bekomme zurück:
Code:
Fehler (0x800CCC78) beim Ausführen der Aufgabe "info@meine-domain.de - Nachrichten werden gesendet": "Die Nachricht kann nicht gesendet werden. Überprüfen Sie die E-Mail-Adresse in den Kontoeigenschaften. Antwort des Servers: 555 5.5.4 Unsupported option: SMTPUTF8"

Lt. Google soll man in der main.cf folgendes eintragen
Code:
smtputf8_enable = yes
Nur sagt mir postfix nach einen reload:
Code:
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: smtputf8_enable=yes
postfix/postfix-script: refreshing the Postfix mail system

Weitere Foren-Einträge schlugen ander Lösungen vor, die aber auch nicht akzeptiert werden.
Code:
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: enable_idna2003_compatibility=yes
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: smtputf8_enable=yes
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: smtputf8_autodetect_classes=sendmail, verify
postfix/postfix-script: refreshing the Postfix mail system

Mein System lautet:
Debian 7.9
mail_version = 2.9.6


Weiß einer Rat ob die Befehle erst in späteren Versionen (aktuell ist ja 2.10) akzeptiert wird? die manpage von postfix schweigt sich über die Version aus.

Danke für Hilfen/Ratschläge
 
Dann müsste ja auch diese E-Mail-Adresse gehen: 猫@狗.我爱你
Die tld gibt es und bedeutet: "I love you"
 
MS Outlook kann keine Punycode-kodierten Zeichen in die Mailadresse setzen?
Postfix kann Mailadressen mit solchen Zeichen empfangen.
 
Last edited by a moderator:
Outlook.com hat eigene Ideen was erlaubt ist und sperrt schon mal ein Konto als Verdächtig, wenn Umlaute im local-part der Mailadresse existieren und diese Mail abgewiesen wurde.

Kann ich also nicht testen.
 
Geht nicht :-(
Thunderbird
 

Attachments

  • thunderbird_ascii.png
    thunderbird_ascii.png
    19.9 KB · Views: 1,036
Also merke: E-Mail Adressen mit Umlauten sollten gemieden werden, sofern man etwas anderes als Spam bekommen möchte.
 
E-Mail Adressen mit Umlauten sollten gemieden werden, (...)
Warum meiden? Erklärung?

man etwas anderes als Spam bekommen möchte
Was haben local-parts und Nicht-Ascii-zeichen mit Spam zu tun? Was soll Spam in diesem Zusammenhang mit Punycode zu tun haben? Erklärung?
 
Last edited by a moderator:
Wenn schon die E-Mail Programme selbst Probleme mit UTF-8 im Namensteil haben, der Punnycode auch nicht überall richtig funktioniert und der Anbieter das auch noch unterstützen muss (Postfix mit UTF8), lässt sich daraus folgern, dass auch weniger Menschen in der Lage sind E-Mails an diese Adresse zu versenden. Somit grenzt man automatisch Menschen aus, die z.B. ein E-Mail Programm wie ich haben. Ich hatte das Problem bereits einmal und es raubte mir meine Zeit. Es wäre zwar schön, wenn jedes E-Mail Programm diesen Standard unterstützen würde, aber offensichtlich ist es nicht so. Die Spamer werden sicherlich mit Umlautdomains und UTF8 im Namensteil der E-Mail Adresse ihre Erfahrungen haben. Wenigstens kommt der Spam dann an.
 
Dass Thunderbird es nicht kann, zeigt dass OpenSource nicht immer was taugt, nur für begrenzes Zeilgruppen ist, Probleme jahrelang ignoriert werden oder es ein Definitionschaos bei den Entwicklern gibt.

Was ich schon seltsam finde, dass es überhaupt Programme gibt, die Punycode nicht beherrschen. Die RFC zu Punycode existiert seit 2003. Das wurde doch erfunden, damit IDN klappt. Und IDN-Domains existieren auch seit 2010. Und Email Address Internationalization (eai) sollte doch auch dann laufen.
https://datatracker.ietf.org/wg/eai/documents/

Was solls. Wahrscheinlich liege ich falsch damit, das globale Mails nicht nur US-amerikanische Zeichen können sollen.

Dass reines 8bit UTF nicht klappt in Headern mag gerade noch angehen, aber dass Punycode von manchen Clients und Servern verweigert wird ist eher 70er-Jahre.
 
Last edited by a moderator:
IDN soll der Thunderbird können: ascii@IDN.IDN

Komplizierter ist es mit utf8@IDN.IDN
Das kann der Thunderbird wohl immer noch nicht.

So ist das nun mal mit den Standards. Manche werden unterstützt und andere werden auf Teufel komm raus einfach nicht implementiert. Manchmal nervt es schon gewaltig, dass die Mozilla-Entwickler solche Sturrköpfe sind. Outlook weigere ich mich prinzipiell zu nutzen.

Ich hab jetzt auch noch nicht so ganz verstanden, ob der E-Mail Client die Domain jetzt nach idna encodiert und dann übergibt oder ob der Postfix das selbst macht. Egal wie man es jetzt dreht, es sind zwei unterschiedliche Codierungen.

Letztendlich geht es in dem Thread ja um Teil vor dem @ und das der Postfix die Regel anscheinend nicht zuordnen kann, was vielleicht an der Version liegt. (um mal auf den Ursprung des Threads zu verweisen)

Hier nochmal der Link: http://www.postfix.org/SMTPUTF8_README.html

Support ab Version 3.0
 
Ungeachtet dessen, was Standards erlauben oder was in Software implementiert ist, sind Nicht-ASCII-Zeichen grundsätzlich schonmal für all diejenigen doof die diese Adresse eintippen müssen, aber die entsprechenden Zeichen nicht auf ihrer Tastatur haben.
Schon alleine dafür sollte man einfach immer eine transliterierte Variante der Adresse anbieten.

Und OT: Realistisch betrachtet ist das ß kein Umlaut sondern eine Ligatur ;)
 
ich müsste eine Mail an jm. senden, der ein Umlaut (***-golßen@domain.de) in der Domain hat.
Ist Dir bekannt, ob die E-Mailadresse bereits lange im Einsatz ist?
Mit der E-Mailadresse dürfte es doch dauernd Ärger im Alltag geben.

Der Hype mit den Sonderzeichen in Domains ist ja auch schnell verebbt.
Wo es dann x verschiedene Zeichen gab, die alle auf einem kleinen Screen gleich aussahen (ö,ö und ö waren dann unterschiedliche Buchstaben und damit auch unterschiedliche Domains). Dann gab es Domains wie microsoft mit falschem o. Als das Mode bei Betrügern wurde, wurden die Domainnamen bei Firefox direkt in xn--punycode angezeigt. Damit waren die Domains dann doch nicht mehr so attraktiv.

Sobald E-Mails sauber mit allen Zeichen laufen, wird das auch wieder eine Welle von Betrug geben.
 
Non-ASCII localparts sind seit wann genau erst erlaubt?
Und wer ausser Postfix >= 3.0 hat es bisher implementiert?

IDNA2003 oder IDNA2008? Siehe aktuelle curl Diskussion...
 
Back
Top