The displaying of the message in Outlook is broken. The users don't

really care who's fault it is... they just see the fact that their

mails sometimes sometimes look wrong in Outlook and are unhappy.
Hey, I am a big fan of open-source, you don't need to try to

convince me... I just would like to provide the best possible

service to my users, so, if I could fix the fact that their mails a

sometimes displayed incorrectly in Outlook, that would be great.
OK... I'll have a look at the code and try to fix it myself. Would

you be interested in a patch or is the redability of the raw encoded

string to you preferable to IMP users being able to send mails to

Outlook users in a way that the mails are displayed correctly?



Cheers

David

AAAAGGH! FUD!  Please tell me exactly *WHAT* is broken?  The fact that 
we encode exactly as the RFC tells us we can?  The fact that *every* 
other mail reader handles the message correctly?  So a program that we 
have no control over is not handling the message correctly?



Furthermore, looking at the header text, this has absolutely *nothing* 
to do with MIME encoding.  it looks as if Outlook is broken when it 
comes to handling RFC 2822 headers, specifically section 2.2.3.  in 
your example, we are splitting a line between two non-encoded words.   
MIME encoding rules should not be used at all when rebuilding the line 
in this case!  Outlook apparently tries to use MIME encoding wrapping 
rules to unwrap the line once it spots MIME encoding _somewhere in the 
header_.  I don't know for sure since microsoft isnt showing us the 
code.  but there is *no* doubt this is wrong behavior.  we are not 
going to "fix" anything BECAUSE THERE IS NOTHING TO FIX! (despite your 
unsubstantiated claim we are using this as an "excuse")

That's the latest version: Outlook 2003 SP2. Are other Outlook 
versions behaving differently? Outlook is used by a lot of people... 
It is certainly not a good thought for our customers to know that 
their mails will not be displayed correctly on one of the most used 
mail user agents.
This seems to me more like an excuse because you don't want to fix, 
which is fine, but don't say that it is unfixeable...



Cheers

David

Yes because your version of outlook is *broken*.  Nothing we can do 
about this (encoding the way you describe does not fix the problem 
either, not to mention that encoding it that way has no guarantee it 
would work in all cases).

Unfortunately, that's not what Outlook is doing. Have a look at the 
attached screenshot.
I agree with you that this is probably a bug in Outlook, but is it 
possible to implement a workaround in IMP? I can't fix Outlook...

Thanks
David

Yes, and this is perfectly acceptable.  It is how you break a MIME 
Header.  The MUA should convert all newlines and leading white space 
in a header to a single space.

Correct.
No, this is not what the RFC says.  The RFC says *if* you put a 
newline between two encoded words, then the space is ignored.  So it 
allows you to

break in the middle of a word, for example, if that encoded word would 
cause the line to exceed 78 characters (plus CRLF) in length.   
However, there is no requirement to break a line this way.
It looks like mutt uses a different, less complex algorithim.  They 
encode spaces within the encoded string using '_'.  IMP (actually 
Horde) only encodes spaces when two consecutive words both contain 
characters that require encoding.



This results in (at least in my opinion) easier strings to read when 
the string is unencoded (i.e. viewing the message source).  The IMP 
string of:

   Infos =?iso-8859-1?b?/GJlcg==?= kIZ =?iso-8859-1?b?Zvxy?= die Nightline

is logically viewed by me as

   Infos <some encoded word> klZ <some encoded word> die Nightline



While the mutt way of doing things:

Infos =?iso-8859-1?Q?=FCber_kIZ_f=FC?= =?iso-8859-1?Q?r?= die Nightline

is logically viewed by me as:

   Infos <some encoded word> <some encoded word> die Nightline



The 'klZ' in the mutt example is completely lost in the encoded stuff.



Long story short - both ways of encoding are correct according to the 
RFCs.  So if your mail reader is entering extra spaces between words 
with either encoding, then your mail reader is broken.

When I write a new mail with umlaut characters in the subject, 
sometimes spaces seem to be missing because the subjects seems to be 
wrongly encoded. For example with:



Subject: Infos über kIZ für die Nightline



IMP encodes it as:



Subject: Infos =?iso-8859-1?b?/GJlcg==?= kIZ =?iso-8859-1?b?Zvxy?= die

         Nightline



Note that before "Nightline" there is a new-line and a tab.



In RFC2047 it is written:





    When displaying a particular header field that contains multiple

    'encoded-word's, any 'linear-white-space' that separates a pair of

    adjacent 'encoded-word's is ignored.  (This is to allow the use of

    multiple 'encoded-word's to represent long strings of unencoded text,

    without having to separate 'encoded-word's where spaces occur in the

    unencoded text.)



That is, I think that you need to put the newline between two encoded 
words, so that the newline is ignored. Mutt does encode the same 
subject like this:



Subject: Infos =?iso-8859-1?Q?=FCber_kIZ_f=FC?=

         =?iso-8859-1?Q?r?= die Nightline



Cheers

David