Wietse Venema via Postfix-users wrote in
<4yhffl6qs3zj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> Wietse Venema via Postfix-users wrote in
|> <4ygfy22qc4zj...@spike.porcupine.org>:
|>|The "full name" encoding for Postfix-generated From: headers is
|>|implemented. Code will be released after it has matured.
|>|
|>|Documentation:
|>|https://www.postfix.org/postconf.5.html#full_name_encoding_charset
|>
|> That is great news!
|>
|> (*I think and assumed*: actually 2231 is "it" to me from the
|> specification side
|
|RFC 2231 defines many things, but the only definition relevant for
|Postfix is the encoded-word syntax =?charset*lang?encoding?gibberish?='.
|This allows a recipient to determine the language of the sender's
|full name, which in turn can be used to pronounce that name correctly.
That RFC 2231 *lang extension for RFC 2047 i have never seen in
the wild. I personally think it is overengineering, and i would
not even know how to implement it given that iconv(3) does not
even give you the necessary information. Heck! It does not even
give you the normalized name for the character set as it had found
it internally once it was iconv_open(3)ed! (Worse, noone ever had
any interest to add such a possibility! Ie, for email, i MUST
know whether a character set actually is US-ASCII (it can be any
of "csascii", "cp367", "ibm367", "us", "iso646-us",
"iso_646.irv:1991", "ansi_x3.4-1986", "iso-ir-6",
"ansi_x3.4-1968", "ascii", "us-ascii", plus case mess) --
i finally have bitten the bullet, almost exactly a year ago, and
the next version of the MUA i maintain ships with a fully fledged
iconv DB, instead of having built-in resolving for ascii, latin-1
and utf-8 only.) It always drives me mad, you know. It *has* the
info -- it even used it! --, but it is a closed box and i will
never know.
Maybe a complete Unicode/CLDR environment, ICU that is, can be
used to make some sense of it. But no ICU in 1997 i would think
for one, and instead of "vision of a better future" i would as of
today put misconception on it. Never seen.
|If there is demand, then support for that syntax can be added later.
|Hint: I don't find any instances of such syntax in my email archive.
Oh! That is easy to get, you only need a non-US-ASCII attachment
filename. It seems you never sent an email with something like,
say, "A photo of our King, his Wife Máxima, and his Children", eg:
$ </dev/null s-nail -:/ -Smta=test \
-s "Oma's Knödelrezept!" -a Knödel-Rezept.txt a@b
..
Subject: Oma's =?utf-8?Q?Kn=C3=B6delrezept!?=
...
--=-=7yq34GyzMZUjiItykur8AxFk3JaV1Xow48Po=-=
Content-Disposition: attachment; filename*=utf-8''Kn%C3%B6del-Rezept.txt
Content-Type: text/plain; charset="us-ascii"
...
(Her potato-pancakes where best.) RFC 2231 is much better. Not
base64 or QP, _ for space, and what not.
Dependent upon the MUA(s) you (have) use(d) it could also be that
they have used RFC 2047 inside parameters falsely but on purpose;
some did that, mutt(1) has a config option to dig that even, my
one does this automatically since some time (looking for RFC 2047
syntax, .. but *could* be fooled, yet *that* *i* have never found
in practice; AH! Remembered something, and indeed, mutt has
enabled that by default in 2022:
Enable $rfc2047_parameters by default.
20+ years later, Mutt still gets bug reports about attachment names in
2047 encoded form.)
My one did produce them in earlier times. One more email
compatibility thing that needs to be transported forever, unless
you leave someone standing in the rain.
|> And N?UPAS of Plan9, that made/makes parts of emails available in
|> a virtual filesystem, for consumption of text tools like grep(1)
|> etc, but again, that is layered, too. message/global, really not.)
|
|With FUSE, anyone with sufficient skill and motivation can implement
|a filesystem interface to access arbitrary parts from email messages.
That is true. No interest from the nmh guys in this regard. (The
nmh mailer offers programs which access email content like so,
but, as they are normal UNIX programs, they have to process the
data over and over again, and i once talked N?UPAS on their list.
If i recall that correctly.) I am on the long road with the MUA
i maintain to come to some kind of client/server thing that could
be used, but it is, of course, not as simple as doing a grep(1) on
a virtual filesystem as in, hypothetic, mail/*/headers/subject or
what. But i am afraid all this is off-topic for postfix,
including RFC 2231! Great that you have added RFC 2047 support!
A merry christmas to all christians! (That guy threw the dealers
out of the temple and went for something else than money -- such
a fool!!)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
