Limitation/rules for QP encoded words in email headers

I'm QP encoding (using RFC2047) the mail headers in outgoing emails (from my own application, sending data to SMTP servers)

This works quite well, but some clients do not properly display the results at the receiving end. They just run havoc, displaying the coding itself as addresses.

Troubleshooting, I realize that RFC2047 states that
- An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'

Is this the problem with my encoding?


When I have a "To" address list like this:
mailtest1@abcd.com;mailtest2@abcd.com;mailtest3@abcd.com;mailtest4@abcd.com;mailtest5@abcd.com

I encode that to:
To: =?iso-8859-1?Q?mailtest1@abcd.com;mailtest2@abcd.com;mailtest3@?=
 =?iso-8859-1?Q?abcd.com;mailtest4@abcd.com;mailtest5@abcd.com?=


It works very well with many clients, but some really do not like it.
Would you say that the above is in violation with RFC2047? How should it be encoded to be legal?

In the above example, the only reason for using encoded words is that the line gets too long.
Should I skip encoding completely in this situation, and just add more and more rows to the header? I probably thought (when once implementing this) that encoding was needed to get multi-line header rows...

And if so, how should a address list like this be encoded to be legal:
  mailtest1@abcd.com (a strange åäö name);mailtest2@abcd.com;mailtest3@abcd.com;mailtest4@abcd.com;mailtest5@abcd.com (another strange åäö name)

Any ideas?
Stefan LennerbrantAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
Plaintetext
john doe<johndoe@example.com>
Address specification
     addr-spec   =  local-part "@" domain        ; global address
This is what "Internet E-mail address" normally means. If you are asked to tell your E-mail address, this is what people want you to tell; they may add some comment-like stuff to it when they use it e.g. to send E-mail to you.
https://www.cs.tut.fi/~jkorpela/rfc/822addr.html
Stefan LennerbrantAuthor Commented:
Well, yes, that is an email address according to standard definition.
But the question is if there really is a limitation on how to encode this according to RFC2047.

The statement
  - An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'

implies that one CAN encode email addresses like:
To: =?iso-8859-1?Q?mailtest1@abcd.com;mailtest2@abcd.com;@?=
 =?iso-8859-1?Q?mailtest3abcd.com;mailtest4@abcd.com;mailtest5@abcd.com?=

but one CANNOT encode like this
To: =?iso-8859-1?Q?mailtest1@abcd.com;mailtest2@abcd.com;mailtest3@?=
 =?iso-8859-1?Q?abcd.com;mailtest4@abcd.com;mailtest5@abcd.com?=

However, both version runs havoc with many clients (like newer MSOffice Outlook versions - however Outlook 2010 handles both with out problems)

So, the question is what special considerations are needed when encoding email addresses.
Do note that, of course, an email address nowadays very well may look like strange-åäö-address@domain.com
David Johnson, CD, MVPOwnerCommented:
It is my understanding that email@domain.xxx is the address specification while
John Doe<email@domain.xxx> John Doe is not part of the address specification.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
David Johnson, CD, MVPOwnerCommented:
and yes the local part before the @ can be any series of characters as they are only interpreted by the system after the @ part this does not imply that they can be qp encoded
http://www.faqs.org/rfcs/rfc822.html
Stefan LennerbrantAuthor Commented:
Still, there are problems (in some clients) with QP-encoding the "name part", when it is too long to fit on one header row, and also great problems (in some klients) with the "address part" when it contains national characters and thus needs to be QP encoded.

But by just making sure that there are no line breaks within the "address part" (which is quite clearly stated in the RFC), everything works "good enough" in many clients, at least.

Some more investigation/work needs to be done, but... good enough for the moment :-)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Protocols

From novice to tech pro — start learning today.