James Cloos wrote: > I just had another hit of this as well. (In my case I use procmail to > do the filtering, with a non-dbmail fallback folder so nothing is lost.) > > Here is the output from dbmail-smtp which procmail logged followed by > the message as it was stored by procmail (with a dir/. style recipe):
<snip extensive logs> > ,---- > | To: =?utf-8?Q?Jos=E9_M=2E_Mart=EDn?= <[EMAIL PROTECTED]> > `---- > > Note how it claims to be utf-8 but includes latin1 data. bugger. > That is the same issue I added to the bug report some time back. > (IIRC, I saw a resolved/closed notice for that report hit this > list recently, yes?) I'm not sure what bug you refer to. But recently more related issues have popped up. In most cases it concerns the more general problem of dealing with garbage input gracefully. Since the whole of the insertion chain is wrapped in a single transaction however, any failure will lead to a total cop-out. We should perhaps add a degraded insertion mode, where failure in the header caching (with it's inherent sensitivity to encoding related issues) leads to incomplete but functional insertion. The message would then be inserted fully, in the right mailbox with the correct flags etc, but be (partly) inaccessible to imap-searches and fetches (no problems in pop3 retrieval). But if we do that (major change) the sender would not have received a bounce message, while the recipient would not be guaranteed to be able to actually see the message in all imap clients. But I havent given up on getting the recoding of all headers running smoothly. > I'm on the 2_2 branch at revision 2795. I've looked at the diff > for rev 2799, but can't tell whether that would fix this issue. > Will dbmail_iconv_decode_text do the right thing if the header > claims one encoding but actually uses another? dbmail_iconv_decode_text is just my current entry point for dealing with the issues involved. It's not such a very complex issue in the end, but it does need to be fully thought through. I'm already working on more refactorings in that code using Marc's and other people's reports to build up more test cases. That is also were I expect your example to end up as well. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
