Re: [Evolution-hackers] I am confused about CamelMessageInfoBase.message_id
On Mon, 2005-11-28 at 11:41 -0500, Jeffrey Stedfast wrote: I believe it's the first 8 bytes of a 16-byte MD5 hash of the Message-Id (or it might be the second 8 bytes) You can check the code in camel-folder-summary.c to find out how to calculate it. Yes, at line 1653. Thanks, jules Jeff On Fri, 2005-11-25 at 13:38 +0100, Jules Colding wrote: Hi, How do I populate this field? I can see in camel-nntp-utils.c:l196 that it is a strdup() of the Message-ID message header filed, but CamelSummaryMessageID is only 8 bytes big, so how can it fit in there? This can't be right, so I am certain that I am missing something in a really stupid and embarrassing way :-( Could someone please lift the clouds from my eyes? Thanks, jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I do about missing data in the message summary?
On Tue, 2005-11-29 at 03:04 +0530, Parthasarathi Susarla wrote: On Mon, 2005-11-28 at 10:20 -0500, Jeffrey Stedfast wrote: actually, that's not true. date_sent is gotten from the MIME message headers (Date: header, fwiw). But isnt that the Date received or the date created and not the date send per se?? (RFC 822) Hmm... so which is it? Hands?? -- jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel_header_unfold()
On Mon, 2005-11-28 at 12:12 -0500, Jeffrey Stedfast wrote:
I see what you are thinking, but by the time this code is run on any
input, the \r has already been stripped and you cannot, by definition,
have \n\n in a header (it terminates the header block so we don't have
to worry about that).
I suppose the following modification could be made to be more clear:
char *
camel_header_unfold(const char *in)
{
char *out = g_malloc(strlen(in)+1);
const char *inptr = in;
char c, *o = out;
o = out;
while ((c = *inptr++)) {
if (c == '\n') {
if (*inptr == ' ' || *inptr == '\t') {
do {
inptr++;
} while (*inptr == ' ' || *inptr == '\t');
*o++ = ' ';
Might be nitpicking, but RFC 2822 says:
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
unfolding. Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.
So it appears to me that too much is being removed above. Shouldn't the
unfolding operation simply remove the CRLF and nothing else?
--
jules
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel_header_unfold()
On Tue, 2005-11-29 at 09:55 +0100, Jules Colding wrote:
On Mon, 2005-11-28 at 12:12 -0500, Jeffrey Stedfast wrote:
I see what you are thinking, but by the time this code is run on any
input, the \r has already been stripped and you cannot, by definition,
have \n\n in a header (it terminates the header block so we don't have
to worry about that).
I suppose the following modification could be made to be more clear:
char *
camel_header_unfold(const char *in)
{
char *out = g_malloc(strlen(in)+1);
const char *inptr = in;
char c, *o = out;
o = out;
while ((c = *inptr++)) {
if (c == '\n') {
if (*inptr == ' ' || *inptr == '\t') {
do {
inptr++;
} while (*inptr == ' ' || *inptr == '\t');
*o++ = ' ';
Might be nitpicking, but RFC 2822 says:
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
unfolding. Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.
So it appears to me that too much is being removed above. Shouldn't the
unfolding operation simply remove the CRLF and nothing else?
if you wanted to get nitty gritty to the finer details of the spec,
sure, but in reality it's much nicer to get rid of the extra whitespace
many clients stick in there when folding.
Often, mailers will folder part1 part2 into part1\n\tpart2 or part1
\n\t part2 or sometimes even part1\npart2
Anyways, if we wanted to remove the unfolding niceness, we'd simply
remove that inner loop and it'd be fixed.
Jeff
--
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED] - www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I do about missing data in the message summary?
3.6.1. The origination date field The origination date field consists of the field name Date followed by a date-time specification. orig-date = Date: date-time CRLF The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. (yes, I'm aware the following sentences explain that Date is not necessarily the time in which it enetred the transport system, but it's the best we have for a sent date) Jeff On Tue, 2005-11-29 at 03:04 +0530, Parthasarathi Susarla wrote: On Mon, 2005-11-28 at 10:20 -0500, Jeffrey Stedfast wrote: actually, that's not true. date_sent is gotten from the MIME message headers (Date: header, fwiw). But isnt that the Date received or the date created and not the date send per se?? (RFC 822) Cheers, partha -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I do about missing data in the message summary?
On Tue, 2005-11-29 at 10:49 -0500, Jeffrey Stedfast wrote: 3.6.1. The origination date field The origination date field consists of the field name Date followed by a date-time specification. orig-date = Date: date-time CRLF The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. (yes, I'm aware the following sentences explain that Date is not necessarily the time in which it enetred the transport system, but it's the best we have for a sent date) Hmm...makes sense. And probably thats the 'closest' we could get to the RFC. Thanks, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I do about missing data in the message summary?
On Tue, 2005-11-29 at 21:29 +0530, Parthasarathi Susarla wrote: On Tue, 2005-11-29 at 10:49 -0500, Jeffrey Stedfast wrote: 3.6.1. The origination date field The origination date field consists of the field name Date followed by a date-time specification. orig-date = Date: date-time CRLF The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. (yes, I'm aware the following sentences explain that Date is not necessarily the time in which it enetred the transport system, but it's the best we have for a sent date) Hmm...makes sense. And probably thats the 'closest' we could get to the RFC. right. some systems might even have some sort of tag for when it actually entered the transport system, if there is one - feel free to use it instead of the Date header. For example, Evolution typically uses the date string in a Received header to calculate the received date when importing from POP3 (I think) since there's no other means to get that info (other than possibly using the download time), but IMAP uses the INTERNALDATE tag since that marks the date timestamp where the message actually arrived on the IMAP server. Jeff -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I do about missing data in the message summary?
On Tue, 2005-11-29 at 11:00 -0500, Jeffrey Stedfast wrote: On Tue, 2005-11-29 at 21:29 +0530, Parthasarathi Susarla wrote: On Tue, 2005-11-29 at 10:49 -0500, Jeffrey Stedfast wrote: 3.6.1. The origination date field The origination date field consists of the field name Date followed by a date-time specification. orig-date = Date: date-time CRLF The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. (yes, I'm aware the following sentences explain that Date is not necessarily the time in which it enetred the transport system, but it's the best we have for a sent date) Hmm...makes sense. And probably thats the 'closest' we could get to the RFC. right. some systems might even have some sort of tag for when it actually entered the transport system, if there is one - feel free to use it instead of the Date header. For example, Evolution typically uses the date string in a Received header to calculate the received date when importing from POP3 (I think) since there's no other means to get that info (other than possibly using the download time), but IMAP uses the INTERNALDATE tag since that marks the date timestamp where the message actually arrived on the IMAP server. Hmm.. But i have noticed on several occasions that the INTERNALDATE (specially with a lot of spam mails) is really *not* the date the IMAP server received it. Cos i see the mail having a pretty old time-stamp. But maybe the server has an issue there. Thanks for the info. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Sending mails using disabled accounts
It looks like current CVS does not allow sending E-mails uing disabled accounts. I very often disable E-mail accounts to make it possible to choose between multiple of my E-mail addresses. Why is this possibility blocked? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
hi philip, Am Mittwoch, den 30.11.2005, 00:38 +0100 schrieb Philip Van Hoof: It looks like current CVS does not allow sending E-mails uing disabled accounts. I very often disable E-mail accounts to make it possible to choose between multiple of my E-mail addresses. Why is this possibility blocked? hmm, seems like somebody fixed http://bugzilla.gnome.org/show_bug.cgi?id=243241. there are about seven duplicates in bugzilla (which have been mostly closed as notabug instead of having marked them as duplicates). so the point is if disabled means do not receive or if it also means and do not send. :-/ cheers, andre -- mailto:[EMAIL PROTECTED] | failed! http://www.iomc.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
On Wed, 2005-11-30 at 00:38 +0100, Philip Van Hoof wrote: It looks like current CVS does not allow sending E-mails uing disabled accounts. I very often disable E-mail accounts to make it possible to choose between multiple of my E-mail addresses. you mean - not having them shown up in the mail folders tree ? How does disabling help you in choosing more easily ? Why is this possibility blocked? It boils down to what one defines 'disabling' an account as. I guess you mean it as 'I do not want to see the mails in the account till I enable it again but it is available right _there_ for all other purposes - Sending mails, Draft/Sent Item settings..etc..' - (more in the narrower sense of 'visibility'). A lot of new users suggested they interpret 'disabling' as 'I do not want anything to do with that account till I enable it again'. What has been done now is to align the behavior to what it suggests (at least to the many). Partha/Shreyas, would you like to shed more light here ? Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
