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 > --
