* p...@cpan.org [2016-09-18T11:40:53] > Currently passing string values of From/To/Cc/Bcc/... headers into > header_str() method is broken in Email::MIME. That is because > Email::MIME currently uses Email::Address for generating those header > values (which is broken) and then MIME encode those broken outputs. > > Email::Address::XS has (looks like) correctly implemented formatter and > so it is needed to correctly MIME encode From/To/Cc/Bcc headers.
I suggest making Email::MIME use Email::Address::XS if it is available, and adding Email::Address::XS to the recommended prereqs of Email::MIME. The right behavior will be easy to get, and usually be installed, but it will be possible to proceed with less correct behavior if you haven't got a compiler (for some sad reason). Part of the question is: how wrong do things go, in what circumstances, if Email::Address is substituted for Email::Address::XS. > As compromise could be: Whole Email::MIME will not depends on module > Email::Address::XS. But if somebody want to pass Unicode string (via > header_str) to Email::MIME then MIME encoding will be done via > Email::MIME::Header::AddressList (which will use Email::Address::XS). So > if caller encodes manually From/To/Cc/... headers and pass them via > header_raw() then Email::Address::XS will not be needed. Specifically, I think, a non-ASCII string. I'm guessing that most/many users are really just passing in fixed ASCII strings, so this rule wouldn't affect them at all. Users passing in non-ASCII would start getting a "automatic encoding of non-ASCII $field header requires ...." error. Seems okay. > And can be Email::MIME::Header::AddressList part of Email-MIME > distribution (even if only this module will depends on XS)? I guess so. We need to mark this stuff experimental for a while, I think, too. -- rjbs
signature.asc
Description: Digital signature
