Re: [Dovecot] Sent vs Sent Items

2007-11-05 Thread Daniel Watts

Ed W wrote:
Religious wars about which is best aside - some mail clients seem to 
default to using Sent Items folder for saving sent mail, and others 
(many) default to Sent.


Seems that in the interests of compatibility and doing the right thing 
(tm) that a symlink from one folder to the other name would ensure that 
either default would give the same result (in a mixed client setup)?


However, I wonder if someone has already written a plugin to do 
something simple like this?  More generally I guess it's folder 
aliasing, so that Sent == Sent Items and perhaps there are also synonyms 
for Drafts/Templates?


Anyone got any thoughts on this simple idea? (The prob with sym links is 
a) creating them at mailbox setup time and b) what happens when someone 
tries to delete the folder...)


Cheers

Ed W



I agree it would be nice if the IMAP server could have an option to map 
a variety of folder names to a particular 'real' folder name. Not just 
Sent. I have also seen:


Trash vs Deleted Items





Re: [Dovecot] Sent vs Sent Items

2007-11-05 Thread Bill Cole

At 2:35 PM + 11/5/07, Daniel Watts wrote:

Ed W wrote:
Religious wars about which is best aside - some mail clients seem 
to default to using Sent Items folder for saving sent mail, and 
others (many) default to Sent.


Seems that in the interests of compatibility and doing the right 
thing (tm) that a symlink from one folder to the other name would 
ensure that either default would give the same result (in a mixed 
client setup)?


However, I wonder if someone has already written a plugin to do 
something simple like this?  More generally I guess it's folder 
aliasing, so that Sent == Sent Items and perhaps there are also 
synonyms for Drafts/Templates?


Anyone got any thoughts on this simple idea? (The prob with sym 
links is a) creating them at mailbox setup time and b) what happens 
when someone tries to delete the folder...)


Cheers

Ed W



I agree it would be nice if the IMAP server could have an option to 
map a variety of folder names to a particular 'real' folder name. 
Not just Sent. I have also seen:


Trash vs Deleted Items


While we're making a list: 'Junk' vs. 'Junk E-mail' is a particular 
problematic case of client disagreement because some clients (e.g. 
Eudora, Outlook) work in ways that are Very Bad when they disagree on 
the final destination of probable spam.


--
Bill Cole  
[EMAIL PROTECTED]




Re: [Dovecot] Sent vs Sent Items

2007-11-05 Thread Gerard Seibert
On Monday November 05, 2007 at 09:37:12 (AM) Bill Cole wrote:

 While we're making a list: 'Junk' vs. 'Junk E-mail' is a particular 
 problematic case of client disagreement because some clients (e.g. 
 Eudora, Outlook) work in ways that are Very Bad when they disagree on 
 the final destination of probable spam.

Correct me if I am wrong; however, there is no RFC specifically detailing the
naming of folders. If there is no specification in place, the author of a
software application is pretty much free to do as they please. The interesting
fact is that while you claim that clients like 'Eudora  Outlook' are bad, the
users of said clients might very well consider your choice of MUA to be
inferior.

Just my 2¢.


-- 
Gerard


A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?

TOPIC: Posting Etiquette



Re: [Dovecot] Sent vs Sent Items

2007-11-05 Thread Uldis Pakuls

Gerard Seibert wrote:

On Monday November 05, 2007 at 09:37:12 (AM) Bill Cole wrote:
hile we're making a list: 'Junk' vs. 'Junk E-mail' is a particular 
problematic case of client disagreement because some clients (e.g. 
Eudora, Outlook) work in ways that are Very Bad when they disagree on 
the final destination of probable spam.



Correct me if I am wrong; however, there is no RFC specifically detailing the
naming of folders. 

Right

If there is no specification in place, the author of a
software application is pretty much free to do as they please.
No, not relay - if there is no specification,  things _must_ be 
configurable.
Or don't call your software IMAP client. Call it Cyrus, MS 
Exchange or Lotus Domino client..., if it ads restrictions where thy 
don't apply.



 The interesting
fact is that while you claim that clients like 'Eudora  Outlook' are bad, the
users of said clients might very well consider your choice of MUA to be
inferior.
  
Outlook Express have at less options to configure Sent items and 
Drafts alias. In Outlook you can specify only root namespace prefix.

Just my 2¢.
  
Anyway alias option would be good workaround for limited pseudo 
IMAPclients.


Uldis.



Re: [Dovecot] Sent vs Sent Items

2007-11-05 Thread Steffen Kaiser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 5 Nov 2007, Bill Cole wrote:

The problem is not what Eudora does with 'Junk' or what Outlook does with 
'Junk E-mail', but what the two of them end up doing to each other's junk 
when they are both looking at an IMAP account that has both folders.


I do have the same problem. I also want to globally set up some scripts 
and default filtering of SPAM (in particular). However, it is not as easy 
as to have two or more names for one physical folder:


a) You want to show up just one of them - depending on the connecting MUA.

b) There are MUAs using localized mailbox names. This is as much crap as 
the localized directories in Windows or the localized Re:.


I dropped the idea of having two names for a pseudo-standard mail folder, 
instead each users must enter the particular mailbox names via 
Webinterface to let the scripts kick in.


Bye,

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRzAY+y9SORjhbDpvAQL/UwgAipm6qlSPjxdJuElTKlQnGvc2NRs+Z4wz
aQqIxJhY2QzJ1fnGELNKI7MgRj55wws9NLcd2RJIg88mk48ipLu09pCtD5NHDODC
/b5Ijnm/EzymUYvRjVDkBqzERiant9bF3ENfxljpqWsFKCuRRaGn7WD226LkADPd
f708It47rKqyaZvlfIxgInRQHP+5APlgSIHgU9xC+WflTKp6jtm4yXnyypC0Aj3W
/7f2uLPWvwIzgNT5cx3SVaoIbQ6HYE1/xDCvTzbf50Eq7jt4u8/pTicb9573/63M
rCZHfNePZ/Rm0/CSR2I4BlMYXx62RLBxX9KhpRKov3JwAyYy2aoKRg==
=CoOd
-END PGP SIGNATURE-