Re: [Phpgroupware-developers] Email Questions.

[Tony (Angles) Puglisi]

To my knowlege (limited... :) this is really a server specific issue. IMAP rfc 
spec
says a server *may* have public folders available, and many do.

Some IMAP servers implement an ACL system whereby users may share email folders 
with
certain other users. I think Cyrus IMAP does this.

I suppose UWash IMAP could potentially do this if the user/group settings on the
server were carefully implemented in the shared folder directories.

I think Courier IMAP implemented shared folder some months ago, but I've no
information on an ACL for it.

In absence of an ACL, I suppose the public folders are really public, but, 
again,
I've no first hand knowlege on this.

My reading indicates this *should* really be an IMAP server issue, I could be 
wrong,
 but I do not think it is the client's role (phpGW is a client in IMAP 
transactions)
to implement an ACL system for IMAP folders.

However, never say never, I know a lot of work has gone into the ACL system in
phpGroupWare, so maybe....


Bob Crandell (address@hidden) wrote*:
>
>Is there anything inherit to imap that would prevent one user from proxying 
>into
>another user's account?  For example, with Groupwise, a user can give 
>permission to
>another to allow them to see what emails there are, on one extreme or give 
>another
>user full access, so that user A can send and receive mail as if he were user 
>B.
>
>Before I was introduced to phpGroupware, I supported, and still support, 
>Novell's
>Groupwise.  I have to say this compares quite favorably with it.  Keep up the 
>good
>work and I'll install it on every Linux server I build.
>
>Merry Christmas
>
>Tony (Angles) Puglisi (address@hidden) wrote*:
>>
>>When the message is moved from the source folder to the target folder (in 
>>this case
>>Trash), the most common practice (and preferred) is not to change any 
>>properties of
>>the message, in particular, the email app should preserve what is called the
>email's
>>"internal date", meaning the date it arrived on the server.
>>
>>That said, the email app *may* change certain things when moving mail around. 
>>I've
>>not done it, but I could look into it, but I really advise against changing 
>>the
>>"internal date" unless we find this is common practice with regards to trash
>folders.
>>
>>Perhaps a non-destructive (i.e. not changing the original "internal date") 
>>*could*
>>be to add an X-* header to the message, perhaps like this:
>>
>>X-trash-date: _RFC822_date_spec_here;
>>
>>BUT this requires the sorting to occur at the email client, since the email 
>>server
>>is "not programmed", generally, to sort in such a custom way. So if you have 
>>alot
>of
>>trash items, this *could* slow things down.
>>
>>Another alternative is to look into any "custom" flags that are being 
>>experimented
>>with in the IMAP rfc track. Things such as "recent" and "seen" are "server 
>>flags"
>>that are official IMAP RFC spec'd items, and these flags are set by the 
>>server or
>>client, and stored on the server. However, custom and/or experimental flags 
>>are
>>allowed, perhaps there is one for this type of thing.
>>
>>
>>
>>Chris Weiss (address@hidden) wrote*:
>>>
>>>>I would also like to add in as well that would be helpful is for the emails 
>>>>that
>>>>are put into the trash sorted by "newest message into the trash" instead of 
>>>>"date
>>>>stamp email was received".
>>>>
>>>
>>>I don't know how possible that is, I've never seen an IMAP client do 
>>>anything but
>>>sort by message recieved date, including Outlook+Exchange.
>>>
>>>
>>>_______________________________________________
>>>Phpgroupware-developers mailing list
>>>address@hidden
>>>
>>
>>
>>
>>_______________________________________________
>>Phpgroupware-developers mailing list
>>address@hidden
>>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>>
>
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>
--
that's "angle" as in geometry