Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Another one for the TIdMessage decoder...


This question is answered.


Permlink Replies: 1 - Last Post: Dec 28, 2016 10:56 AM Last Post By: Remy Lebeau (Te... Threads: [ Previous | Next ]
John May

Posts: 81
Registered: 6/25/10
Another one for the TIdMessage decoder...  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 27, 2016 10:39 AM
This header line (which is part of more complete email but the rest is not relevant really) is supposed to be decoded as "תעודת חובה"

From: "=?utf-8?Q?=D7=9E=D7=95=D7=A7=D7=93
 =D7=97=D7=91=D7=A8-=D7=90=D7=9C=D7=95=D7=9F?="
	<aaa@bbb.ccc>


Indy does not decode such header properly. I tested decoding in the usual batch of email clients - Outlook, Windows Live Mail, Gmail webmail... they all handle the From: properly and display correct text above.

May I offer a suggestion to fix this? First merge the split lines (folded lines), and then do the decoding of the content? Looks like Indy currently first decodes and then merges the lines. As other email clients do the opposite they get it correctly.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Another one for the TIdMessage decoder... [Edit]
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 28, 2016 10:56 AM   in response to: John May in response to: John May
John wrote:

This header line (which is part of more complete email but the rest is
not relevant really) is supposed to be decoded as "תעודת חובה"

Actually, it decodes as this instead:

מוקדחבר-אלון

But either way, the header you have shown is malformed.

Indy does not decode such header properly.

Nor should it, per the MIME specs.

I tested decoding in the usual batch of email clients - Outlook,
Windows Live Mail, Gmail webmail... they all handle the From:
properly and display correct text above.

Then they are chosing to ignore the malformedness. Indy does not.

May I offer a suggestion to fix this? First merge the split lines
(folded lines), and then do the decoding of the content?

Indy already unfolds the lines first before then decoding the content. That
is not the problem.

The real problem is the folding itself. When a header field is MIME-encoded
per RFC 2047, an encoded-word is not allowed to be folded mid-data, but your
header is doing exactly that. Folding can occur between two separate encoded-words,
but cannot occur inside of a given encoded-word. An encoded-word is designed
to be treated as a self-contained atom when processed in its encoded form.
During the unfolding process (which is handled by TIdHeaderList before DecodeHeader()
is called), the #13#10#32 sequence used between the first 2 lines gets converted
into a single #32 space character. That behavior is dictated by RFCs 822/2822/5322.
But, that space character then breaks MIME decoding of the encoded-word,
as unencoded whitespace is not allowed inside of an encoded-word. This is
very clearly stated in several areas of RFC 2047. Since your encoded-word
uses quoted-printable encoding, any whitespace within the content should
have been encoded as '=20' instead of being folded illegally.

Had your content been encoded/folded correctly by the sender, Indy would
have decoded it just fine.

Looks like Indy currently first decodes and then merges the lines.

No, it does the opposite.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02