Hello,
I looked into that a bit with weDBmail stuff - what I remember
is an rfc2822 message itsself doesn't matter, it can use whatever
you want. Everything that handles a message over the network (ie.
smtp, pop, imap) uses nvt ascii, which requires \r\n newlines.
Specifically, I think rfc2821 (smtp) says the headers require \r\n
but I don't know that the body does (because a lone \n is within
the valid charset for the message text, so maybe it's not being
interpretted as a newline...), except for the very last 2 lines,
"\r\n.\r\n".
I would think it'd be better to just handle the message as it
comes to you, rather than changing it. I know for a fact that you
can see mixed \r\n and \n in the same message (whether right or
wrong, it happens). There would likely be implications with
cryptographic signatures if you alter anything in the body. Just
store the message as you receive it, and calculate rfcsize for
how the message will be returned (ie. \n -> \r\n expansion.
But on the other hand, there's no difference to the client if
it's stored with \n and then converted to \r\n when read, which
is what happens now, so I'd guess that must already be taken care
of in the crypto signing programs/protocols (I don't use any
myself).
The pop/imap daemons shouldn't need altered any - they do
\n -> \r\n expansion on the fly as they read from the db and write
to the client (in db_send_message_lines()) and will leave \r\n alone.
In weDBmail work, it seems the pear imap functions work the best
with \n delimited messages (and absolutely break with mixed-formats),
and that seems to be what postfix gives you upon local delivery,
despite everything I can see in the rfc's saying it should be \r\n
(but for local delivery, I guess you never actually perform smtp,
so...).
---- Original Message ----
From: Roel Rozendaal - IC&S <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] Error in calculation of mailbox-size
Sent: Fri, 27 Feb 2004 10:11:09 +0100
> expanding the newlines at insertion sounds good to me; it will however
> require some adjustments for the pop and imap daemons. Furthermore, i
> don't know whether some rfc's forbid actual changing the message upon
> insertion.
>
> Op 26-feb-04 om 21:42 heeft Aaron Stone het volgende geschreven:
>
> > Which is to say, that some messages will arrive with \r\n and some
> > with just
> > \n, and we need to accept both of these, but when displaying a
message,
> > everything is sent as \r\n... which leads me to wonder if I should be
> > *counting* the non-\r\n lines, or simply converting them to \r\n upon
> > receipt,
> > and not bother with messagesize / rfcsize, as everything will be
> > rfcsize.
> >
> > Ilja, Roel... any preference here? I'm happy to add the extra checks
> > for \r\n,
> > but that code is going to be only slightly different from code to
just
> > convert
> > the messages to \r\n anyhow!
> >
> > Aaron
> >
> >
> > "Jesse Norell" <jesse@kci.net> said:
> >
> >>
> >> Aaron,
> >>
> >> I've not looked at the delivery code, but in this you'd needd to
> >> make sure that any \r\n's were stripped to just \n when the message
> >> is saved. If that's not done, then you just need to add the number
> >> of header/body lines that had only \n (hence the imap server will
> >> change to \r\n), not ones that have \r\n (because those will already
> >> be included in the header/body bytecounts).
> >>
> >>
> >>
> >> ---- Original Message ----
> >> From: Aaron Stone <dbmail-dev@dbmail.org>
> >> To: <dbmail-dev@dbmail.org>
> >> Subject: Re: [Dbmail-dev] Error in calculation of mailbox-size
> >> Sent: Thu, 26 Feb 2004 19:33:00 -0000
> >>
> >>> I've got it working in my tree, but it required changing about half
> >> a dozen
> >>> delivery functions to carry a few more arguments. Ilja, do please
> >> push your
> >>> tree (with my patches ;-) into CVS, and I'll diff against it this
> >> evening.
> >>>
> >>> Upon message delivery, both sizes are calculated and stored:
> >>> physmessage.messagesize = bytecount of header + bytecount of body
> >>> physmessage.rfcsize = bytecount of header + linecount of header
> >>> + bytecount of body + linecount of body
> >>>
> >>> Aaron
> >>>
> >>>
> >>> "Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >>>
> >>>> So basically...
> >>>>
> >>>> rfcsize = headersize + headerlines + messagesize + messagelines?
> >>>>
> >>>> Aaron
> >>>>
> >>>>
> >>>> Roel Rozendaal - IC&S <roel@ic-s.nl> said:
> >>>>
> >>>>> on the rfc_size field:
> >>>>>
> >>>>> the rfc_size is the size which should be returned when you ask
> >> the imap
> >>>>> server to FETCH RFCSIZE. It differs from the messagesize because
> >> each
> >>>>> of the newlines has to be counted twice as they are rewritten to
> >> '\r\n'
> >>>>> when outputted by the imap server. Initially it is set to zero
> >> and the
> >>>>> imap server updates this field the first time the rfcsize is
> >> requested
> >>>>> (or, more precisely, the server updates this field if it is
> >> equal to
> >>>>> zero) .
> >>>>> I came up with this when i observed frequent rfcsize requests from
> >>>>> mailclients for the same mails, caching the rfcsize removes the
> >> need to
> >>>>> parse the entire message time and time again.
> >>>>> If you feel like it, you can calculate this probably fairly easy
> >> when
> >>>>> reading the data of the to-be-delivered message - that would be
> >> even
> >>>>> better :-) (but i never found the time to do it :p)
> >>>>>
> >>>>> regards roel
> >>>>>
> >>>>> Op 26-feb-04 om 16:43 heeft Aaron Stone het volgende geschreven:
> >>>>>
> >>>>>> I thought that there was a function that counted the final
> >> size of a
> >>>>>> message
> >>>>>> automatically... but I guess not! In any event, I see that at
> >> the very
> >>>>>> end of
> >>>>>> store_message_temp(), there's an update:
> >>>>>>
> >>>>>> db_update_message(msgidnr, unique_id, totalmem+headersize, 0);
> >>>>>>
> >>>>>> The first problem is that the fourth argument, rfc_size, is 0.
> >> How
> >>>>>> does the
> >>>>>> RFC size differ from the Message size? The second problem
> >> seems to be
> >>>>>> that
> >>>>>> totalmem+headersize is not yielding a correct result. They are of
> >>>>>> nominally
> >>>>>> different types, size_t and u64_t, but that should work, no?
> >>>>>>
> >>>>>> Aaron
> >>>>>>
> >>>>>>
> >>>>>> Ilja Booij <ilja@ic-s.nl> said:
> >>>>>>
> >>>>>>> Found the problem. Using the new delivery chain, the size of
> >> a message
> >>>>>>> is never stored, so the total size of the message (as stored
> >> in the
> >>>>>>> messagesize field in the physmessage table) is only the size
> >> of the
> >>>>>>> header.
> >>>>>>>
> >>>>>>> Aaron, could you take a look at this? I guess the total size
> >> of the
> >>>>>>> message needs to be stored somewhere in the store_message_temp()
> >>>>>>> function.
> >>>>>>>
> >>>>>>> I'll be off now, and won't be back until Monday. I want to
> >> release RC3
> >>>>>>> then. I hope we can tackle the Mozilla problem from then on
> >> (unless
> >>>>>>> anybody happens to find the cause of the problem before
> >> Monday :) ).
> >>>>>>>
> >>>>>>> Ilja
> >>>>>>>
> >>>>>>>
> >>>>>>> Ilja Booij wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> it seems that calculation of a user's mailbox size isn't
working
> >>>>>>>> properly (not all messageblks are counted).
> >>>>>>>>
> >>>>>>>> I'm working on this :)
> >>>>>>>>
> >>>>>>>> Ilja
> >>>>>>>> _______________________________________________
> >>>>>>>> Dbmail-dev mailing list
> >>>>>>>> Dbmail-dev@dbmail.org
> >>>>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>>> _______________________________________________
> >>>>>>> Dbmail-dev mailing list
> >>>>>>> Dbmail-dev@dbmail.org
> >>>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Dbmail-dev mailing list
> >>>>>> Dbmail-dev@dbmail.org
> >>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>>
> >>>>>
> >>>>> _________________________
> >>>>> R.A. Rozendaal
> >>>>> IC&S
> >>>>> T: +31 30 63 55 736
> >>>>> F: +31 30 63 55 731
> >>>>> www.ic-s.nl
> >>>>>
> >>>>> _______________________________________________
> >>>>> Dbmail-dev mailing list
> >>>>> Dbmail-dev@dbmail.org
> >>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Dbmail-dev mailing list
> >>>> Dbmail-dev@dbmail.org
> >>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Dbmail-dev mailing list
> >>> Dbmail-dev@dbmail.org
> >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>
> >> -- End Original Message --
> >>
> >>
> >> --
> >> Jesse Norell
> >>
> >> administrator@kci.net is not my email address;
> >> change "administrator" to my first name.
> >> --
> >>
> >> _______________________________________________
> >> Dbmail-dev mailing list
> >> Dbmail-dev@dbmail.org
> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>
> >
> >
> >
> > --
> >
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
>
> _________________________
> R.A. Rozendaal
> IC&S
> T: +31 30 63 55 736
> F: +31 30 63 55 731
> www.ic-s.nl
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
-- End Original Message --
--
Jesse Norell
administrator@kci.net is not my email address;
change "administrator" to my first name.
--