On 2014-02-19 10:01, Paul J Stevens wrote:
On 18-02-14 17:58, Peter Milesson wrote:
With worked, I mean that Thunderbird displays messages when browsing
through the lists, that the attachment clips show up, that the
attachments are working, and that the folder tree is not corrupt.
As a one-off testing strategy that is perfectly valid, but I'd much
rather like to see the differences in IMAP response between a 'good'
gmime version, and a 'bad' one.
Thunderbirds FETCH command is not very complex:
x login username password
x select INBOX
x FETCH 1:* (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc
Subject Date Message-ID Priority X-Priority References Newsgroups
In-Reply-To Content-Type)])
x logout
stick this in a file:
cat > /tmp/testfetch.txt << EOF
x login username password
x select INBOX
x FETCH 1:* (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc
Subject Date Message-ID Priority X-Priority References Newsgroups
In-Reply-To Content-Type)])
x logout
EOF
and send it to dbmail:
cat /tmp/testfetch.txt |nc imapserver 143
if that works redirect output to a file:
cat /tmp/testfetch.txt |nc imapserver 143 > /tmp/out1.txt
If you do that for a good and a bad gmime version, you can diff the
output files which will give me a really good indication of what's going on.
Also, to verify TB behavior it might be a good idea to run TB in debug-mode:
cat > ~/debug_tb.sh << EOC
#!/bin/sh
MYDATE=`date "+%Y%m%d_%H%M%S"`
NSPR_LOG_MODULES=IMAP:5
NSPR_LOG_FILE=/tmp/thunderbird_${MYDATE}.log
export NSPR_LOG_MODULES NSPR_LOG_FILE
echo $NSPR_LOG_FILE
/usr/bin/thunderbird &
exit $?
EOC
chmod +x ~/debug_tb.sh
~/debug_tb.sh
if you run TB like that, it will create a massive logfile containing all
IMAP interaction. Don't keep it running like that for too long :-)
For one thing, above TB fetch command while opening a mail-folder might
have changed in your specific TB version, so we might want to validate
it. But I suspect it will produce enough information to proceed.
Hi Paul,
OK, I will do that. However, that must wait until the weekend. Customers
start to yell at me ;-).
Meanwhile, 3.0.2 is working well with gmime 2.6.9. Tried 3.1.10 again
with different gmime versions from the 2.6 series. With 3.1.10, gmime
version does not seem to have any impact on the (bad) function of
3.1.10. DBMail 3.1.10 with exactly the same database as for 3.0.2
creates a mixed salad of the message headers in the IMAP folders for any
gmime version tested.
Isn't there perhaps a short int, where there should be an int,
truncation creating the mix? The message ids in the database have long
ago exceeded 65535, which would be a plausible explanation...
Best regards,
Peter
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
