On Wednesday 28 September 2016 15:29:28 Ricardo Signes wrote: > * 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.
First problem is CVE-2015-7686. If you pass "unsafe" string into Email::Address then perl starts eating CPU for a very long period. Next problem with Email::Address is that it eats names of email groups. Which means that if you ask or pass MIME-decoded string version of raw header: To: undisclosed-recipients:; You will just get: To: Another problem is parsing name/phrase which have MIME encoded string which "looks like" an email address. E.g. for MIME header: To: =?UTF-8?B?PG15Pg==?= <addr...@host.com> You will get MIME-decoded string: To: <my@name>, <addr...@host.com> Because just of first problem CVE-2015-7686, I would really suggest to totally avoid using Email::Address. If you process "unsafe" email from attacker on some server, you get perfect DOS attack. I think that returning original header (not MIME decoded) or croaking is better then using Email::Address. > > 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. Ok. > > 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. No problem. I think now we discussed everything needed... I will implement patches for Email::MIME and will see how it is usable and how it is working...
