Re[2]: [PEAR-DEV] status of Mail_mime?

[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/