* 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.


Attachment: signature.asc
Description: Digital signature

Reply via email to