Re: [Evolution-hackers] CamelMimeMessage from known UID -- easiest way?
On Wed, Apr 1, 2009 at 2:36 PM, Saurabh Nanda saurabhna...@gmail.com wrote: Hi, I'm a newbie who's trying to write a plugin for Evolution. Please pardon my ignorance if my question sounds too simplistic. I've spent hours with the Camel documentation, but have not been able to figure this out for myself. Given the UID [1] what is the easiest way to get a reference to the CamelMimeMessage object representing the message? There is a function called camel_folder_get_message, but it requires a CamelFolder object as one of the arguments. If this is what I need to use, how do I get hold of the CamelFolder where the message resides? your eplugin should hook onto org.gnome.evolution.mail.folderview.popup . Your callback would get a data pointer of type EMPopupTargetSelect (say EMPopupTargetSelect *target). target-folder is the pointer to the CamelFolder you need. HTH, Partha [1] I'm assuming UID is the value of the Message-ID header Thanks, Saurabh. -- http://nandz.blogspot.com http://foodieforlife.blogspot.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Parthasarathi Susarla Where i'm going, I don't need a road. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] build break???
Hi Matthew, On 5/9/07, Matthew Barnes [EMAIL PROTECTED] wrote: As of this writing trunk and gnome-2-18 branch build successfully for me, thanks to a quick fix by Srini for a small build break I caused yesterday. If you're still encountering problems can you please post the errors here or file a bug? Sorry for the false alarm - i was kinda mixing up things which e-d-s from trunk and evo from 2 18 - thats the reason for way too many conflicts. Apologies for the inconvenience. My apologies for the inconvenience. Cheerio, partha -- Parthasarathi S A E-mail : ajaysusarla at gmail dot com ajaysusarla at yahoo dot com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] application/ms-tnef support
On Wed, 2006-03-29 at 20:54 +0200, Andre Klapper wrote: hi nick, Am Mittwoch, den 29.03.2006, 13:32 -0500 schrieb Nick Sukharev: I wonder if absence of application/ms-tnef support in Evolution is a result of some sort Microsoft licensing? I thought about trying to add this support myself. Does anybody have any ideas if such patches would be accepted? there was an experimental plugin available for evo 2.3.1: http://mail.gnome.org/archives/evolution-list/2006-February/msg00126.html don't know if it has been updated in the meantime, and don't know if it can become part of the stable releases. Yup it is available in the tarball (if you decide to build Evolution), the plugin was purely experimental as Andre already mentioned. Its not gone in as the default plugin in the stable release -partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel.Store or Camel.Folder sync()
On Wed, 2006-03-01 at 08:51 +0100, Jules Colding wrote: Yes sure, but my question was more directed towards the expunge functionality of sync(). Both camel_store_sync() and camel_folder_sync() have an option for expunging folders. The functionality is therefore shared between the Camel.Store and Camel.Folder classes. I am therefore in doubt about which one is the preferred place to actually implement the expunge functionality. The store_sync() calls a folder_sync on all the folders available in the store. So you actually need to implement it the Camel.Folder sync. And the store sync would do the rest for you. It is not necessary for you to implement the store_sync method unless you drastically want to change something specific to your store, which i doubt. For more details just see store_sync() function in camel-store.c. I would guess in Camel.Folder but is that correct? yup. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Unsubscribtion letter
Dude, People have enough work and mails and junk to read already. And trust me the last thing we want on this list is some mails like these. Please refer to sushmas earlier mail regarding how to subscribe and un-subscribe -partha On Wed, 2006-02-15 at 01:42 -0800, Siddhartha Singh wrote: i want to unsubscribe __ Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, more on new and used cars. ___ 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] ... and how camel should be
Hiya, On Mon, 2006-02-13 at 22:38 +0100, Philip Van Hoof wrote: On Mon, 2006-02-13 at 15:10 -0500, Jeffrey Stedfast wrote: This would take several years to implement - likely to require complete rewrites of at least some of the providers. I don't really see this happening anytime soon. What about the disk summary branch? Hmm... Yes, it exists, as Michael wrote it, never been tested and worked on since then. I have just started some work on it - to get it merged with the HEAD (once we branch for 2-14), and i shall keep it posted here, whenever it happens. The details of the branch are here http://go-evolution.org/On-disk_summaries (written by NotZed) Will this branch have likewise functionality? The disk summaries branch does something on those lines, but it also means a lot of disk I/O than before, and only after prolonged testing/usage would we now how well it would work. Difficult is fun. :) Am glad this discussion has begun. -partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] IMAP Mails in trash may be expunged after you use thunderbird
On Thu, 2005-12-22 at 13:26 +0800, jeff cai wrote: Hi,all Harry and I find that if you delete a mail in INBOX folder by ThunderBird, all mails in trash folder in Evolution will be removed. This comes from the difference of implementation of both products. When you delete a mail, evolution marks the mail Deleted flag, while thunderBird will mark the mail Deleted and copy one to a real folder Trash, then expunge the folder which the deleted mail is in. Therefore, those mails marked as Deleted in that folder will also be removed. You can't find them again. The result is YOU LOST mails in the trash folder of evolution. I dont see *we* can do much about this. Since: + Its Thunderbird which is Expunging the folder, probably some settings can be changed for it not to Expunge each time you delete. Am not sure though + Evolution just marks it deleted. And does *not* Expunge it by default (or does it based on the settings or user action), when deleted. And i am sure this is quite like the behaviour users would be comfortable with. Ofcourse, we can go on debating about which is the best way to do this. But i dont see anything productive coming out of such a debate. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Should I unref a CamelMesageInfoBase?
Hey On Wed, 2005-12-07 at 13:25 +0100, Jules Colding wrote: Hi, Must I unref a reference to a message info when retrieved by camel_folder_summary_uid()? This function increases the refcount before returning it. Yeah. you need to unref it. I can see from gw_update_summary() in the GroupWise provider that it never unrefs the reference. Is that wrong? few issues in the branch. The HEAD has all the fixes in. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Possible bug in GW Camel provider
On Thu, 2005-12-15 at 14:29 +0100, Jules Colding wrote: On Wed, 2005-12-14 at 21:30 +0530, Parthasarathi Susarla wrote: Hey jules, On Wed, 2005-12-14 at 15:39 +0100, Jules Colding wrote: [snip] I have just inspected cvs HEAD instead of the gnome-2-12 branch. The strings are indeed being released in HEAD so my assertion that this is a bug seems to be correct, but the bug(s) is only present in the gnome-2-12 branch. Yeah! a lot changes in the HEAD, did not put them on the stable branch since they were way to many string changes and ABI breakages. HEAD has a lot of fixes. Speaking about fixes... When mi is retrieved at line 1061 in camel-groupwise-folder.c (HEAD) the refcount is incremented. mi is never unreffed when exist is TRUE. I think that there should be a call the camel_message_info_free() at line 1167 just after the call to camel_folder_change_info_change_uid(). You are right. Fix is committed to head. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New plugin (Purge Old Mail) [Patch attached]
Hey Alex, So the plugin looks good an works well too. A couple of issues: * you need to probably update the eplug file for the right hooks (as discussed on IRC) * in the function org_gnome_purge_mail_prefs_factory, you are comparing strings (folder names), since folder names are translatable, this check would fail for folder names which are translated. Otherwise, things look fine. Thanks and all the best for the plugins to come :) Cheers, partha On Tue, 2005-11-08 at 12:16 -0200, Alexandre Rocha Lima e Marcondes wrote: Hello fellow Evolution Hackers, I'm proud to announce a patch to incorporate a new plug-in to evolution: purge old mail This plug-in allows to set the number of days to keep messages on folder-by-folder basis as well as enable/disable the plug-in to any specific folder. The plug-in files and the patch that is used to compile and add it to evolution code base is attached. P.S.: Thank you very much Shreyas Srinivasan for helping me on this first journey to code an evolution plugin ... -- Regards, Alexandre Rocha Lima e Marcondes P4 Tecnologia e Desenvolvimento Humano [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.p4tecnologia.com alexandre.p4tecnologia.com Projetos: MonoBrasil MonoBASIC ACBr Freedom ERP To validate this message's signature follow the instructions: http://www.cacert.org/index.php?id=3lang=en_US ___ 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-patches] Re: [Evolution-hackers] Logic flaw in header_decode_lwsp()
Indeed a good find Jules.
Thanks for the patch fejj.
Cheers,
partha
On Fri, 2005-12-02 at 14:15 -0500, Jeffrey Stedfast wrote:
On Fri, 2005-12-02 at 15:19 +0100, Jules Colding wrote:
Hi,
The following while statement does not make sense:
# snip ###
static void
header_decode_lwsp(const char **in)
{
const char *inptr = *in;
char c;
d2(printf(is ws: '%s'\n, *in));
while (camel_mime_is_lwsp(*inptr) || (*inptr =='(' *inptr != '\0')) {
.
.
.
# snip ###
If *inptr is equal to '(' then it is per definition not equal to '\0'.
OK, does not makes sense might to harsh, but it definitely does not
seem to done this way on purpose.
indeed, and while I was fixing that logic problem I also removed the
'\0' check since it isn't needed in any way (if it is lwsp or '(' then
it can't be \0)
___
Evolution-patches mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/evolution-patches
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
Hey Guenther, On Thu, 2005-12-01 at 23:38 +0100, guenther wrote: Ok, I will try to remain calm -- not to shout, not to rant, not to do anything I may regret later. 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? OK. There are several reasons. Firstly and the most obvious being that when an account is disabled you should not be able to 'operate' on the account. You can only *save* such mails as draft or send it using another account. And most importantly - the concept of being able to *send* mails using a *disabled* account is pretty confusing. So now we just have a message asking the user to chose another account to send e-mail. This issue was discussed recently on e-p, just a month ago [1]. With absolutely *no* conclusion. I don't see any approval for the patch either. The patch which i sent did not solve #243241, i already mentioned this in a reply to andres mail. The reason i wanted you to comment is if the current behavior atleast 'partially' solves the issue. Btw, the bug for which the patch i had sent was this http://bugzilla.gnome.org/show_bug.cgi?id=315987 And as for the current behavior on the CVS. its as follows: When a user tries to send an e-mail using a disabled account, a message which says You cant send this mail using a disabled account appears. And the only thing one could do, apart from saving the message as a draft, is to chose one of the enabled accounts and send the message. And yes, this behavior was with the prior approval of the UI team (FYI it was srini who approved the patch). To sum up the entire thread: Can we please get a decision by the UI team on #243241 first? Do we want this? And regarding the bug #243241, ofcourse your suggestions are taken. And we *are* really working on it. Philip, Brett, can you try the Guenthers suggestion on using account only for sending (and having it enabled). That should work fine as well. From Guenthers mail: Edit / Preferences / Mail Accounts / account Edit Receiving Email / ServerType: None Edit / Preferences / Mail Accounts / account Enable Yeah, a sending only account. Really. It's already available. Guenther, this still can be done. I have it built from the current CVS snapshot - and i can do it still. So i really dont understand what you are complaining about. Why are patches sent to e-p, if the replies and discussion is going to be ignored anyway? The patches like always are *sent* to the patches list and are also put up on the bugzilla. A rant does not help anyone. It just creates a lot of *Mess*. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
Hey Philip, 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. Why is this possibility blocked? OK. There are several reasons. Firstly and the most obvious being that when an account is disabled you should not be able to 'operate' on the account. You can only *save* such mails as draft or send it using another account. And most importantly - the concept of being able to *send* mails using a *disabled* account is pretty confusing. So now we just have a message asking the user to chose another account to send e-mail. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
Hey Andre, On Wed, 2005-11-30 at 02:20 +0100, Andre Klapper wrote: 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. :-/ Hmm...the patch actually does not try and fix that, probably just partially. But guenther would say that there is more to that bug han just 'not being able to send e-mails using disabled accounts'. :) (btw, i would want guenther to take a call on that, if this kinda fixes his problem. Guenther??) Adding guenther on the CC Cheers, partha ___ 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 09:54 +0100, Philip Van Hoof wrote: On Wed, 2005-11-30 at 09:42 +0100, Philip Van Hoof wrote: So how do I solve my situation then? ;-) I have multiple E-mail accounts that I use for sending. But only a few real 'mailboxes' for receiving. Some of the E-mail accounts are aliases to others. Example: My gnome e-mail address isn't a real e-mail address with a mailbox attached. It gets delivered to another E-mail address which I also use. Yet, I'd like to send using my gnome e-mail address in the From header. May I suggest a This account is used for sending only option, then? Hm... Interesting proposition i should say :). Huh! I actually never thought of this problem. So am actually little stumped i should admit. :) Would get back to you on this in a little while. Cheers, 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 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 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
Re: [Evolution-hackers] evolution wiki
On Sun, 2005-11-27 at 20:57 -0500, AG wrote: Is there a wiki for evolution-hacker or a wiki for evolution in general? Just wanted to find a means to share the following: Check out http://go-evolution.org/ Slackware 10.2 users can get Evolution 2.4 up and running quite easily using gsb/FRG or Freerock GNOME. See - http://gsb.freerock.org/ you could add the section there. Cheers, 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-22 at 13:55 +0100, Jules Colding wrote: Hi, I am currently retrieving data from a MAPI object and most data is easily mapped from MAPI into corresponding Camel data types. One is missing though - the CamelMessageInfoBase.date_sent type doesn't seem to exist within the range of MAPI properties available on the object. Does the sent time exist in the message header? Do I just set the date_sent property to NULL if not?? date_sent is typically for the items in the Sent folder. Yeah you can set it to 0. -partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When do I update the Camel.FolderSummary?
On Tue, 2005-11-15 at 11:45 +0100, Jules Colding wrote: Hi, Reading the comments in the code, it seems that I should only update the folder summary when explicitly told so by Evolution invoking the camel_folder_refresh_info() method or, obviously, when I know something changed server-side. refresh_info can be called in 3 ways: * either by clicking on Send/Receive button * auto sync (timed sync) based on your settings. * or when you select a folder, the selected folder is refreshed. You could explicitly call call camel_folder_refresh_info() when you want to, ofcourse, that is entirely provider implementation specific. But mostly, its usually done in one of the 3 ways mentioned above Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [CAMEL] CamelFolder *_getv() - What should it do?
On Mon, 2005-11-14 at 13:41 +0100, Jules Colding wrote: [snip] arg-ca_ptr must be freed while folder-name is managed by the folder instance. Whom is responsible for freeing the GPtrArray ? One needs to call folder_free with the appropriate tag to free the CamelArgs. Typically called by the mail code, to get folder properties after which the free method is called. -partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [CAMEL] CamelStore create_folder() name constraints...
On Tue, 2005-10-18 at 10:05 +0200, Jules Colding wrote: OK. So the point is that _most_ backend servers wont allow it, but that _some_ servers might allow it. I should therefore check that no identically named folder exist and refuse to create an identically named sibling, as a matter of enforcing some kind of naming consistency in Evolution regardless of the nature of the backend server. Right? My concerns are with regard to Exchange. The point is that most, but not all, message store providers will reject identically named sibling folders. Am really not sure how Exchange works. Have to look it up. The documentation for the PR_DISPLAY_NAME actually states that sibling folder must be uniquely named but somewhere (don't remember where) MSDN only states that _most_, but not all, message store providers require unique PR_DISPLAY_NAME. Forcing unique sibling folder names on creation will partly solve the dilemma, but what should happen when identically named siblings are found anyway? If indeed a protocol(server) allows you to have identically named siblings, then the matter of concern would be how we would store it locally. The filesystem would obviously not allow us to have identical siblings. So i think we inherently are(although its not very obvious) forcing unique sibling folder names. -partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [CAMEL] CamelStore create_folder() name constraints...
On Tue, 2005-10-18 at 11:29 +0200, Jules Colding wrote: On Tue, 2005-10-18 at 14:40 +0530, Parthasarathi Susarla wrote: On Tue, 2005-10-18 at 10:05 +0200, Jules Colding wrote: Forcing unique sibling folder names on creation will partly solve the dilemma, but what should happen when identically named siblings are found anyway? If indeed a protocol(server) allows you to have identically named siblings, then the matter of concern would be how we would store it locally. The filesystem would obviously not allow us to have identical siblings. No, but we can do almost as good by appending a ' ' to the name of the first identically named sibling and ' ' the next and so forth. I am pondering how to do this the best. I do not think that forcibly changing the name on the remote server will be any good, so I think that a local mapping agent must be used. Something like: Case A - N identically named folders/objects are found on the remote server: A map of display names are created whereby the remote names used to construct a one-to-one local name == remote UUID mapping. The local names are constructed from the remote names by appending 1..(N-1) ' ' characters to the remote names. Case B - An Evolution user wants to create an object with a name that is identical to an existing sibling: We deny the request. Case A above can get complicated, but I don't see how we can do otherwise if we want to cover all use cases. Thoughts? We should deny, unless the protocol tells what to do. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [CAMEL] CamelFolder *_getv() - What should it do?
On Mon, 2005-10-17 at 13:04 +0200, Jules Colding wrote: Hi, I can see several providers implementing a *_getv() method. It seems that it just provides a descriptive name of the folder in question. Is that correct? It does a lot more than that. getv provides info based on the type of argument that we require to know about. This would include Total count, Unread count, flags, full name. check the 'folder_getv' method in camel-folder.c. The implementation is clear enough Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
