Re: status of Mail_mime?

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