Seit einigen Jahren habe ich mich daran gewöhnt, Dateianhänge mit Umlauten manuell nachbenennen zu müssen, weil mutt sie wie folgt zur Speicherung anbietet:
=?iso-8859-1?Q?Ma=DFnahmenplan_Qualit?= =?iso-8859-1?Q?=E4tsmanagement.docx?=
In einem Forum wurde mir damals beschieden, das Problem seien alle anderen E-Mail-Clients, die mit Anhängen nicht standardkonform umgingen.
Zufällig stoße ich heute auf einen vergleichsweise jungen Gitlab-Eintrag, in dem McCarthy en passant die Konfigurationsvariable rfc2047_parameters erwähnt, mit der sich das Problem sofort lösen lässt. Auf die konsternierte Rückfrage, warum dieser Parameter nicht standardmäßig gesetzt sei, bekräftigt er die slippery slope-Position der Entwicklerinnen:
Accepting garbage by default encourages the proliferation of non-standard emails and further decay of the standards. Some leniency is of course appropriate: thus the inclusion of the config variable, and for example commit 26bba6f9 which adjusted 2047 decoding to cope with non-compliant partitioning.
But usage of 2047 vs 2231 encoding is straight-forward, and has been for over 20 years. Roessler didn't think $rfc2047_parameters merited default on, and neither have subsequent Mutt committers. I'm not inclined to change it either.
A similar argument was attempted in ticket 60, in which a faulty client used 2047 encoding across the entire Message-ID header. The ticket there needed to be lodged with the faulty MUA, not Mutt, and I would say the same thing here.
Diese Vorlage für eine erregte Diskussion um den Grad adäquater leniency lasse ich aus Dankbarkeit für rfc2047_parameters ungenutzt.