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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> said:
So basically...
rfcsize = headersize + headerlines + messagesize + messagelines?
Aaron
Roel Rozendaal - IC&S <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 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
