FAQ
[in reply to borz_off@cs.msu.su, 31-12-2008]
The release will be pretty useless if it doesn't contain a fix for bug #11238:
http://pear.php.net/bugs/bug.php?id=11238
I agree, that bug is probably the worst open one and it should be fixed.
I spent a bit of time researching said bug and the fix will not be an easy one,
unfortunately. Essentially we'll need to add logic to parse "structured" headers
from RFC 822.
I agree with this also. I took an hour browsing the specs, and I am of the opinion that we should parse them fully before encoding. Anything less will go to waste, because sooner or later some user will encounter a corner case that we have not handled properly. There are simply too much obscure corner cases in the spec, e.g. comments, quoted names (containing chars like ',' or '<'), group names, escaping for people who really want to write things like =?bla?b?=, etc...
It won't need to be as complex as that in Mail_RFC822 class, but
we'll need to split the header value into lexical parts, as described in section
3.1.4 of said RFC and then encode (or not) these parts separately.
I feel otherwise. I do think we need to do it all and not stop at some string magic. In my opinion we should depend on Mail_RFC822 for working with address lists, rather than duplicatie its header-parsing logic either partly or more or less completely. Plus, the Mail package would be a natural dependency that I can't see inconveniencing many users.

For structured headers (From, To, Cc, Bcc, Sender, Resent-To, Resent-Cc, Resent-Bcc) we would parse the contents as well as possible and rebuild a properly encoded header.

The only thing that we would need to create, is a function to rebuild a (properly encoded) address list string from a Mail_RFC822::parseAddressList() result, which is not an intractable problem.

Now, in my opinion this function should ideally belong in the Mail_RFC822 class and not within Mail_Mime. Is a maintainer of Mail_RFC822 reading along? I'd be happy to add it there, but if releasing a new Mail_RFC822 is not possible, in the interest of speediness we might add it within Mail_Mime. This would however be less desirable from a design standpoint. Also, many people working with RFC822 address lists likely need to convert in both directions. So my wish would be to add to Mail_RFC822, then depend on it.
All the patches proposed so far do not follow this approach and thus fail to
comply to RFC 2047 (its section 5, in particular).
Yes, it's very easy to think of cases that would break the submitted patches. All in all, I'm not an advocate for doing a quick hack right now. This bug has been here for ages and I'd rather make a real solution, then put a new release into beta, then you (and others) can test it, and meanwhile we could try to coordinate with Mail_RFC822 maintainers to move the address list builder to the right place.

Comments?

Cheers (and a good 2009, of course)
WH

--
Walter Hop <walter@php.net> | http://www.lifeforms.nl/

Search Discussions

  • Alexey Borzov at Jan 2, 2009 at 6:19 pm
    Hi Walter,

    Walter Hop wrote:
    I spent a bit of time researching said bug and the fix will not be an easy one,
    unfortunately. Essentially we'll need to add logic to parse "structured" headers
    from RFC 822.
    I agree with this also. I took an hour browsing the specs, and I am of the opinion that we should parse them fully before encoding. Anything less will go to waste, because sooner or later some user will encounter a corner case that we have not handled properly. There are simply too much obscure corner cases in the spec, e.g. comments, quoted names (containing chars like ',' or '<'), group names, escaping for people who really want to write things like =?bla?b?=, etc...
    It won't need to be as complex as that in Mail_RFC822 class, but
    we'll need to split the header value into lexical parts, as described in section
    3.1.4 of said RFC and then encode (or not) these parts separately.
    I feel otherwise. I do think we need to do it all and not stop at some string magic. In my opinion we should depend on Mail_RFC822 for working with address lists, rather than duplicatie its header-parsing logic either partly or more or less completely. Plus, the Mail package would be a natural dependency that I can't see inconveniencing many users.
    Mail package is not-quite-maintained now and has its own share of open address
    parsing bugs: http://pear.php.net/bugs/bug.php?id=13659

    Though it is of course up to you as Mail_mime maintainer whether to depend on
    something...
    For structured headers (From, To, Cc, Bcc, Sender, Resent-To, Resent-Cc, Resent-Bcc) we would parse the contents as well as possible and rebuild a properly encoded header.

    The only thing that we would need to create, is a function to rebuild a (properly encoded) address list string from a Mail_RFC822::parseAddressList() result, which is not an intractable problem.
    The problem with current Mail_RFC822 implementation is that it does not use a
    tokenizer to split the header value, but some black regexp magic. It will be
    quite difficult to reconstruct the *original* header after it is processed.
    Now, in my opinion this function should ideally belong in the Mail_RFC822 class and not within Mail_Mime. Is a maintainer of Mail_RFC822 reading along? I'd be happy to add it there, but if releasing a new Mail_RFC822 is not possible, in the interest of speediness we might add it within Mail_Mime. This would however be less desirable from a design standpoint. Also, many people working with RFC822 address lists likely need to convert in both directions. So my wish would be to add to Mail_RFC822, then depend on it.
    This will essentially mean complete rewrite of Mail_RFC822, if you are so keen
    on doing it maybe you should consider a PHP5 version instead?
    This bug has been here for ages and I'd rather make a real solution, then put a new release into beta, then you (and others) can test it, and meanwhile we could try to coordinate with Mail_RFC822 maintainers to move the address list builder to the right place.
    Comments?
    I'm going to try implementing the fix for #11238 within Mail_mime class (with
    the approach outlined in my previous mail), will attach it to the bug once it is
    ready.

    Also, if I understand the RFC process correctly, we should support RFC 2822
    rather than RFC 822 as the former obsoletes the latter?

    Cheers (and a good 2009, of course)
    Happy New Year to you as well. :)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-qa @
categoriesphp
postedJan 1, '09 at 4:13p
activeJan 2, '09 at 6:19p
posts2
users2
websitepear.php.net

2 users in discussion

Walter Hop: 1 post Alexey Borzov: 1 post

People

Translate

site design / logo © 2022 Grokbase