headers
Michael Welzl | 22 Jul 2008 11:15
Picon
Favicon

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


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
(Continue reading)

Permalink | Reply | 126 comments |
headers
Frank Ellermann | 22 Jul 2008 12:54
Picon
Picon

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


Michael Welzl wrote:

> 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)

Having a non-interoperable *different* idea is fortunately
not any "IETF requirement" I'm aware of... ;-)

> Please let us know what you think!

You would have to merge stuff from 2822upd for the general
syntax, check out:

<http://tools.ietf.org/html/draft-resnick-2822upd>

Then grab the equivalent NetNews header field syntax without
changing a single comma in it (for interoperability):

<http://tools.ietf.org/html/draft-ietf-usefor-usefor>

That is an approved RFC waiting for its number.  It is also
the source for the IANA registration of the Expires: header
field for NetNews.  (See section 3.2.5 and chapter 6)

There is one subtlety with the obsolete 2822(upd) syntax in
this RFC, see section 3.1.1.  Better stick to it, don't try
to create theoretical nightmares for news2mail gateways. ;-)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Moore | 22 Jul 2008 15:17

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


here's my question - what should _really_ happen when a message "expires"?

I keep most incoming messages for archival purposes.  So I wouldn't want 
my message store to delete them on my behalf - certainly not without my 
explicit consent.  What is "pointless" to you might not be pointless to 
me - even an announcement about a talk that happened before I got the 
announcement is useful information to me - it tells me that the talk 
happened, and there might be a video of it on youtube.

(otoh, the vast majority of calls for papers that I receive - for past 
or future events - are useless to me.  somehow conference organizers 
just Don't Get that they are spammers too)

the most I might want to do with an expiry date is
- for my MUA to optionally hide expired messages from me when displaying 
lists of messages (say in a folder)
- for my MUA to not notify me that I have new mail when an expired 
message arrives.

a similar question - when should a sender set an expiry date?

I'm not saying it's a bad idea, I'm saying that these issues are hard to 
sort out and that's probably why we haven't standardized it yet.

(and regardless of how we define a message's expiry date, getting users 
to understand how to use such things consistently is even harder.)

Keith
(Continue reading)

Permalink | Reply | 19 comments |
headers
Keith Moore | 22 Jul 2008 15:21

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


It's not at all clear that the Usenet notion of "expires" is right for 
email.  I'd look at X.400's expiry date as a starting point - at least 
it was designed with email in mind.

Keith

> Then grab the equivalent NetNews header field syntax without
> changing a single comma in it (for interoperability):
> 
> <http://tools.ietf.org/html/draft-ietf-usefor-usefor>
> 
> That is an approved RFC waiting for its number.  It is also
> the source for the IANA registration of the Expires: header
> field for NetNews.  (See section 3.2.5 and chapter 6)
Permalink | Reply | 1 comment |
headers
Michael Welzl | 22 Jul 2008 15:28
Picon
Favicon

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


On Tue, 2008-07-22 at 09:17 -0400, Keith Moore wrote:
> here's my question - what should _really_ happen when a message "expires"?
> 
> I keep most incoming messages for archival purposes.  So I wouldn't want 
> my message store to delete them on my behalf - certainly not without my 
> explicit consent.  What is "pointless" to you might not be pointless to 
> me - even an announcement about a talk that happened before I got the 
> announcement is useful information to me - it tells me that the talk 
> happened, and there might be a video of it on youtube.

That's what we have filters for! You could let your client
move the email to some subfolder, mark it somehow (light
grey in the list, whatever - up to your client), or just
delete it (like I would).

> (otoh, the vast majority of calls for papers that I receive - for past 
> or future events - are useless to me.  somehow conference organizers 
> just Don't Get that they are spammers too)

I'm sure that some of them would, if we would make it easy for
them to let their emails automatically disappear once they
become pointless. But "making it easy" means that this has
to be a visible and obvious feature in most email clients,
which IMO means that it has to be a standard first. Outlook
shows that people don't generally use that feature much as
long as it's not a standard.

Sure it's only a claim that people would use that feature
if it was a standard, but I say that this is worth trying.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Frank Ellermann | 22 Jul 2008 16:21
Picon
Picon

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


Keith Moore wrote:

> It's not at all clear that the Usenet notion of "expires"
> is right for email.  I'd look at X.400's expiry date as a
> starting point - at least it was designed with email in mind.

Apparently RFC 2156 defines "Expires:" - replacing an older
"Expiry-Date:" defined in RFC 1327.  Both about X.400, with
a reference in RFC.ietf-usefor-usefor-12 to RFC 2156.

The IANA registry for the mail "Expires:" and "Expiry-Date"
header fields still points to the initial registry RFC 4021.

RFC 4021 has references to RFC 1327 and 2156, noting that
RFC 1327 "Expiry-Date:" was replaced by RFC 2156 "Expires:".

The initial registry (4021) states that "Expires:" is "not
for general use", but for MIXER (2156).

Apparently one point of this procedural exercise is to get
rid of the "not for general use" note, and explain how an
"Expires:" header field with the known semantics "message
expiry time" can be generally useful (in mail).

The explanation in RFC.ietf-usefor-usefor covers the intent.
It doesn't go into details how this could be implemented by
a news server (that is the job of another memo), let alone
by UAs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Macdonald | 22 Jul 2008 17:08
Favicon

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


On Tue, 2008-07-22 at 11:15 +0200, Michael Welzl wrote:
> 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).

I like this. I'd retain this part as well:

"The word "client" may in this text designate functionality,
which some implementations actually implement wholly or partly
in a server. For example, in the case of IMAP and NNTP, it is
very common to implement functionality, which logically may be
regarded as belonging to a client, in the server."

No sense in sending a message if it is old in the first place. With
anti-spam systems delaying email for extended periods of time, this does
happen.

It is also unclear to me what the date-time field is suppose to look
like. It seems to be a RFC822 date updated to have 4 digit years. It
could also be:

22 Jul 2008 11:03 -0500

I'd rather have it be RFC3339 date format. But I have no idea how MS
deals with that.

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 22 Jul 2008 17:04

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


Michael Welzl wrote:
> On Tue, 2008-07-22 at 09:17 -0400, Keith Moore wrote:
>> here's my question - what should _really_ happen when a message "expires"?
>>
>> I keep most incoming messages for archival purposes.  So I wouldn't want 
>> my message store to delete them on my behalf - certainly not without my 
>> explicit consent.  What is "pointless" to you might not be pointless to 
>> me - even an announcement about a talk that happened before I got the 
>> announcement is useful information to me - it tells me that the talk 
>> happened, and there might be a video of it on youtube.
> 
> That's what we have filters for! You could let your client
> move the email to some subfolder, mark it somehow (light
> grey in the list, whatever - up to your client), or just
> delete it (like I would).

I'd love to believe that mail clients will be that flexible.  But I also 
have to consider that most mail clients today are still fairly primitive 
as to what they can do with existing headers.   My guess is that if 
expiry-date / expires is implemented at all, it will generally be 
implemented in the simplest possible way - e.g. by deleting the message 
silently.

>> (otoh, the vast majority of calls for papers that I receive - for past 
>> or future events - are useless to me.  somehow conference organizers 
>> just Don't Get that they are spammers too)
> 
> I'm sure that some of them would, if we would make it easy for
> them to let their emails automatically disappear once they
(Continue reading)

Permalink | Reply | 16 comments |
headers
Lisa Dusseault | 22 Jul 2008 19:14
Favicon

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


On Jul 22, 2008, at 8:04 AM, Keith Moore wrote:

>
> Let me repeat that I'm not opposed to standardizing this.  But it's  
> not clear to me that it would become a visible and obvious feature  
> in MUAs even if it were standardized.

I'd like to see commitments or indications from MUA implementors that  
they would plan to implement if it were standardized.

thanks,
Lisa
Permalink | Reply | 2 comments |
headers
Hector Santos | 22 Jul 2008 19:25
Favicon

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.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane