EXPIRE

> I'm not sure the added complexity would buy us anything useful.  The
> EXPIRE setting can only be a rough guide to the user, never accurate
> (without some complex per-message expiration warning mechanism).  Even
> if the server presents the currently accurate value for a specific
> user, that value could change, the user doesn't know how long the
> message has already been on the server, and some servers could change
> the expiration period after the user has seen the message.

And for those exact reasons I oppose including EXPIRE. At best the information 
it provides is of marginal utility, and in practice, any incorrect/invalid 
data returned by EXPIRE will most likely result in lost mail. The only way I 
will support EXPIRE is if the protocol spec *requires* the server to enforce 
the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
on day n+1 you say EXPIRE 2, any operations I performed on day n must continue
to work within the constraints of the EXPIRE 30 information you gave me). If 
you cannot guarantee the semantics of operations based on EXPIRE data it 
doesn't belong in the protocol.

--lyndon