[Dovecot] Thunderbird 1.5 and messages with no Date: header
hi,
some of my Thunderbird users have a minor but annoying problem with messages that have no Date: header.
these clients use BODY[HEADER.FIELDS (Date)] as the date for messages. when a message has no Date: header, they display the date as 01/01/1970 10:00:00 because Dovecot returns empty string.
would it be possible for Dovecot to return INTERNALDATE instead, for messages that contain no Date: header? I know this is not *technically* correct, but it's a reasonable best-guess, and better than returning nothing. perhaps as a client-workaround?
I vaguely recalled a previous message about this, but I couldn't find it today.
grant.
grant beattie wrote:
some of my Thunderbird users have a minor but annoying problem with messages that have no Date: header.
these clients use BODY[HEADER.FIELDS (Date)] as the date for messages. when a message has no Date: header, they display the date as 01/01/1970 10:00:00 because Dovecot returns empty string.
would it be possible for Dovecot to return INTERNALDATE instead, for messages that contain no Date: header? I know this is not *technically* correct, but it's a reasonable best-guess, and better than returning nothing. perhaps as a client-workaround?
Isn't it better to fix the MUA in question? Returning another value than the one present in the header structure would break RFC 3501, IMHO.
Anyway, the Date header should be fixed/added by MTA (haven't read RFC2822 but the ENVELOPE desription in 3501 seems to confirm my interpretation).
Anyway #2, assuming that the message hasn't arrived via SMTP (as the MTA would fix/add the Date header unless it's broken) and probably also not via COPY or APPEND, I'm not sure how would INTERNALDATE help you - if I'm reading the specification correctly, the behaviour is implementation-defined in other cases :)
So in short, is there a report in Thunderbird's bug tracker?
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Fri, May 19, 2006 at 01:08:03PM +0200, Jan Kundrát wrote:
would it be possible for Dovecot to return INTERNALDATE instead, for messages that contain no Date: header? I know this is not *technically* correct, but it's a reasonable best-guess, and better than returning nothing. perhaps as a client-workaround?
Isn't it better to fix the MUA in question? Returning another value than the one present in the header structure would break RFC 3501, IMHO.
Anyway, the Date header should be fixed/added by MTA (haven't read RFC2822 but the ENVELOPE desription in 3501 seems to confirm my interpretation).
Anyway #2, assuming that the message hasn't arrived via SMTP (as the MTA would fix/add the Date header unless it's broken) and probably also not via COPY or APPEND, I'm not sure how would INTERNALDATE help you - if I'm reading the specification correctly, the behaviour is implementation-defined in other cases :)
using INTERNALDATE instead, in this special-case workaround, would mean that messages don't show up with a zero date - and yes, it would help a lot. these are messages that are arriving via SMTP, so INTERNALDATE would represent the date that the message was delivered to the destination mailbox.
I completely agree it would be better to fix the MUA, but what's out there right now is broken, and a workaround for a broken client is better than no workaround at all.
So in short, is there a report in Thunderbird's bug tracker?
I don't know, I haven't checked yet. but that won't magically fix existing clients that are in widespread use.
grant.
grant beattie wrote:
using INTERNALDATE instead, in this special-case workaround, would mean that messages don't show up with a zero date - and yes, it would help a lot. these are messages that are arriving via SMTP, so INTERNALDATE would represent the date that the message was delivered to the destination mailbox.
Well, fixing your SMTP's delivery agent to include the Date header seems better to me. Is there anything preventing you from doing that?
Current Dovecot's behaviour seems correct (according to the RFC 3501).
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Fri, May 19, 2006 at 03:16:57PM +0200, Jan Kundrát wrote:
using INTERNALDATE instead, in this special-case workaround, would mean that messages don't show up with a zero date - and yes, it would help a lot. these are messages that are arriving via SMTP, so INTERNALDATE would represent the date that the message was delivered to the destination mailbox.
Well, fixing your SMTP's delivery agent to include the Date header seems better to me. Is there anything preventing you from doing that?
the MTA (Exim) is configured to always add the Delivery-Date: header, and I'm sure I can make it add a missing Date: header.
but again, it doesn't fix it for all possible cases of where this problem might occur (different MTAs, configurations, etc.) if we acknowledge that the client is broken, and a suitable workaround is possible, I don't think implementing it as a client-workaround would be a bad thing.
Current Dovecot's behaviour seems correct (according to the RFC 3501).
indeed. but how many perfectly RFC IMAP clients do you know of? afaik, there aren't any? :)
grant.
grant beattie wrote:
the MTA (Exim) is configured to always add the Delivery-Date: header, and I'm sure I can make it add a missing Date: header.
but again, it doesn't fix it for all possible cases of where this problem might occur (different MTAs, configurations, etc.) if we acknowledge that the client is broken, and a suitable workaround is possible, I don't think implementing it as a client-workaround would be a bad thing.
If the incoming message doesn't contain the Date header, it isn't valid. Your MDA doesn't conform the the RFC 2822, IMHO.
Current Dovecot's behaviour seems correct (according to the RFC 3501).
indeed. but how many perfectly RFC IMAP clients do you know of? afaik, there aren't any? :)
I'm writing one :)
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Tue, May 23, 2006 at 08:42:03PM +0200, Jan Kundrát wrote:
but again, it doesn't fix it for all possible cases of where this problem might occur (different MTAs, configurations, etc.) if we acknowledge that the client is broken, and a suitable workaround is possible, I don't think implementing it as a client-workaround would be a bad thing.
If the incoming message doesn't contain the Date header, it isn't valid. Your MDA doesn't conform the the RFC 2822, IMHO.
indeed, however, we get too much mail that has no Date: header for it to be realistic to reject them. upon investigating, Exim has no out-of-the-box way to add a missing Date: header, though I can craft a configuration to do it.
the reason for asking for a way to implement this workaround in Dovecot is so that existing messages and MUAs can "just work".
Current Dovecot's behaviour seems correct (according to the RFC 3501).
indeed. but how many perfectly RFC IMAP clients do you know of? afaik, there aren't any? :)
I'm writing one :)
:)
g.
grant beattie wrote:
On Tue, May 23, 2006 at 08:42:03PM +0200, Jan Kundrát wrote:
but again, it doesn't fix it for all possible cases of where this problem might occur (different MTAs, configurations, etc.) if we acknowledge that the client is broken, and a suitable workaround is possible, I don't think implementing it as a client-workaround would be a bad thing.
If the incoming message doesn't contain the Date header, it isn't valid. Your MDA doesn't conform the the RFC 2822, IMHO.
indeed, however, we get too much mail that has no Date: header for it to be realistic to reject them. upon investigating, Exim has no out-of-the-box way to add a missing Date: header, though I can craft a configuration to do it.
the reason for asking for a way to implement this workaround in Dovecot is so that existing messages and MUAs can "just work".
why not switch to Postfix? I am surprised Exim doesnt do this. is it not that popular an MTA?
grant beattie escribió:
On Tue, May 23, 2006 at 08:42:03PM +0200, Jan Kundrát wrote:
If the incoming message doesn't contain the Date header, it isn't valid. Your MDA doesn't conform the the RFC 2822, IMHO.
indeed, however, we get too much mail that has no Date: header for it to be realistic to reject them. upon investigating, Exim has no out-of-the-box way to add a missing Date: header, though I can craft a configuration to do it.
Exim will do it for you with out of the box capabilities. Add to your data acl:
warn add_header = Date: $tod_full condition = ${if !def:h_Date: {1}}
Of course you can add the header only to locally generated messages or whatever, but that's a exim-users topic.
Regards,
Angel Marin http://anmar.eu.org/
grant beattie wrote:
If the incoming message doesn't contain the Date header, it isn't valid. Your MDA doesn't conform the the RFC 2822, IMHO. indeed, however, we get too much mail that has no Date: header for it to be realistic to reject them. upon investigating, Exim has no out-of-the-box way to add a missing Date: header, though I can craft a configuration to do it.
See section 43.1 of the Exim spec: "control = submission", probably with "/sender_retain". Strange enough, a missing Date header has never been an issue to me and I never read much from others about it. And I let TB simply sort by arrival order (threaded), so I also don't rely on the Date header.
the reason for asking for a way to implement this workaround in Dovecot is so that existing messages and MUAs can "just work".
Fixing this in the MTA/MDA is not really nice, but it's not half as ugly as doing it in dovecot.
grant beattie wrote:
these clients use BODY[HEADER.FIELDS (Date)] as the date for messages. when a message has no Date: header, they display the date as 01/01/1970 10:00:00 because Dovecot returns empty string.
IMNSHO, the appropriate fix is to refuse these messages in the initial SMTP transaction. RFC-2822, section 3.6 clearly states:
The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional. More information is contained in the table following this definition.
Any message without a DATE: and FROM: header is malformed and should be refused. When I turned this on, the only legitimate messages that were bounced were from a stupid print-to-email feature on our HP printer/copiers. I routed those through an MTA that added a DATE: header and all was fine.
YMMV
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
participants (6)
-
Angel Marin
-
Eric
-
grant beattie
-
Jakob Hirsch
-
Jan Kundrát
-
John Peacock