GNOME Bugzilla – Bug 310462
Mail is handled by the wrong Filter
Last modified: 2005-07-15 21:12:32 UTC
Distribution/Version: Debian SID I'm testing the maildir support of beagle. Some mail is handled (correctly) by FilterMail, but most of it is incorrectly handled by FilterText. The mime type of the incorrectly handled files is "plain/text". The files that are handled correctly ahave a mime type of message/rfc822; I couldn't find why there are mime type differences between different email messages - I'll be happy to learn about other steps to further debug this - I would especially be happy to learn how beagle identifies mime types. I can also send an example of the incorrectly identified emails. This was reproduced on both the CVS version and 0.12.
Do you see an [Email attachment] in Best next to the wrong identified mails?
*** Bug 310464 has been marked as a duplicate of this bug. ***
No, best doesn't show an email attachment. BTW, regarding bug 310464 - I don't think it's a duplicate of this bug. The problem here, is that some emails are NOT handled by FilterMail, but the problem in Bug 310464 is with those mails that ARE filtered by FilterMail (but still, are not marked as emails). Let me know if I'm wrong about this; I would like to know as much as I can about how beagle works with regards to maildir messages as I check it more thoroughly.
Beagle uses the GnomeVFS to detect mimetypes. If it's incorrectly identified the problem is probably with your mime-database and not Beagle. You can check how GnomeVFS identifies the file with by using the "gnomevfs-info" command.
You are right. gnomevfs-info identifies some Maildir mail files as "text/plain" and some as "message/rfc822". How can I investigate it further? This may be a showstopper for Maildir users (more mails are currently identified as 'text' than as 'messages'). Should I take it to the gnomevfs bugzilla? I should mention that I'm running KDE on Debian SID - $ dpkg -l | grep gnomevfs libgnomevfs2-0 2.10.1-5 libgnomevfs2-common 2.10.1-5 libgnomevfs2-dev 2.10.1-5 If there are any packages missing or version mismatches let me know.
Are the ones being reported as text/plain mbox-format files? That is, files which start with "From <blah blah blah>"? I ran into this when I was testing the new mail code recently, and I couldn't find any information about mimetypes for mbox-format files. So yeah, this should probably be filed against gnome-vfs.
No, the difference between the ones that are reported as text/plain and the ones that are identified as message/rfc822 is small - they are both files in the same mail folder, used by the same application (kmail). For example, a file that IS recognized correctly starts with: Return-Path: ... Where a file that is NOT recognized correctly, starts with: X-Virus-Flag: no Return-Path: ... and looks more-or-less the same after that. But I didn't investigate this seriously enough, so it may just be incidental. Should I go ahead and open a bug on the gnome-vfs bugzilla?
Ok, it is definitely because of the X-Virus-Flag. Most MIME sniffers, including both gnome-vfs and Apache assume that one of a few headers (like Return-Path) will begin an email. X-Virus-Flag isn't one of them. RFC 822 says that while headers don't have to be in a specified order, it is strongly recommended for reasons like this. The bug here really is in whatever program is setting X-Virus-Flag at the top of the file. It's behaving badly. You can open a bug against gnome-vfs, but I suspect it'll be closed WONTFIX. There's simply no way that a MIME sniffer can detect every possible header that could lead to a valid RFC 822 message. This is part of the reason why this convention exists, and the virus scanner should play nicely. Since this isn't a Beagle bug, I'm going to close it NOTGNOME.
Ok, that makes sense. I'll confirm your findings and let you know. If this is the solution, it's fine by me - but you might want to update the wiki to include a warning to kmail users - the application that adds this field is kmail_clamav.sh, the anti virus filter that is utilized by kmail's 'anti virus' wizard.