Anton,
Could you please send me the testmessage below as a gzipped attachment. I'll try to reproduce the problem
you're seeing. I suspect there may be a problem with gmime's parsing of your koi8-r encoded from address which
triggers a bug in the old mimeparser still in use in the message retrieval chain.
I'd also like to see a trace level 5 of a dbmail-smtp insertion sequence.
more below...
Anton Nekhoroshikh wrote:
cat test.eml3 | ./dbmail-smtp -f /usr/local/dbmail.new/bin/dbmail.conf
-d [EMAIL PROTECTED]
cat test.eml3:
From: =?koi8-r?Q?=E1=CE=D4=CF=CE=20=EE=C5=C8=CF=D2=CF=DB=C9=C8=20?=<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: test
Content-Type: text/plain
test mail
cat /tmp/msg:
From:
=?koi8-r?Q?=E1=CE=D4=CF=CE=20=EE=C5=C8=CF=D2=CF=DB=C9=C8=20?=<[EMAIL
PROTECTED]
l.ru>
To: [EMAIL PROTECTED]
Subject: test
MIME-Version: 1.0
Content-Type: text/plain
test mail
----------------------------------
why differed messages?
The message insertion chain parses messages through gmime. This is done for splitting the message header from
the body, converting messages CRLF->LF, calculating rfcsize, building a hashtable of all headers, etc.
The gmime representation of the header is what explains the changes in the message header. These change
entail: rewrapping of long headerlines, cleaning up of mime-attribute quoting, and adding a MIME-Version
header when missing. All these changes should be well within the bounds set by relevant RFC's. If they are not
this means we hit a bug in gmime.
I'll get on this asap.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
