mailing list archives

I'm looking for recommendations as to what extensions make sense to
implement in my server.  Generally speaking, this is a mix of adding
true functionality and reasonably wide-spread client support.  I've
already added IDLE and NAMESPACE; what else makes sense?

Bill

On Fri, 16 Mar 2007, Bill Janssen wrote:
> I'm looking for recommendations as to what extensions make sense to
> implement in my server.  Generally speaking, this is a mix of adding
> true functionality and reasonably wide-spread client support.  I've
> already added IDLE and NAMESPACE; what else makes sense?

Going through the current set of standards-track and approved 
(SORT and THREAD are both blocked on i18n) extensions:

must-have:	LOGINDISABLED, STARTTLS
  ;; requirement of the specification

should-have:	MULTIAPPEND, SORT, THREAD, UIDPLUS
  ;; some clients are heavily impacted if absent

ought-to-have:	BINARY, IDLE, UNSELECT
  ;; some clients are impacted if absent

nice-to-have:	CATENATE, CHILDREN, CONDSTORE, ESEARCH, LITERAL+,
 		 NAMESPACE, SASL-IR, URLAUTH
  ;; some clients will benefit if present; note that CATENATE and
  ;; URLAUTH are part of the mandatory "trio" for Lemonade

if meaningful:	ACL, LOGIN-REFERRALS, MAILBOX-REFERRALS, QUOTA
  ;; may not be meaningful on your server

your choice:	ID
  ;; diagnostic purposes

Some people may disagree with me on some of these boundaries; consider 
them to be fuzzy.  I am aware of some clients which would consider some of 
the "nice-to-have" extensions important enough to kick up into a higher 
category.

The bottom line is that very few extensions stand out as being worthless 
with the possible exception of the two referral extensions, which seem to 
have fallen by the wayside.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Fri Mar 16 23:29:37 2007, Mark Crispin wrote:
> On Fri, 16 Mar 2007, Bill Janssen wrote:
>> I'm looking for recommendations as to what extensions make sense to
>> implement in my server.  Generally speaking, this is a mix of 
>> adding
>> true functionality and reasonably wide-spread client support.  I've
>> already added IDLE and NAMESPACE; what else makes sense?
> 
> Going through the current set of standards-track and approved (SORT 
> and THREAD are both blocked on i18n) extensions:
> 
> must-have:	LOGINDISABLED, STARTTLS
>  ;; requirement of the specification
> 
> should-have:	MULTIAPPEND, SORT, THREAD, UIDPLUS
>  ;; some clients are heavily impacted if absent
> 
> ought-to-have:	BINARY, IDLE, UNSELECT
>  ;; some clients are impacted if absent
> 
> nice-to-have:	CATENATE, CHILDREN, CONDSTORE, ESEARCH, LITERAL+,
> 		 NAMESPACE, SASL-IR, URLAUTH
>  ;; some clients will benefit if present; note that CATENATE and
>  ;; URLAUTH are part of the mandatory "trio" for Lemonade
> 
> 
I'd push NAMESPACE upward - clients using NAMESPACE at all are 
sometimes heavily impacted if this isn't available, and many will use 
it for some form of autoconfiguration.


> if meaningful:	ACL, LOGIN-REFERRALS, MAILBOX-REFERRALS, QUOTA
>  ;; may not be meaningful on your server
> 
> 
I'd put both ACL and QUOTA as nice-to-have - clients such as 
Thunderbird support ACL, and QUOTA is fairly common. That said, both 
are most often used in a read-only manner, and it's entirely legal to 
implement both on the server in a read-only way. Annoyingly, 
Thunderbird will generate errors if it cannot perform GETACL, so for 
ACL, you need both MYRIGHTS and GETACL.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Thanks; nice list.

Bill

I'm a bit confused on the UIDPLUS tag UIDNOTSTICKY.  RFC 4315 says,

      The selected mailbox is supported by a mail store that does not
      support persistent UIDs; that is, UIDVALIDITY will be different
      each time the mailbox is selected.  Consequently, APPEND or COPY
      to this mailbox will not return an APPENDUID or COPYUID response
      code.

My system will persist UIDs until the the server is re-booted for some
reason; that is, UIDVALIDITY may be different each time a mailbox is
selected, though it's not likely to be.  Depends on the frequency of
selection.  So UIDs tend to be persistent, but are not guaranteed to be.

Should I send UIDNOTSTICKY, or not?

Bill

On Fri, 16 Mar 2007, Bill Janssen wrote:
> My system will persist UIDs until the the server is re-booted for some
> reason; that is, UIDVALIDITY may be different each time a mailbox is
> selected, though it's not likely to be.  Depends on the frequency of
> selection.  So UIDs tend to be persistent, but are not guaranteed to be.
> Should I send UIDNOTSTICKY, or not?

You should not set UIDNOTSTICKY.  UIDNOTSTICKY is only when the 
UIDVALIDITY is never persistent.

HOWEVER!!  As a general "quality of implementation" issue, UIDVALIDITY 
SHOULD always be persistent for a mailbox.  The ONLY time that UIDVALIDITY 
should change is if a mailbox is deleted and a new mailbox with the same 
name is created.

UIDNOTSTICKY is an admission by the server that either the server or the 
mail store is of inferior quality that can not comply with the design 
requirements of IMAP UIDs.  Not announcing UIDNOTSTICKY, but changing the 
UIDVALIDITY on a mailbox is an admission by the server that either it or 
the mail store has an defect that caused it to fail to comply with the 
design requirements of IMAP UIDs.

Now, before people start jumping on me for saying such negative things 
about servers...let's note that the new mix format in UW imapd is the 
FIRST and ONLY mail store that is NOT inferior/defective by the above 
criteria.

Specifically, the mh, mtx, tenex, and arbitrary file formats are all 
"inferior", and the mbx, mmdf, mx, and traditional UNIX formats are all 
"defective".  The problems in those formats are due to legacy issues. 
One of the design goals of the mix format was to break free of legacy and 
not have those problems.

Put another way, UW imapd isn't "inferior"/"defective", but most of its 
supported mail stores (all but the newest mix format) are.  I am not happy 
about this; nor that it took me so long to come up with a mail store that 
didn't have this problem.

Any "inferior" or "defective" server and/or mail store causes considerable 
trouble to clients which depend upon UIDs for synchronization.  Only pure 
online clients such as Pine/Alpine will be relatively unscathed (and even 
Pine/Alpine uses UIDs for reply drafts to note the message being replied).

To be fair to UW imapd, the "defective" mail stores (most notably mbx and 
traditional UNIX) only show their defect under fault conditions; that is, 
something unexpected happened to screw things up.  Sadly, such faults do 
occur, and far more often than I (or my users!) like.  [Hence another 
motivation for mix format...]

Thus, unless you have legacy issues constraining you, you should exert 
heroic efforts to try to avoid inflicting yet another "inferior" or 
"defective" server and/or mail store on the world.  Yes, the 
specifications leave loopholes to allow it; but it should be considered 
embarassing to use those loopholes.  It's not "alright" to use those 
loopholes if you can avoid it.

Please try to have full sticky UIDs in your server and mail store.

[Do what I say, not what I do....]

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.