[Dovecot] CATENATE allows empty messages
Dovecot-2.2.1 allows empty messages to be APPENDed when using CATENATE:
b1 append inbox catenate (text {0+}
)
b1 OK [APPENDUID 1366726248 12] Append completed.
Contrast this with regular APPEND: b2 append inbox {0+} b2 NO Can't save a zero byte message.
Note that zero-size literals are OK but zero-size messages are not. So while "b1" above should fail like "b2", this should continue to succeed: b3 append inbox catenate (text {0+} text {8+} foobar ) b3 OK [APPENDUID 1366726248 13] Append completed.
On 29.4.2013, at 21.40, Mike Abbott michael.abbott@apple.com wrote:
Dovecot-2.2.1 allows empty messages to be APPENDed when using CATENATE: b1 append inbox catenate (text {0+}
) b1 OK [APPENDUID 1366726248 12] Append completed.Contrast this with regular APPEND: b2 append inbox {0+} b2 NO Can't save a zero byte message.
Note that zero-size literals are OK but zero-size messages are not. So while "b1" above should fail like "b2", this should continue to succeed: b3 append inbox catenate (text {0+} text {8+} foobar ) b3 OK [APPENDUID 1366726248 13] Append completed.
This could be changed I guess, but I don't think it's a bug. I don't see anything in RFC 3501 prohibiting saving empty messages. Only the MULTIAPPEND RFC says:
A zero-length message literal argument is an error, and MUST
return a NO. This can be used to cancel the append.But that doesn't prohibit zero-length CATENATE parameters.
On 30.4.2013, at 0.12, Timo Sirainen tss@iki.fi wrote:
On 29.4.2013, at 21.40, Mike Abbott michael.abbott@apple.com wrote:
Dovecot-2.2.1 allows empty messages to be APPENDed when using CATENATE: b1 append inbox catenate (text {0+}
) b1 OK [APPENDUID 1366726248 12] Append completed.Contrast this with regular APPEND: b2 append inbox {0+} b2 NO Can't save a zero byte message.
Note that zero-size literals are OK but zero-size messages are not. So while "b1" above should fail like "b2", this should continue to succeed: b3 append inbox catenate (text {0+} text {8+} foobar ) b3 OK [APPENDUID 1366726248 13] Append completed.
This could be changed I guess, but I don't think it's a bug. I don't see anything in RFC 3501 prohibiting saving empty messages. Only the MULTIAPPEND RFC says:
A zero-length message literal argument is an error, and MUST return a NO. This can be used to cancel the append.But that doesn't prohibit zero-length CATENATE parameters.
Also another way to generate empty message is to give URL to an empty MIME part. Should such APPENDs also fail? I think if there's no good reason to disallow empty messages I'll just keep the code as it is and allow them.
Quoting Timo Sirainen tss@iki.fi:
On 30.4.2013, at 0.12, Timo Sirainen tss@iki.fi wrote:
This could be changed I guess, but I don't think it's a bug. I
don't see anything in RFC 3501 prohibiting saving empty messages.
Only the MULTIAPPEND RFC says:A zero-length message literal argument is an error, and MUST return a NO. This can be used to cancel the append.But that doesn't prohibit zero-length CATENATE parameters.
Also another way to generate empty message is to give URL to an
empty MIME part. Should such APPENDs also fail? I think if there's
no good reason to disallow empty messages I'll just keep the code as
it is and allow them.
Some clients treat IMAP as a pseudo-filesystem (e.g. Kolab), so I
would agree that limiting what can be stored is a bad idea.
michael
It's the inconsistency that bothers me. Plain old APPEND doesn't allow empty messages but CATENATE does?
Quoting Mike Abbott michael.abbott@apple.com:
It's the inconsistency that bothers me. Plain old APPEND doesn't
allow empty messages but CATENATE does?
I don't recall/see anything in RFC 3501 that prevents a zero-length message:
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal
[...]
literal = "{" number "}" CRLF *CHAR8 ; Number represents the number of CHAR8s
[...]
number = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < 4,294,967,296)
So this is legal under the ABNF:
APPEND mailboxname {0}CRLF[0 length *CHAR8]CRLF
Timo mentioned that MULTIAPPEND doesn't allow zero-length messages.
But looks like that was done solely as a way to provide a mechanism to
cancel a MULTIAPPEND rather than a statement that zero-length messages
are not ever intended to be processed by any kind of APPEND action
(i.e. a vanilla RFC 3501 non-MULTIAPPEND action).
michael
participants (3)
-
Michael M Slusarz
-
Mike Abbott
-
Timo Sirainen