Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

Michael,

Many backend systems have their own email policies.   What you are 
describing seem to be more preferences or hints, which is good.  
End-users can use them (2822 expiration header) with their MUAs.  
Backends can use them too.

But most of this still goes under the auspices of backend server mail 
storage policies. 

For example, our backend offers policy options such as:

       Days to Expire READ Private mail:      7
       Days to Expire UN-READ Public or Private mail:  30
       Days to Expire External (sent) mail: 30

This is why in the MUA, like in Outlook, if you hit F1 for help in the 
account server setup dialog page for "Keeping mail on server" option(s) 
during mail pickup,  you will read the server storage policies may not 
honor these client options because the server has its own set of rules.

This server policy *always prevails* is a key point described in the 
POP3 RFC 1939, see section 8, "Scaling and Operational 
Considerations."    Showing one paragraph:

      Clients must not assume that a site policy will automate message
      deletions, and should continue to explicitly delete messages using
      the DELE command when appropriate.

Also, the CAPA  EXPIRE tag (RFC 2449) also may play a role here.

What I am saying, clients generally do not dictate server policies in 
these areas.   i.e.,  In our own security design, the MUA delete 
command, may actually function as a  "mark received" only at the 
server.   There is also an ergonomic (mail device) reason for that - 
Roaming users.   Many users will use an Offline MUA, even on different 
machines and also with an Online MUA. Many still want the ability to 
read "New Mail" on all devices.    So not marking for received or 
deletion allows different viewing methods until possibly the server 
unread expire mail policy, if any, kicks in.

For our system as well,  this growing need presented an audit design 
dilemma in areas of "notification messages."   When a high value 
message, a subscription and/or expiration message was posted for the 
user,   the roaming user need open the door to ideas for users saying 
they never received it.   It also could bypassed  Return Receipts.

In the end, redesigns may include the need for internal mail flags to 
provide full tracing of how mail was "picked up" or requested 
(regardless if it was read or not).   An unreceived expired message 
still needs to be recorded.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



Michael Welzl wrote:
> Dear all,
>
> When I get home from a trip, I am annoyed with the large
> number of emails that have already become pointless, as
> they are associated with a date in the past - talk
> announcements, calls for papers and such.
>
> Microsoft dealt with this issue using their "expiry-date" header,
> but in a non-standard-conforming way (the "expiry-date" header
> is deprecated). Now I wonder: why is there no standard which
> all email clients could support?
>
> If every email client on the planet would make it really, really
> easy and obvious for the user to set an expiry date when writing
> an email, I'm quite sure that a lot of people would make use
> of this feature.
>
> So we propose to standardize such a header. We would do this
> by reviving the "Expiry" part of
> http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15
> (we've been in touch with the draft's author, Jacob Palme,
> about this, and he likes the idea).
>
> We even already fulfil the standard IETF requirement of
> having two independent implementations:
> * one by Microsoft (not really standard conforming, but
>   still the same functionality)
> * ours, a plugin for Thunderbird to set the date when sending,
>   and a tool which logs into a pop server to automatically
>   detect expired emails and remark or delete them.
>
> Our software is available here:
> http://www.welzl.at/research/tools/email/index.html
>
> Please let us know what you think!
> (and if this is even the right place for this kind of discussion)
>
> Cheers,
> Michael Welzl  (and Thomas Nolf, in cc)
>
>
>
>