Re: Libmailcheck- take two

[Maciej Stachowiak <mstachow alum mit edu>]

Ian Campbell wrote:
>  
> I hope we don't end up using fetchmail (well at least not for IMAP)... The
> point with IMAP is that you don't d/l the mail from the server - it is
> stored and manipulated on the server.

I'm not saying we should use fetchmail to actually donwload the mail -
I am suggesting that since fetchmail knows how to talk every mail protocol,
for all practical purposes, it should be easier to modify it to check if 
pending mail is avaialable (if it does not already provide this capability
directly) than to implement this functionality for all those various mail 
protocols.

> Here's an idea...
> 
> The server provides a list of known mailbox types. a call creates a new
> mailbox by type name (note my previous mail for my interface ideas):
> 
> MailBox *gnome_mailbox_new_by_typename (gchar *name);
> 
> and each type of mailbox object is responsible for creating a panel of
> it's own settings to be included in the apps config dialog or whatever, it
> would do this by overriding the config method in the base MailBox object.
> Any app can then just call:
> GtkWidget *gnome_mailbox_config(MailBox *mb);
> whilst building it's config dialog....
> 
> or else the gtk-args thing should probably be used in favour of some
> proprietary method, gtk-args is designed to allow apps to manipulate
> unknown objects. I think it was originally desgined for GUI builders, but
> would work just as well here...

Either of those sounds like a decent plan.

> 
> I beleive there is .gnome_private directory analogous to .gnome except
> only readable by the user.  there are gnome_config_private_* methods to
> save stuff in there. Saving a password in here should be OK? I am guessing
> that password saving is (part of) the reason these methods exist.  An
> option to prompt is always nice mind you.

No way. NFS home directories typically go over the network in the clear. 
Also, crackers who crack root should not be able to use information on
disk to infiltrate other hosts. Secret data should never ever be saved in the 
user's home directory in the clear. Note that ssh encrypts your secret key 
with a passphrase you must provide each time, for example, even though the 
permissions on the .ssh directory do not in theory allow anyone to read it.

 - Maciej