Indeed, headers look like:
Guys, what is it ? Hiiw can i turn it off and get standard base64
1) they problem was fixed
2) even on non-fixed versions user had an option to turn it to compatible
Again, Opera introduced dangerous defaut settings twist, that changes w/o
alerting user and damages his work.
This is the standard way (RFC 2231) to encode international
(non-english/american) filenames. It is triggered when any character that is
(essentially) not in the ranges a-z, A-Z, 0-9, "-", "+" and "_".
If the receiving client does not understand it (that is, its email decoding
engine is too old) it will not display a name.
I am afraid that there are only two ways to avoid the no-name problem:
1) Your contacts can upgrade to an email client (or webmail service) supporting
RFC 2231 (an 11 year old standard, supported in Opera since v6.0, when we
started to support Unicode, IIRC)
2) you can restrict your filenames to the above mentioned characters in
The third choice, of course, is to live with it, or perhaps compress the files
into archives with names that does not trigger the internationalized name
Sorry, but those are the choices, as RFC2231 is not compatible with the older
and worse (hacked-together) ways to indicate the filename (and it is impossible
to make sure the name comes out right in those methods), and it is not possible
to send both alternatives.
RFC 2231: http://www.ietf.org/rfc/rfc2231.txt
There is no new version of Outlook Express. You might hate it, still it is
> 2) you can restrict your filenames to the above mentioned characters in
The link at Mozillazine claims problem is with long name, not with
> Sorry, but those are the choices, and it is not possible to send both
But it is possible to choose one.
You might give user to choose.
You might have knowledge of MUA's and use it when replying and cache it in
Contacts for new messages w/o parent.
Currently it looks like "after one Opera update it all suddenly stopped to
> RFC 2231: http://www.ietf.org/rfc/rfc2231.txt
Looking in http://www.ietf.org/iesg/1rfc_index.txt
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text. K. Moore. November 1996.
(Format: TXT=33262 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations. N. Freed, K. Moore. November 1997.
(Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045,
RFC2047, RFC2183) (Status: PROPOSED STANDARD)
[other RFCs say "Status: STANDARD"]
Which "standards" are _the_ "standards" (if any?)
> There is no new version of Outlook Express.
> You might hate it, still it is in use.
"Windows Mail" and "Windows Live Mail"
are the updated versions of Outlook Express.
Many changes (different mailboxes and other stored file formats,
"Identities" replaced by a column of different accounts,
which looks a bit like Thunderbird).
http://download.live.com/wlmail [later still, huge "complete" download]
No idea about RFC support changes.
The IETF have 3 levels of standard matrity for RFCs, plus several other
non-standard levels (like experimental and informational). See
"Proposed standard" is the first level of a standard, used for the first version
of a specification of some significance that has (primarily) come out of a
Working Group with a consensus behind it. They can have some rough egdes,
"Draft Standard" is the more polished, mature version of a "proposed standard",
after implementation experience has been gathered.
"Standard" or "Internet Standard" is the most mature documents that have been
stable for a long time, and which have been polished to shining gleam.
RFC 2045-2049 are at the middle maturity level, where most RFCs in use exist;
there are relatively few at the Full standard level. (even TLS is still at the
RFC2231 is an update of 2045&co, which was needed because 2045&co cannot handle
internationalized text in headers properly (IOW, they weren't fully defined) .
RFC2047 can handle some of it, but not in parameters values, and it is forbidden
to use those methods in Content-* headers:
An 'encoded-word' MUST NOT be used in parameter of a MIME
Content-Type or Content-Disposition field, or in any structured
field body except within a 'comment' or 'phrase'.
That is, 2047 can be used to encode a Japanese Subject header, but not a Japanse
> The IETF have 3 levels of standard matrity for RFCs, plus several other
> non-standard levels (like experimental and informational). See
Thank you for the link and info.
Not tested them. Windows Mail is not installable on XP.
WLM... don't know yet.
Tested Live Mail on XP.
Nothing changed with respect to this RFC.
"Windows Mail" sucks badly comparing with OE.
That's why MS opened (again) POP3 support for Hotmail.
(still using OE)
both do, comparing to Fidolook
> (still using OE)
pure OE ???
I tried helluva lot of other programs, but was not satisfied with any.
Some do not like cyrillic, some are just mailers (no Usenet support), some are just awful ;)
So it's OE in the end (using POP3 instead of IMAP everywhere - for better filtering).
Fidolook.org us enhancement over OE.
And it's current maintainer is one of Miranda IM co-devels :-)
It was crucial when the only place of topical discussions in ru-net was
Still it gives quite a number of features to OE.
However, with demise of FIDO, NNTP and OE, it fallen out of favour now.
There are almost no active users left, except for China :-)