[Dovecot] maildir format
Hello Timo and other dovecot-dev or users,
It looks like Dovecot accepts (with APPEND command) messages that
begins
with 'From[SPACE]' line, which are not valid from RFC 2822 point of
view.
Additionnally, Dovecot will store them as they are APPENDed, I mean
with the starting 'From[SPACE]' line, which generates a bad Maildir
format.
http://www.qmail.org/man/man5/maildir.html states the following :
<< Each file in new is a newly delivered mail message. The modification time of the file is the delivery date of the message. The message is delivered without an extra UUCP- style From_ line, without any >From quoting, and without an extra blank line at the end. The message is normally in RFC 822 format, starting with a Return-Path line and a Delivered-To line, but it could contain arbitrary binary data. It might not even end with a newline.
-- DINH Viêt Hoà
On Wed, 2006-05-03 at 03:17 +0200, DINH Viêt Hoà wrote:
Hello Timo and other dovecot-dev or users,
It looks like Dovecot accepts (with APPEND command) messages that
begins with 'From[SPACE]' line, which are not valid from RFC 2822 point of
view. Additionnally, Dovecot will store them as they are APPENDed, I mean with the starting 'From[SPACE]' line, which generates a bad Maildir
format.
The alternative would be to fail the operation completely. I don't see that as very good idea.
The message is normally in RFC 822 format, starting with a Return-Path line and a Delivered-To line, but it could contain arbitrary binary data. It might not even end with a newline.
Here the "could contain arbitrary binary data" looks to me like there aren't really any restrictions as to what the message could contain, including a From-line at the beginning :).
On 03 May 2006, at 12:25, Timo Sirainen wrote:
On Wed, 2006-05-03 at 03:17 +0200, DINH Viêt Hoà wrote:
Hello Timo and other dovecot-dev or users,
It looks like Dovecot accepts (with APPEND command) messages that begins with 'From[SPACE]' line, which are not valid from RFC 2822 point of view. Additionnally, Dovecot will store them as they are APPENDed, I mean with the starting 'From[SPACE]' line, which generates a bad Maildir format.
The alternative would be to fail the operation completely. I don't see that as very good idea.
The message is normally in RFC 822 format, starting with a Return-Path line and a Delivered-To line, but it could contain arbitrary binary data. It might not even end with a newline.
Here the "could contain arbitrary binary data" looks to me like there aren't really any restrictions as to what the message could contain, including a From-line at the beginning :).
You could combine both :
accepting mails with 'From[SPACE]' and stripping this line while
storing the mail.
(And by the way, I should accept Maildir messages with 'From[SPACE]'
at the beginning ;) )
-- DINH Viêt Hoà
On Wed, 2006-05-03 at 13:37 +0200, DINH Viêt Hoà wrote:
On 03 May 2006, at 12:25, Timo Sirainen wrote:
On Wed, 2006-05-03 at 03:17 +0200, DINH Viêt Hoà wrote:
Hello Timo and other dovecot-dev or users,
It looks like Dovecot accepts (with APPEND command) messages that begins with 'From[SPACE]' line, which are not valid from RFC 2822 point of view. Additionnally, Dovecot will store them as they are APPENDed, I mean with the starting 'From[SPACE]' line, which generates a bad Maildir format.
The alternative would be to fail the operation completely. I don't see that as very good idea.
The message is normally in RFC 822 format, starting with a Return-Path line and a Delivered-To line, but it could contain arbitrary binary data. It might not even end with a newline.
Here the "could contain arbitrary binary data" looks to me like there aren't really any restrictions as to what the message could contain, including a From-line at the beginning :).
You could combine both : accepting mails with 'From[SPACE]' and stripping this line while
storing the mail.
Sounds a bit evil to just modify what the user wanted to save.
(And by the way, I should accept Maildir messages with 'From[SPACE]'
at the beginning ;) )
Sounds like a better solution :)
participants (2)
-
DINH Viêt Hoà
-
Timo Sirainen