Michael Monnerie wrote: > On Montag 16 Februar 2009 Mantis Bug Tracker wrote: >> For instance, one of them, write_addrspec function (which is used for >> From, To, and similar headers), parses header value, converts it to >> UTF-8, and then converts it back to the charset gmime thinks is best >> for this header (see internet-address.c and gmime-utils.c). > > Why? Mail comes via SMTP, and that headers are clearly ASCII. There are > no 8bit headers allowed. This makes problems with postfix. I discussed > that with Wietse Venema and Victor Duchovni (the 2 main devs), they > clearly stated that only ASCII is allowed (this was on the context that > I sometimes get errors when postfix connects to dbmail via an SQL > query).
Dbmail tries to handle 8bit data in the headers gracefully. But that is not the issue here. The problems lies with gmime. If you have a header say: Subject: =?utf-8?b?w6nDqcOp?= it's perfectly 7bit clean. However, when we start adding a From_ header to it during delivery, some (recent) versions of gmime will decode them internally (ok, fine), but then recode them as latin5 is something like that before giving them back like when we need a string representatation of a parsed message. We need a good mimeparser, but gmime is proving to be an moving target :-( >> The philosophical question: should dbmail treat the input message as >> something precious (and the only permitted action is inserting of >> additional message headers)? The alternative is to permit modifying >> the message form (for instance, header charset), but not the message >> value (meaning). > > I'd say never ever modify the mail (headers). That would be very bad > with SpamAssassin for example. I absolutely need the original mail in > order to feed it back to SA, to learn it. Exactly such spelling/coding > errors are generally a good sign for the difference of SPAM or HAM, so > it's really needed. > > If needed, add some only internally used headers, but always return the > original mail to the outside world. And that is exactly where the problem lies. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
