Front page | perl.pep |
Postings from September 2016
From: Ricardo Signes
September 28, 2016 13:29
Message ID: 20160928132928.GA25781@debian
* email@example.com [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.