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 

  To: undisclosed-recipients:;

You will just get:


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.


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

Reply via email to