Re: [Dovecot] Missing MIME-Version header in e-mails.
On Wed, August 1, 2007 9:51 am, Timo Sirainen tss@iki.fi said:
On Wed, 2007-08-01 at 19:50 +0800, Tan Shao Yi wrote:
Hi,
I notice that in src/lib-mail/message-parser.c, there is a section of code that checks for the presence of MIME-Version before allowing processing of the Content-* headers.
Is there a possibility of relaxing this rule? There are some broken mailers, in particular newsletter mailers that do not seem to honour the MIME-Version header, though they do send the Content-Type.
I suppose this could be changed. At least UW-IMAP also does that..
Or at least make relaxing it an option in v1.1. I personally think it should be relaxed.
Bill
On Wed, 1 Aug 2007, Bill Boebel wrote:
On Wed, August 1, 2007 9:51 am, Timo Sirainen tss@iki.fi said:
On Wed, 2007-08-01 at 19:50 +0800, Tan Shao Yi wrote:
Hi,
I notice that in src/lib-mail/message-parser.c, there is a section of code that checks for the presence of MIME-Version before allowing processing of the Content-* headers.
Is there a possibility of relaxing this rule? There are some broken mailers, in particular newsletter mailers that do not seem to honour the MIME-Version header, though they do send the Content-Type.
I suppose this could be changed. At least UW-IMAP also does that..
Or at least make relaxing it an option in v1.1. I personally think it should be relaxed.
Bill
Hi Timo,
Will it be possible to make this available in the 1.0 branch? UW-IMAP seems to continue to process e-mails without the MIME-Version, so long as it has the Content-Type or -Encoding header.
Cheers.
On Thu, 2007-08-02 at 08:36 +0800, Tan Shao Yi wrote:
Will it be possible to make this available in the 1.0 branch? UW-IMAP seems to continue to process e-mails without the MIME-Version, so long as it has the Content-Type or -Encoding header.
Hi Timo,
Thanks so much.
UW-IMAPD includes an additional check for the Content-Transfer-Encoding too. Would it be a good idea to include it too?
From rfc822.c in UW-IMAPD:
if (!strcmp (tmp+8,"TRANSFER-ENCODING") || (!strcmp (tmp+8,"TYPE") && strchr (d,'/'))) { MM_LOG ("Warning: MIME header encountered in non-MIME message", PARSE);
Cheers.
On Thu, 2 Aug 2007, Timo Sirainen wrote:
On Thu, 2007-08-02 at 08:36 +0800, Tan Shao Yi wrote:
Will it be possible to make this available in the 1.0 branch? UW-IMAP seems to continue to process e-mails without the MIME-Version, so long as it has the Content-Type or -Encoding header.
Hi Timo,
I just tried your patch in hg and realised it also requires the "Content-Transfer-Encoding: 8bit" to be present.
I'm seeing some really bad mailers at my site that provide just header Content-Type: text/html; "charset=iso-8859-1" :(
Is there a possibility for us to accommodate such mails as MIME?
Cheers, Tan Shao Yi
On Thu, 2 Aug 2007, Tan Shao Yi wrote:
Hi Timo,
Thanks so much.
UW-IMAPD includes an additional check for the Content-Transfer-Encoding too. Would it be a good idea to include it too?
From rfc822.c in UW-IMAPD:
if (!strcmp (tmp+8,"TRANSFER-ENCODING") || (!strcmp (tmp+8,"TYPE") && strchr (d,'/'))) { MM_LOG ("Warning: MIME header encountered in non-MIME message", PARSE);
Cheers.
On Thu, 2 Aug 2007, Timo Sirainen wrote:
On Thu, 2007-08-02 at 08:36 +0800, Tan Shao Yi wrote:
Will it be possible to make this available in the 1.0 branch? UW-IMAP seems to continue to process e-mails without the MIME-Version, so long as it has the Content-Type or -Encoding header.
On Fri, 2007-08-03 at 01:04 +0800, Tan Shao Yi wrote:
Hi Timo,
I just tried your patch in hg and realised it also requires the "Content-Transfer-Encoding: 8bit" to be present.
I'm seeing some really bad mailers at my site that provide just header Content-Type: text/html; "charset=iso-8859-1" :(
Is there a possibility for us to accommodate such mails as MIME?
Well, I'm not sure how you'd want Dovecot to handle it. All of this basically only changes BODY and BODYSTRUCTURE replies. With Content-Type: header Dovecot returns its contents, but a missing Content-Transfer-Encoding: causes it to use 7bit as default:
- 1 FETCH (BODY ("text" "plain" ("charset" "iso-8859-1" "format" "flowed") NIL NIL "7bit" 623 22))
So are you saying that you'd want it to use 8bit as default?
Although if your Content-Type really has quotes around charset, that's the problem. It's completely broken then and Dovecot just ignores it:
- 1 FETCH (BODY ("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 623 22))
UW-IMAP handles it a bit differently:
- 1 FETCH (BODY ("TEXT" "PLAIN" ({20} "CHARSET=ISO-8859-1" "MISSING_PARAMETER_VALUE" "FORMAT" "flowed") NIL NIL "7BIT" 623 22))
On Thu, 2 Aug 2007, Timo Sirainen wrote:
On Fri, 2007-08-03 at 01:04 +0800, Tan Shao Yi wrote:
Hi Timo,
I just tried your patch in hg and realised it also requires the "Content-Transfer-Encoding: 8bit" to be present.
I'm seeing some really bad mailers at my site that provide just header Content-Type: text/html; "charset=iso-8859-1" :(
Is there a possibility for us to accommodate such mails as MIME?
Well, I'm not sure how you'd want Dovecot to handle it. All of this basically only changes BODY and BODYSTRUCTURE replies. With Content-Type: header Dovecot returns its contents, but a missing Content-Transfer-Encoding: causes it to use 7bit as default:
- 1 FETCH (BODY ("text" "plain" ("charset" "iso-8859-1" "format" "flowed") NIL NIL "7bit" 623 22))
So are you saying that you'd want it to use 8bit as default?
Although if your Content-Type really has quotes around charset, that's the problem. It's completely broken then and Dovecot just ignores it:
- 1 FETCH (BODY ("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 623 22))
UW-IMAP handles it a bit differently:
- 1 FETCH (BODY ("TEXT" "PLAIN" ({20} "CHARSET=ISO-8859-1" "MISSING_PARAMETER_VALUE" "FORMAT" "flowed") NIL NIL "7BIT" 623 22))
Hi Timo,
Thanks for the explaination. I think the bad e-mail header I received was not too good. The patch applied is OK.
Cheers.
participants (3)
-
Bill Boebel
-
Tan Shao Yi
-
Timo Sirainen