Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Keith Moore <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Date: Thu, 31 Jul 2008 09:34:55 -0400
List-Id: <ietf-822.imc.org>

Charles Lindsey wrote:
> In <[email-masked]> Keith Moore <[email-masked]> writes:
> 
>> I think it's rather odd that people are arguing that a proposed 
>> extension to the 822 (i.e. user-to-user) protocol can only be used by 
>> what is arguably mail transport (or on the boundary between transport 
>> and the recipient's user agent).  It certainly doesn't belong in SMTP. 
>> Nor does it belong in a body part, since it's clearly a message-level 
>> function.
> 
> Eh? That header has no meaning whatsoever for RFC 2821 transport. Its only
> possible effects arise _after_ 'final delivery', at which point it is
> sitting in some sort of 'mailbox' (be it IMAP, POP3, or Hector's grand
> archive with alread-existing purging mechanisms). So the feature certainly
> has to be in an RFC 2822 header, if it exists at all.

agreed.

But the idea of a message store wasn't part of the original internet 
mail architecture. So it's not clear to everyone where its 
responsibilities lie.  If the message store is (as I believe) a part of 
the recipient's user agent then it should be neutral with respect to 
storing messages except when given explicit instructions by the recipient.

Unfortunately the market has swallowed the idea that the "network" has 
the right to interfere with traffic between sender and recipient, and 
that furthermore it has the right to do so without any accountability.

Which makes it very hard to build reliable communications systems.

Keith

To: [email-masked]
Xref: clerew local.mime:5473
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Thu, 31 Jul 2008 10:45:32 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I think it's rather odd that people are arguing that a proposed 
>extension to the 822 (i.e. user-to-user) protocol can only be used by 
>what is arguably mail transport (or on the boundary between transport 
>and the recipient's user agent).  It certainly doesn't belong in SMTP. 
>Nor does it belong in a body part, since it's clearly a message-level 
>function.

Eh? That header has no meaning whatsoever for RFC 2821 transport. Its only
possible effects arise _after_ 'final delivery', at which point it is
sitting in some sort of 'mailbox' (be it IMAP, POP3, or Hector's grand
archive with alread-existing purging mechanisms). So the feature certainly
has to be in an RFC 2822 header, if it exists at all.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5474
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header - now: draft-welzl-expires-00.txt
Date: Thu, 31 Jul 2008 11:05:12 GMT
Lines: 43
Sender: [email-masked]

In <[email-masked]> "Frank Ellermann" <[email-masked]> writes:

>- Expires-field = "Expires:" CFWS date-time [CFWS] CRLF
>+ Expires-field = "Expires:" SP date-time CRLF

>| It is additionally defined in a similar way in
>| netnews [5]. 

>Charles wrote it was the other way around, Netnews
>had it first, later MIXER adopted it; fight it out.

Actually, I got it slightly wrong. The Expires header field as defined in
RFC 2156 has the same syntax as we require here (apart from that Netnews
SP, which I think we should omit - we tried, and failed, to get wording
in RFC 2822-bis to fix that).

The _real_ mess in RFC 2156 is that they also re-invented the (widely used
but then undocumented) Netnews Supersedes header field, and gave it the
wrong syntax, necessitating special wording in USEFOR to explain the
discrepancy.

Interestingly, RFC 2156 provides no semantics for the Expires header
(beyond recording the fact that the original X.400 message contained an
'expiry-time'). So any "MAY but MUST NOT" wording you write will probably
do no harm in the case of genuine gated-from-X.400 messages.

>You need a non-empty IANA considerations section to
>update the permanent message header field registry
>with a reference to RFC 3864.

Yes, and the template you provide will need to cover both RFC 2156 and
your new draft.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header - now: draft-welzl-expires-00.txt
Date:  Thu, 31 Jul 2008 13:58:34 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 30
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Michael Welzl wrote:

> Just this bit leaves me confused:
=20
>> The RFC-editor funding and the IETF Trust copyright
>> boilerplates are not more state of the art. =20

At the end of your draft you have an "acknowldegment"
with "funding for the RFC-editor is provided by the=20
IASA" (or similar), they don't do that anymnore. =20

That is at best a *nit* below the level of an IDnit,
they can strip it before publication, but apparently
your boilerplate isn't up to date.

Similar:  The copyright note on the front page was
removed.  That could be important if you need the=20
space for something else, e.g., a longer abstract,
or an editorial note.  Otherwise it is only a nit.

> (except for the "can't find the authors" problem)

I had that issue with an empty or blank organization,
that's a reported bug that will be fixed.  It's also
simple to bypass it, organization "foo" works.  But
your draft has non-empty oraganizations, therefore I
can't tell what the problem in your case is:  Report
it as a bug (on the Tools list, or via ietf-action@).

 Frank

From: "Michael Welzl" <[email-masked]>
To: <[email-masked]>
Subject: Re: Intent to revive "expires" header - now: draft-welzl-expires-00.txt
Date: Thu, 31 Jul 2008 08:03:17 +0200
Sender: [email-masked]

Hi,

Frank wrote:

> s/2234/5234/
> s/introduces a new/updates the known/g

and so on, and so forth: I agree with all of that and will accordingly
update the next revision, thanks a lot!

Just this bit leaves me confused:

>The RFC-editor funding and the IETF Trust copyright
>boilerplates are not more state of the art.  

I removed / added / changed this bit several times yesterday,
until I finally reached a state which was acceptable (except
for the "can't find the authors" problem) to the I-D submission
tool.

> This draft is not yet ready for an IETF Last Call :-)

... but we're almost there, aren't we?   :-D

Cheers,
Michael

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header - now: draft-welzl-expires-00.txt
Date:  Thu, 31 Jul 2008 03:22:37 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 44
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Michael Welzl wrote:

> Now go ahead and tear it to pieces  :-)

s/2234/5234/
s/introduces a new/updates the known/g

Split references in "normative" and "informative".
Don't worry about the problem "what if my RFC is
ready before 2822upd or the Netnews RFC?" at this=20
time.

- Expires-field =3D "Expires:" CFWS date-time [CFWS] CRLF
+ Expires-field =3D "Expires:" SP date-time CRLF

When I wrote "do not change a single comma in the
Netnews definition" I meant it:  <date-time> has
its own trailing [CFWS], and its own leading [FWS].
I kept the magic Netnews SP above, maybe remove it.

| It is additionally defined in a similar way in
| netnews [5].=20

Charles wrote it was the other way around, Netnews
had it first, later MIXER adopted it; fight it out.

| Such automatic removal without explicit instructions
| from the recipient is strictly forbidden for general
| Internet mail.=20

s/Such/Any/, as there is no "such" automatism in the
other specifications.

The RFC-editor funding and the IETF Trust copyright
boilerplates are not more state of the art. =20

You need a non-empty IANA considerations section to
update the permanent message header field registry
with a reference to RFC 3864.

You forgot RFC 2119 in the (normative) references.
This draft is not yet ready for an IETF Last Call :-)

 Frank

Date: Wed, 30 Jul 2008 17:33:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC: Chris Haynes <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:

> In reality, people may or may not follow the specs, and you
> can always have systems which misuse things that you prescribe -
> this is like the house that is then built based on the figure.

The fallacy in this logic is that there is presumption the figure 
(proposal) was correct to begin with.

I don't buy this cry that people don't follow specs, that they 
bastards, morons, idiots what have you.  Step back and try to 
understand why there might be varying implementations, why people 
(implementators) will not do what you say they should do, or even 
exactly under your terms.

To me, there are three kinds of RFC:

   1) One that make sense in entirely,
   2) One that makes partial sense,
   3) One that doesn't make sense at all.

Yet, all of them can be rubber stamped as gospel standards, and many 
are done with the smallest consensus where there might be a 
significant amount of "purged" disagreement.

This might explain why you might find "deviant" implementations.  Many 
are put into an ALL or nothing, or maybe even partial support, 
filtering what they like or don't like, reading ill-stated semantics 
to fit the desired usage which may under Pareto's Principle, work 
80-90% of the time with a high payoff.

The rhetorical question I have is whose fault is that?

IMV, this proposal falls under #2 above.

Worst, a key different with this proposal that it is unlike many others:

      In the attempt to add useful functionality for end-users,
      it attempts to mandate, not encourage a 'migrational'
      change, but mandate a drastic change in existing server behavior.

So I don't see how anyone can not expect this to not have a serious 
concern or impact or even agreement for endorsement.

Its not really about following the suggested semantics or a "figure" - 
it just might be that it wasn't quite right to begin with.

This idea is good. The way it is being proposed is, well, not good. :-)

-- 
HLS

Date: Wed, 30 Jul 2008 17:04:29 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Russ Allbery <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

Russ Allbery wrote:
> Keith Moore <[email-masked]> writes:
> 
>> yes, it's advisory in theory.  but in practice Expires in netnews means
>> "delete the message on or before this date" for very close to 100% of
>> the servers out there - precisely because in netnews the assumption is
>> that all messages will expire after a relatively short time anyway.
> 
> The part after the dash doesn't imply the part before the dash, and I
> think you're underestimating the number of servers that ignore Expires or
> set minimum expiration times that disable its effect.

+1. Thanks for pointing it out.

-- 
HLS

From: "Michael Welzl" <[email-masked]>
To: <[email-masked]>
Cc: "Thomas Nolf" <[email-masked]>, <[email-masked]>
Subject: Re: Intent to revive "expires" header - now: draft-welzl-expires-00.txt
Date: Wed, 30 Jul 2008 23:08:24 +0200
Sender: [email-masked]

Folks,

> > I think we are at the point where a fresh draft would be helpful.
> 
> Agreed. I think we're pretty close to something viable here.

Coincidentally, I finished the draft today and planned to submit it
tomorrow (it's evening here), but couldn't resist submitting it now
after seeing these comments.

Since I couldn't get the submission tool to identify the author's
information (god knows why - is there a new rule that I-D's cannot
have 3 authors perhaps?), I had to request manual posting. It should
appear in the directories within the next 2 work days.

Meanwhile, the document is available from:
http://www.welzl.at/research/tools/email/draft-welzl-expires-00.txt

Now go ahead and tear it to pieces  :-)

Cheers,
Michael

To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 30 Jul 2008 13:25:05 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> yes, and I agree that it makes a difference.  if a usenet message sender
> wants to delete a message that he has sent after a particular date, he
> can always issue a cancel for that message on that date.

He can, but such a message will do almost nothing, as in practice very few
servers honor cancels.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 30 Jul 2008 12:54:27 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> yes, it's advisory in theory.  but in practice Expires in netnews means
> "delete the message on or before this date" for very close to 100% of
> the servers out there - precisely because in netnews the assumption is
> that all messages will expire after a relatively short time anyway.

The part after the dash doesn't imply the part before the dash, and I
think you're underestimating the number of servers that ignore Expires or
set minimum expiration times that disable its effect.

> the definitions as stated are very similar, but the definitions have to
> be evaluated within their usage contexts - and the two contexts are very
> different.  basically the two contexts are so different that to use
> Expires in email would likely result in confusing, surprising, and
> undesirable behavior in email.

Okay.  It appears we simply have different opinions after looking at the
same data.  I will just register my complete disagreement with the above
paragraph for the record of the discussion.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 30 Jul 2008 20:38:48 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 15
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:
=20
> why is Expires: better than Expiry-Date:?

It's the same concept as in the MIXER and Netnews RFCs.

Nobody is going to explain to gateway operators that
they should map one to the other.  Another name gives
you nothing but block it at gateways.  Unless gateway
operators *try* to be smart, but hopefully they don't
when they are not forced to try it.

My flawed (and wrt "GiGo" very old) crystal ball says,

 Frank

Date: Wed, 30 Jul 2008 13:43:18 -0400
From: Tony Hansen <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Pete Resnick <[email-masked]>, Frank Ellermann <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

A thought just crossed my mind and I had to pass it on (because they're 
so rare, you know). Without further comment: "Expiry-Suggestion:"

	Tony

Keith Moore wrote:
> 
> Okay but why is Expires: better than Expiry-Date:? I have the impression 
> that existing uses of Expires tend to do the wrong thing whereas uses of 
> Expiry-Date tend to do the right thing or at least be benign.

Date: Wed, 30 Jul 2008 10:34:40 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Keith Moore wrote:

> > we're better off without a standard Expires header than with one
> > that would have the effect (intended or otherwise) of having such
> > messages be deleted without recipients' consent.

> IBTD.  No documented standard with strange variations in syntax in
> practice is worse than a clear standard with MUSTs and MUST NOTs.

+1. I spend way too much time on such messes already; anything we  can do to
eliminate them is a good idea IMO.

> Morons intentionally violating MUSTard are no compelling reason to
> "undocument" Expires:.  And this header field exists in the Mixer
> and Netnews RFCs, an attempt to "undocument" the idea is futile.

And more to the point, there appears to a move towards using it now, for
whatever reason. Sometimes when you brush these ideas off they go away, but
other times they move into wide use without agreed upon semantics.

> I think we are at the point where a fresh draft would be helpful.

Agreed. I think we're pretty close to something viable here.

				Ned

Date: Wed, 30 Jul 2008 09:40:45 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Pete Resnick <[email-masked]>
Cc: Keith Moore <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

> On 7/30/08 at 9:56 AM -0400, Keith Moore wrote:

> >Even if we say  that mail transport and message stores MUST NOT
> >delete messages on the basis of this new field without recipient
> >consent, implementors of such products will have a hard time
> >resisting the temptation to add such a feature which seems obviously
> >useful to them.

> So, I believe there is a saving grace here, and that we will be able
> to go ahead and use "Expires:" instead of
> "I-Dont-think-you-want-to-read-this-after:"...

> If, e.g., Microsoft were to implement message deletion based on the
> "Expires:" header in, e.g., Exchange, they would immediately be sued
> or otherwise have their heads handed to them. The reason is that they
> will instantly cause companies to be in violation of all sorts of
> corporate compliance laws and discovery orders. They simply can't do
> this. The power of corporate money is much greater than user
> complaints. So I don't think the "risk of idiocy" profile for
> "Expires:" is nearly as bad as other features we've seen abused in
> the past.

And by the same token, in many cases once the mandated retention period is
past, in order to limit what's discoverable many companies have strict
policites calling for forced deletion of most if not all email. I doubt it
makes sense to  have such mechanisms consider an Expires: field, but if a case
existed where it did it's safe to say it will work in whatever way is deemed to
miminize exposure to lawsuits, irrespective of anything that's said in an RFC.

> Now, will some web mail folks who already have draconian mail
> deletion policies use "Expires:" to start deleting that mail
> preferentially? Maybe not, because they have better things to do than
> to write code to search for "Expires:" and would rather just delete
> after some hard date. If they do, then as a user, I think I'd prefer
> them to preferentially delete "expired" messages rather than others.

Very good point.

> Either way, I think the damage potential here is minimal, and the
> gain, though also small, is reasonable for folks who want to use it.

+1

				Ned

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Wed, 30 Jul 2008 13:04:12 -0400
Cc: Frank Ellermann <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Okay but why is Expires: better than Expiry-Date:? I have the  
impression that existing uses of Expires tend to do the wrong thing  
whereas uses of Expiry-Date tend to do the right thing or at least be  
benign.

Sent from my iPod

On Jul 30, 2008, at 11:33 AM, Pete Resnick <[email-masked]>  
wrote:

> On 7/30/08 at 9:56 AM -0400, Keith Moore wrote:
>
>> Even if we say  that mail transport and message stores MUST NOT  
>> delete messages on the basis of this new field without recipient  
>> consent, implementors of such products will have a hard time  
>> resisting the temptation to add such a feature which seems  
>> obviously useful to them.
>
> So, I believe there is a saving grace here, and that we will be able  
> to go ahead and use "Expires:" instead of "I-Dont-think-you-want-to- 
> read-this-after:"...
>
> If, e.g., Microsoft were to implement message deletion based on the  
> "Expires:" header in, e.g., Exchange, they would immediately be sued  
> or otherwise have their heads handed to them. The reason is that  
> they will instantly cause companies to be in violation of all sorts  
> of corporate compliance laws and discovery orders. They simply can't  
> do this. The power of corporate money is much greater than user  
> complaints. So I don't think the "risk of idiocy" profile for  
> "Expires:" is nearly as bad as other features we've seen abused in  
> the past.
>
> Now, will some web mail folks who already have draconian mail  
> deletion policies use "Expires:" to start deleting that mail  
> preferentially? Maybe not, because they have better things to do  
> than to write code to search for "Expires:" and would rather just  
> delete after some hard date. If they do, then as a user, I think I'd  
> prefer them to preferentially delete "expired" messages rather than  
> others.
>
> Either way, I think the damage potential here is minimal, and the  
> gain, though also small, is reasonable for folks who want to use it.
>
> pr
> -- 
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax:  
> (858)651-1102

Date: Wed, 30 Jul 2008 16:33:42 +0100
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

On 7/30/08 at 9:56 AM -0400, Keith Moore wrote:

>Even if we say  that mail transport and message stores MUST NOT 
>delete messages on the basis of this new field without recipient 
>consent, implementors of such products will have a hard time 
>resisting the temptation to add such a feature which seems obviously 
>useful to them.

So, I believe there is a saving grace here, and that we will be able 
to go ahead and use "Expires:" instead of 
"I-Dont-think-you-want-to-read-this-after:"...

If, e.g., Microsoft were to implement message deletion based on the 
"Expires:" header in, e.g., Exchange, they would immediately be sued 
or otherwise have their heads handed to them. The reason is that they 
will instantly cause companies to be in violation of all sorts of 
corporate compliance laws and discovery orders. They simply can't do 
this. The power of corporate money is much greater than user 
complaints. So I don't think the "risk of idiocy" profile for 
"Expires:" is nearly as bad as other features we've seen abused in 
the past.

Now, will some web mail folks who already have draconian mail 
deletion policies use "Expires:" to start deleting that mail 
preferentially? Maybe not, because they have better things to do than 
to write code to search for "Expires:" and would rather just delete 
after some hard date. If they do, then as a user, I think I'd prefer 
them to preferentially delete "expired" messages rather than others.

Either way, I think the damage potential here is minimal, and the 
gain, though also small, is reasonable for folks who want to use it.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Chris Haynes <[email-masked]>, [email-masked], [email-masked]
Organization: University of Innsbruck
Date: Wed, 30 Jul 2008 17:13:36 +0200
Sender: [email-masked]

On Wed, 2008-07-30 at 04:07 -0400, Hector Santos wrote:
> The insanity as I see it:
> 
> A 2822 header proposal which is essentially is a *user feature 
> request* for MUA  *display rendering* is using the wrong term for the 

"display rendering" is given as a possible example. It could
also mean moving into a different folder or even deletion,
if explicitly allowed by the user.

> controlling header, yet at the same time, it attempts to 
> inconsistently use the wrong control header to eliminate long time 
> existing server storage automated expiration controls by shifting the 
> controls to the user with an astounding new twist - a *non-optional* 
> user permission mandate on the server retention policies - a major 
> conflictive change in the existing paradigm, a concept that never was 
> allowed and most likely will never be widely accepted.
> 
> IOW, in other to get the display to work, you need to change the 
> server behavior.
> 
> That is just plain nuts!
> 
> Bill is right. Call it something else, add classifications to it.
> Don't call it "Expires" if you don't want back ends and operators to 
> to use it in their mail-bots or try to tie it into existing automated 
>   expiration/purging processes.   Even if it was user permission 
> based, systems can get around that by making it default ON - forcing 
> the user to turn it off.

I'm against suggesting anything in the direction of the behavior
you describe above, but still could live with renaming it
(although I would against it, right now ... well, there seem
to be pro's and con's, as with any engineering problem)

Cheers,
Michael

Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Organization: University of Innsbruck
Date: Wed, 30 Jul 2008 17:11:01 +0200
Sender: [email-masked]

On Tue, 2008-07-29 at 21:49 -0400, Hector Santos wrote:
> Michael Welzl wrote:
> 
> >>     The Expires header indicates a date-time, at which this
> >>     message expires. The field can be used both to limit and to
> >>     extend the life of a message. User agents and servers which
> >>     employ automatic purging of old messages MAY let this field
> >>     influence the purging process. There is no requirement that a
> >>     user agent must suppress expired messages or make them
> >>     inaccessible to their owners.
> > 
> > Let's analyze the paragraph:
> > 
> > * sentence 1 is fine with me.
> > 
> > * sentence 2, "can be used both to limit and to extend" seems
> >   confusing and strange to me.
> 
> Not sure why that is odd to you.
> 
> If you have accepted the reality that backends already expire messages 
> regardless of flags or user permission, the question is how would this 

I changed my mind yesterday about sentence 1: it waters
the other statement that I want to have in there, about
only doing this when it's explicitly allowed by the user.

So, regarding "acceptance of this reality", sure I accept
that such things happen, but this is not what we design for.

Cheers,
Michael

Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Chris Haynes <[email-masked]>, RFC822 <[email-masked]>
Organization: University of Innsbruck
Date: Wed, 30 Jul 2008 17:07:46 +0200
Sender: [email-masked]

On Tue, 2008-07-29 at 15:58 -0400, Hector Santos wrote:
> Michael Welzl wrote:
> 
> > I don't understand that. I have seen wide agreement that we
> > don't want to specify behavior #1, so why do you call this
> > more realistic?
> 
> Because the practice of automatic purging already exist without any 
> flags, and clearly without user permission.  That is reality.
> 
> This proposal attempts to introduce a new header that would require a 
> change and alteration ($$$) of this existing design and practice.
> 
> IMO, this is asking much more than what is realistically more 
> possible, which is to simply state:
> 
>     Servers which employ automatic purging of old messages
>     MAY let this field influence the purging process.
> 
> Once there is a criteria of user permission, I think you can run into 
> an ugly game of users having a false illusion of controls they never 
> had in the first place.

I disagree. Prescribing and suggesting things is what RFCs should do;
this is like drawing an architectural figure.

In reality, people may or may not follow the specs, and you
can always have systems which misuse things that you prescribe -
this is like the house that is then built based on the figure.

Now saying that servers MAY let this field influence the
purging process (although we don't want them to, unless
given explicit permission by the user) is like saying that
the side wall of the kitchen may or may not end up being
totally straight at the corner of an architectural sketch,
just because this is how people build things sometimes.

Cheers,
Michael

Date: Wed, 30 Jul 2008 09:56:22 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Frank Ellermann wrote:
> Keith Moore wrote:
> 
>> then we disagree.  IMO, it's nearly always a disservice to
>> the Internet community for us to define a standard way to
>> do an undesirable thing.
> 
> I think we don't necesarily disagree about this principle,
> we apparently disagree that it is applicable for "Expires:".
> 
> An undesirable thing here would be applications ignoring the
> MUSTard in your proposed semantics.  But suppressing an idea
> because fools could intentionally ignore MUSTard is IMO odd.

It depends on how widespread such foolishness is.

1. Face it, most people don't know that RFCs even exist, so they have no 
idea whether their service providers, MUAs, or message stores conform to 
the MUSTs in those RFCs.  And while most implementors probably know that 
RFCs exist and are capable of finding them, many of them won't bother to 
  do enough research to find the "right" RFC for something like Expires 
that seems to have an obvious meaning.   Especially when there are 
several RFCs that mention the use of Expires in a different context.

This is the downside to having plain language header field names, and to 
reusing existing field names from other protocols/contexts.

2. There's also a strong tendency among implementors for creeping 
featurism, to add features that don't need to be there.  Even if we say 
  that mail transport and message stores MUST NOT delete messages on the 
basis of this new field without recipient consent, implementors of such 
products will have a hard time resisting the temptation to add such a 
feature which seems obviously useful to them.  It's mostly an ego thing, 
I think, but I don't see much hope in fixing it.

3. And there's still the problem of communicating what this means to 
users.  If we name the field "Less-Relevant-After" then user agents 
still need to give users the ability to set this field when composing 
mail, and they still need to give users the ability to search for such 
fields, flag such messages for deletion, etc.  and message stores need 
to give users the option of deleting "less relevant" messages.  It 
doesn't matter what we write in the RFC if users don't use the RFC. 
They'll just use the field in whatever way makes sense to them - 
assuming user agents give them ability to do so.

--

Really I think it mostly comes down to this:  Market conditions have 
resulted in crippled email user interfaces with no obvious way to 
improve the situation.  So whenever we talk about adding another field 
that gives users more control over messages or more flexibility, we're 
faced with the possibility that we'll see more implementation of this 
field (incorrectly) in message transport and message stores than we see 
in user agents.

That doesn't mean we shouldn't define new fields.  But maybe we ought to 
think hard about what's wrong with email user interfaces and what we can 
do to help unwedge them.  Rather than adding one new field at a time 
maybe we should consider what new features users really need, what it 
would take to make them usable, and what protocol extensions would help 
support them.

Keith

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 30 Jul 2008 14:57:29 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 34
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> then we disagree.  IMO, it's nearly always a disservice to
> the Internet community for us to define a standard way to
> do an undesirable thing.

I think we don't necesarily disagree about this principle,
we apparently disagree that it is applicable for "Expires:".

An undesirable thing here would be applications ignoring the
MUSTard in your proposed semantics.  But suppressing an idea
because fools could intentionally ignore MUSTard is IMO odd.

If the OP insists on it he can publish his idea anyway, e.g.,
as Internet drafts refreshed after 180 days for the next 44
years (I-D versions > 99 might not work).

Or as independent submission in an informational RFC, that's
in theory enough to get a new entry in the permanent message
header field registry.

The fine print of RFC 3864 would likely force him to pick a
new name, if the change controller for Expires: is the IETF.

He could get a provisional registration for "Colour-me-grey"
based on a first draft.  It is not possible to suppress his
idea if he and others insist on it. =20

I'd pick the "99 drafts" approach in this situation, because
a new name for an existing header field IMHO makes no sense.
In theory, in practice I don't care enough about "Expires:"=20
in e-mail to explore dark corners in Brian's marauder's map.

 Frank

Date: Wed, 30 Jul 2008 08:08:21 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Frank Ellermann wrote:
> Keith Moore wrote:
> 
>> we're better off without a standard Expires header than with one 
>> that would have the effect (intended or otherwise) of having such 
>> messages be deleted without recipients' consent.
> 
> IBTD.  No documented standard with strange variations in syntax in
> practice is worse than a clear standard with MUSTs and MUST NOTs.

then we disagree.  IMO, it's nearly always a disservice to the Internet 
community for us to define a standard way to do an undesirable thing.

(I say "nearly" because sometimes a feature is undesirable in general 
but there are corner cases when it is useful - though I don't think this 
is the case for "Expires" if that means that the message store or mail 
transport can delete the message without recipients' consent.)

Keith

Date: Wed, 30 Jul 2008 08:04:42 -0400
From: Keith Moore <[email-masked]>
To: Chris Haynes <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Chris Haynes wrote:

[ a bunch of stuff with which I agree, followed by: ]

> In my view:
> 
> 1) To introduce the Expires header with a semantic which permits the mail system to silently discard messages (wherever the message is at that time) would be bad requirements engineering,
> 
> 2) The only possible role for such a header would be as a 'hint' to recipients, who may opt to give their user agent permission to delete messages (probably selectively - based on sender, topic, etc). But such a 'hint' (and its implementation) should not be discussed and defined at the 822 architectural layer - it does not belong here.
> 
> So, FWIW, I think it is a bad idea to consider it in an 822 forum - whatever semantic is attached to it.

I think it's rather odd that people are arguing that a proposed 
extension to the 822 (i.e. user-to-user) protocol can only be used by 
what is arguably mail transport (or on the boundary between transport 
and the recipient's user agent).  It certainly doesn't belong in SMTP. 
Nor does it belong in a body part, since it's clearly a message-level 
function.

Where else can we put it?

Date: Wed, 30 Jul 2008 04:07:48 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Chris Haynes <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

The insanity as I see it:

A 2822 header proposal which is essentially is a *user feature 
request* for MUA  *display rendering* is using the wrong term for the 
controlling header, yet at the same time, it attempts to 
inconsistently use the wrong control header to eliminate long time 
existing server storage automated expiration controls by shifting the 
controls to the user with an astounding new twist - a *non-optional* 
user permission mandate on the server retention policies - a major 
conflictive change in the existing paradigm, a concept that never was 
allowed and most likely will never be widely accepted.

IOW, in other to get the display to work, you need to change the 
server behavior.

That is just plain nuts!

Bill is right. Call it something else, add classifications to it.
Don't call it "Expires" if you don't want back ends and operators to 
to use it in their mail-bots or try to tie it into existing automated 
  expiration/purging processes.   Even if it was user permission 
based, systems can get around that by making it default ON - forcing 
the user to turn it off.

--
HLS

Chris Haynes wrote:
> 
> On Wednesday, July 30, 2008 at 4:19:14 AM, Keith Moore wrote:
> 
>> IMHO, we're better off without a standard Expires header than with one
>> that would have the effect (intended or otherwise) of having such 
>> messages be deleted without recipients' consent.
> 
>> Keith
> 
> I argued yesterday that the _only_ possible semantic (relevant to an 822 discussion) is :
> 
> "After the given date the mail system MAY discard this message." 
> 
> This would be the Originator giving permission for the message to be deleted (without the recipient's knowledge or permission)- which would, I opine, be a technically-possible feature to add to an RFC.
> 
> So far I've been arguing from a strictly logical / architectural point of view.  
> 
> Let me now express a personal engineering judgement:
> 
> I think any kind of message deletion without the control or consent of the recipient would be a very bad idea.
> 
> 
> Consider this use case (based around Michael Welzl's original post):
> 
> a) Someone books a meeting and circulates the agenda to the invitees,
> 
> b) The departmental administrator is copied on the invite, so she can book the room,
> 
> c) That invitation has a 'Expires' header - set at the time of the meeting
> 
> d) The adminstator's mail system notices that it has the originator's 'permission' to delete the message and does so the next morning.
> 
> However:  
> 
> - The administrator wanted to keep that e-mail as a record of the room usage, for charging purposes and room utilisation analysis,
> 
> - The secretary of the meeting needed that eMail to help write up the minutes.
> 
> In other words, the message has a meaning and validity for some recipients beyond the knowledge or expectations of the originator. 
> 
> Decisions by the originator about the time the message is 'relevant' may be made in ignorance of the significance and validity of the contained information for all recipients.
> 
> In my view:
> 
> 1) To introduce the Expires header with a semantic which permits the mail system to silently discard messages (wherever the message is at that time) would be bad requirements engineering,
> 
> 2) The only possible role for such a header would be as a 'hint' to recipients, who may opt to give their user agent permission to delete messages (probably selectively - based on sender, topic, etc). But such a 'hint' (and its implementation) should not be discussed and defined at the 822 architectural layer - it does not belong here.
> 
> So, FWIW, I think it is a bad idea to consider it in an 822 forum - whatever semantic is attached to it.
> 
> Chris Haynes
> 
>  
> 
> 
> 

-- 
HLS

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 30 Jul 2008 09:58:13 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> we're better off without a standard Expires header than with one=20
> that would have the effect (intended or otherwise) of having such=20
> messages be deleted without recipients' consent.

IBTD.  No documented standard with strange variations in syntax in
practice is worse than a clear standard with MUSTs and MUST NOTs.

Morons intentionally violating MUSTard are no compelling reason to
"undocument" Expires:.  And this header field exists in the Mixer
and Netnews RFCs, an attempt to "undocument" the idea is futile.

I think we are at the point where a fresh draft would be helpful.

 Frank

Date: Wed, 30 Jul 2008 03:17:45 -0400
From: Keith Moore <[email-masked]>
To: Bill McQuillan <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

Bill McQuillan wrote:
> 
> On Tue, 2008-07-29, Russ Allbery wrote:
> 
>> Bill McQuillan <[email-masked]> writes:
> 
>>> In netnews the tradition is that the originator of a message "owns" it.
>>> Thus the author is empowered to cancel a message that he or she has
>>> posted and to suggest the lifetime of that message by using the
>>> "Expires:" field.
> 
>> I don't believe this is a correct characterization of how netnews works or
>> how the netnews protocol documents present control over message stores.
>> It is quite well-established in the Usenet world that the operator of a
>> news server has complete control over that message store, including
>> keeping messages for an arbitrary length of time, ignoring Expires,
>> rejecting all cancel messages, and so forth.  The original poster has no
>> control over the message within the protocol once it has left their
>> posting client; they can only provide advisory information and requests.
> 
> Actually, as I understand it an operator only has control of his own local
> store (and any downstream stores which soley depend on his feed.) The
> message I was refering to is a higher level entity that may be cached in
> many thousand stores that no one operator has control over.
> 
> Obviously, there are overrides possible in the real world, but the one
> person that usenet seems to treat as legitimate in sending a cancel message
> is the author. I do not claim that this is an integral part of the
> architecture, but it seems to me that it is a generally accepted feature of
> usenet but not of email.

yes, and I agree that it makes a difference.  if a usenet message sender 
wants to delete a message that he has sent after a particular date, he 
can always issue a cancel for that message on that date.  from that 
perspective, giving the usenet sender the ability to request deletion 
via Expires doesn't create a new capability - it just provides a more 
efficient/precise way to do what could have already been done via a 
cancel message.

Keith

Date: Wed, 30 Jul 2008 08:08:05 +0100
From: Chris Haynes <[email-masked]>
Reply-To: Chris Haynes <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re[2]: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Wednesday, July 30, 2008 at 4:19:14 AM, Keith Moore wrote:

> IMHO, we're better off without a standard Expires header than with one
> that would have the effect (intended or otherwise) of having such 
> messages be deleted without recipients' consent.

> Keith

I argued yesterday that the _only_ possible semantic (relevant to an 822 discussion) is :

"After the given date the mail system MAY discard this message." 

This would be the Originator giving permission for the message to be deleted (without the recipient's knowledge or permission)- which would, I opine, be a technically-possible feature to add to an RFC.

So far I've been arguing from a strictly logical / architectural point of view.  

Let me now express a personal engineering judgement:

I think any kind of message deletion without the control or consent of the recipient would be a very bad idea.

Consider this use case (based around Michael Welzl's original post):

a) Someone books a meeting and circulates the agenda to the invitees,

b) The departmental administrator is copied on the invite, so she can book the room,

c) That invitation has a 'Expires' header - set at the time of the meeting

d) The adminstator's mail system notices that it has the originator's 'permission' to delete the message and does so the next morning.

However:  

- The administrator wanted to keep that e-mail as a record of the room usage, for charging purposes and room utilisation analysis,

- The secretary of the meeting needed that eMail to help write up the minutes.

In other words, the message has a meaning and validity for some recipients beyond the knowledge or expectations of the originator. 

Decisions by the originator about the time the message is 'relevant' may be made in ignorance of the significance and validity of the contained information for all recipients.

In my view:

1) To introduce the Expires header with a semantic which permits the mail system to silently discard messages (wherever the message is at that time) would be bad requirements engineering,

2) The only possible role for such a header would be as a 'hint' to recipients, who may opt to give their user agent permission to delete messages (probably selectively - based on sender, topic, etc). But such a 'hint' (and its implementation) should not be discussed and defined at the 822 architectural layer - it does not belong here.

So, FWIW, I think it is a bad idea to consider it in an 822 forum - whatever semantic is attached to it.

Chris Haynes

Date: Tue, 29 Jul 2008 23:46:12 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Tue, 2008-07-29, Russ Allbery wrote:

> Bill McQuillan <[email-masked]> writes:

>> In netnews the tradition is that the originator of a message "owns" it.
>> Thus the author is empowered to cancel a message that he or she has
>> posted and to suggest the lifetime of that message by using the
>> "Expires:" field.

> I don't believe this is a correct characterization of how netnews works or
> how the netnews protocol documents present control over message stores.
> It is quite well-established in the Usenet world that the operator of a
> news server has complete control over that message store, including
> keeping messages for an arbitrary length of time, ignoring Expires,
> rejecting all cancel messages, and so forth.  The original poster has no
> control over the message within the protocol once it has left their
> posting client; they can only provide advisory information and requests.

Actually, as I understand it an operator only has control of his own local
store (and any downstream stores which soley depend on his feed.) The
message I was refering to is a higher level entity that may be cached in
many thousand stores that no one operator has control over.

Obviously, there are overrides possible in the real world, but the one
person that usenet seems to treat as legitimate in sending a cancel message
is the author. I do not claim that this is an integral part of the
architecture, but it seems to me that it is a generally accepted feature of
usenet but not of email.

-- 
Bill McQuillan <[email-masked]>

Date: Tue, 29 Jul 2008 23:28:22 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

Russ Allbery wrote:
> 
> However, I don't think that difference poses any real difficulties for the
> definition of Expires.  Regardless of the expectation around when the
> message goes away, the existing netnews definition of the field is "this
> message will no longer be useful after this date, and you therefore may
> want to discard it."  This meaning is just as reasonable in e-mail as it
> is in netnews.  (In netnews, it also carries the additional meaning of
> "this message will be useful up until this date, so you might want to keep
> it for that long rather than discarding it earlier," which it will not
> have in e-mail due to different assumptions, but I don't think that's an
> issue.)
> 
> In both cases, the effect of the header is entirely advisory and is
> determined by the local policy of the recipient, not the sender.

yes, it's advisory in theory.  but in practice Expires in netnews means 
"delete the message on or before this date" for very close to 100% of 
the servers out there - precisely because in netnews the assumption is 
that all messages will expire after a relatively short time anyway.

by contrast with email, expiration is relatively uncommon, and when 
expiration is employed the default timeouts tend to be very much longer.

 > The proposed meaning for e-mail and the established meaning for
 > netnews are so similar that the only differences I see are
 > edge-case quibbling.  I think it would be very strange to use
 > a different name for the header in e-mail when basically the
 > same meaning is intended.

the definitions as stated are very similar, but the definitions have to 
be evaluated within their usage contexts - and the two contexts are very 
different.  basically the two contexts are so different that to use 
Expires in email would likely result in confusing, surprising, and 
undesirable behavior in email.

Keith

Date: Tue, 29 Jul 2008 23:22:15 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: Michael Welzl <[email-masked]>, Chris Haynes <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
> 
> Michael Welzl wrote:
> 
>> I don't understand that. I have seen wide agreement that we
>> don't want to specify behavior #1, so why do you call this
>> more realistic?
> 
> Because the practice of automatic purging already exist without any 
> flags, and clearly without user permission.  That is reality.
> 
> This proposal attempts to introduce a new header that would require a 
> change and alteration ($$$) of this existing design and practice.
> 
> IMO, this is asking much more than what is realistically more possible, 
> which is to simply state:
> 
>    Servers which employ automatic purging of old messages
>    MAY let this field influence the purging process.

...and that's just insane.   it gives filters license to degrade email 
reliability even more than they are already doing.

Keith

Date: Tue, 29 Jul 2008 23:19:14 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked], Michael Welzl <[email-masked]>, [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
> Thanks Ned for your X.4xx review here.
> 
> I agree, when it comes to gateway transformations lacking a 1 to 1 map, 
> there are things that require a design decision.  Sometimes you have no 
> choice but to follow the side, the rules, of the end-gate.

that's insane.  we might or might not be able to get people to do things 
well, but we absolutely do not have to propagate bad decisions made in 
the past.  herd mentality has no place in engineering.

IMHO, we're better off without a standard Expires header than with one 
that would have the effect (intended or otherwise) of having such 
messages be deleted without recipients' consent.

Keith

Date: Tue, 29 Jul 2008 22:18:37 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To:  [email-masked]
CC: Keith Moore <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Thanks Ned for your X.4xx review here.

I agree, when it comes to gateway transformations lacking a 1 to 1 
map, there are things that require a design decision.  Sometimes you 
have no choice but to follow the side, the rules, of the end-gate.

--
HLS

[email-masked] wrote:
> 
> So what does all this mean? It means that if you gateway to a pure X.400
> environment that rigorously follows all the rules and uses P7 to talk to 
> MUAs
> you end up with more or less the operational behavior Keith wants, 
> although the
> defaults may be to auto-discard. (I didn't find a default in the standard
> itself, which means it's probably operational-profile-specific.) 
> however, if
> you're dealing with a real-world implementation that doesn't use P7 or 
> worse,
> operates with an Internet rather than X.400 kant, you're not going to have
> per-user controls for this and you're likely to see such messages discarded
> automatically with no recourse.
> 
> I will also note that while we don't support X.400 any more, since the
> expiry-date check was implemented at the MTA level it is actually 
> something we
> still support doing. Of course I have no idea if anybody actually have the
> feature enabled any more - I suspect not but there's no way to be sure.
> 
>                 Ned

-- 
HLS

Date: Tue, 29 Jul 2008 21:49:21 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC:  [email-masked]
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:

>>     The Expires header indicates a date-time, at which this
>>     message expires. The field can be used both to limit and to
>>     extend the life of a message. User agents and servers which
>>     employ automatic purging of old messages MAY let this field
>>     influence the purging process. There is no requirement that a
>>     user agent must suppress expired messages or make them
>>     inaccessible to their owners.
> 
> Let's analyze the paragraph:
> 
> * sentence 1 is fine with me.
> 
> * sentence 2, "can be used both to limit and to extend" seems
>   confusing and strange to me.

Not sure why that is odd to you.

If you have accepted the reality that backends already expire messages 
regardless of flags or user permission, the question is how would this 
external flag be use to:

   - Expedite, accelerate an expiration? and/or

   - Allowed to override the default expiration by
     extending its life?

Example #1:

- Today is July 29, you got a new message.
- Sender has a Expires: date:  August 5, one week from now.
- MUA User has option "Leave Mail On Server for 30 days."
- Backend Policy has "Keep Received mail for 10 days." (August 8)

If the user with his offline MUA popped into the system and picked it 
   up on August 1:

     Does the backend expire the message come August 5?
     Does it ignore the Expires header and expires it on August 8?
     Does the MUA issue the delete on August 5 or August 29 (30
     days later)?

Example #2:

- Today is July 29, you got a new message.
- Sender has a Expires: date:  September 1
- MUA User has option "Leave Mail On Server for 30 days."
- Backend Policy has "Keep Received mail for 10 days." (August 8)

If the user with his offline MUA popped into the system and picked it 
   up on August 1:

     Does the backend expire the message come August 8?
     Does it follow and extend the life to September 1?
     Does the MUA issue the delete on August 29 (30 days later)?
     Does the MUA issue the delete on September 1 (Expire Header)?

Example #3:

- Today is July 29, you got a new message.
- Sender has a Expires: date:  August 5, one week from now.
- MUA User has option "Leave Mail On Server for 30 days."
- Backend Policy has "Keep Received mail for 10 days." (August 8)
- Backend Policy has "Keep UnReceived mail for 30 days." (September 1)
- The user has went on a two week vacation.

If the user with his offline MUA popped into the system and picked it 
   up on August 15:

     Does the backend expire the unreceived message come August 5?
     Does it wait until September 1?

How about if he come back until September 2?

etc.

> * The last sentence is not strict enough in my opinion. One
>   conclusion from this whole discussion that we're having here
>   is that the field should only be advisory. Hence I prefer
>   the stricter statement that Keith made, even when it's
>   unusual to prescribe behavior for user agents:
> 
> "Mail Filters MUST NOT consider an expired header field as criteria to 
> be considered for deleting the message unless given explicit 
> instructions to do so by the recipient"

Mail Filters, in the true sense, are a little different what is meant 
by backend servers data retention, automatic expiration and purging 
processes.

-- 
HLS

Date: Tue, 29 Jul 2008 16:33:31 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Charles Lindsey <[email-masked]>
CC:  [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Charles Lindsey wrote:

>> Hector Santos writes:
>>
>> In my view, the conflictive issues are:
>> 
>> 1) Servers which employ automatic purging of old messages
>>    MAY let this field influence the purging process.
>>
>> or
>> 
>> 2) Servers which employ automatic purging of old messages
>>    MUST NOT let this field influence the purging process.
>> 
>> or
>> 
>> 3) Servers which employ automatic purging of old messages
>>    SHOULD NOT let this field influence the purging process
>>    without USER PERMISSION.
> 
> But what do you mean be "servers" here? Surely you don't mean MTAs,
> because they are not in the business of storing messages (beyond maybe for
> 7 days or so trying to deliver a message, after which then bounce it back
> up the Return-Path as "undeliverable")?

Right. Not MTAs.

For one example, our framework is client/server RPC based.  Backend 
mail database servers.  Our SMTP, POP3, IMAP, WEB MAIL, GUI AGENT/JAVA 
  Servers are RPC clients to the RPC Mail Database server.   The 
server has a built-in mail purging/packing events from floating 
between 1am to 5am.  1am today, 2pm tomorrow, and so on.

Other systems have different designs and methods, but fundamentally, 
they all have the similar ideas in place.

> Or do you mean IMAP and POP servers? AFAICS, those are the _only_ places
> where some semantic action connected with the Expires header MIGHT be
> specified, and even there it would have to be a user-configurable option.

No, it can happen other places as described above.

I guess POP3 might be a consideration because POP3 has to gather its 
new (mail indexes for the POP3 client.   I guess I can see it where it 
might use a Expires criteria here to skip over those messages.

But if this standard became reality today, lets see, off the top of my 
head:

For the backend:

   - No doubt, it will be considered as part of the
     backend purging/packing system.  Thats a no brainer
     and most appropriate place *for us.*  Possible add options like:

     [X] Support RFC XXXX Expires Header
         [X] To Accelerate Expiration declared by Sender
         [_] Allow Extension of expiration declared by Sender

   - Consider added it to our automated nntp client.

For developers/operators:

   - Add functionality to support a "Date Comparison" so that
     operators/developers can add rules into their server-side
     scripts:

     [RULE #XXXX]
     if Headers["Expires"] GTE Today then reject|move|keep

I doubt we would provide the rule, but document it as new feature, and 
then you might find people liking this that they will add the rule. 
This is also where they might be add a user permission.

I can also see some extended new ideas as part of warning system where 
  mail is highlighted when it approaches 7, 4, 2, 1 days from 
expiration, etc.

The sky the limit with this one, or, nothing happens at all :-)

-- 
HLS

To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 29 Jul 2008 13:32:54 -0700
Sender: [email-masked]

Bill McQuillan <[email-masked]> writes:

> I believe that conflating netnews and email is very misleading here.
>
> The difference is in the concept of "ownership."
>
> In netnews the tradition is that the originator of a message "owns" it.
> Thus the author is empowered to cancel a message that he or she has
> posted and to suggest the lifetime of that message by using the
> "Expires:" field.

I don't believe this is a correct characterization of how netnews works or
how the netnews protocol documents present control over message stores.
It is quite well-established in the Usenet world that the operator of a
news server has complete control over that message store, including
keeping messages for an arbitrary length of time, ignoring Expires,
rejecting all cancel messages, and so forth.  The original poster has no
control over the message within the protocol once it has left their
posting client; they can only provide advisory information and requests.

> As far as Expires: is concerned, a conflict may seem to arise in the
> area of retention policy when a recipient is using an employer's systems
> and equipment to receive the message, but an analysis of the
> "ownerships" involved will usually resolve it. But notice that the
> Expires: does not come from either of the "owners" of the message.

Expires is not, either in Usenet nor in the proposal here for e-mail, a
command that must be followed.  It's additional metadata about the message
that can be used by any component in the processing flow as desired, or
ignored entirely.  It is frequently ignored on Usenet, or at least limited
within particular ranges.

There is a significant difference in this area between netnews and e-mail:
in netnews, all messages are assumed to expire at some point, so Expires
only provides input as to when that should happen.  The assumption in
e-mail is that all messages are retained forever in the absence of some
explicit action (user deletion, site-wide retention policy configuration,
etc.).

However, I don't think that difference poses any real difficulties for the
definition of Expires.  Regardless of the expectation around when the
message goes away, the existing netnews definition of the field is "this
message will no longer be useful after this date, and you therefore may
want to discard it."  This meaning is just as reasonable in e-mail as it
is in netnews.  (In netnews, it also carries the additional meaning of
"this message will be useful up until this date, so you might want to keep
it for that long rather than discarding it earlier," which it will not
have in e-mail due to different assumptions, but I don't think that's an
issue.)

In both cases, the effect of the header is entirely advisory and is
determined by the local policy of the recipient, not the sender.

The proposed meaning for e-mail and the established meaning for netnews
are so similar that the only differences I see are edge-case quibbling.  I
think it would be very strange to use a different name for the header in
e-mail when basically the same meaning is intended.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 29 Jul 2008 15:58:18 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC: Chris Haynes <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:

> I don't understand that. I have seen wide agreement that we
> don't want to specify behavior #1, so why do you call this
> more realistic?

Because the practice of automatic purging already exist without any 
flags, and clearly without user permission.  That is reality.

This proposal attempts to introduce a new header that would require a 
change and alteration ($$$) of this existing design and practice.

IMO, this is asking much more than what is realistically more 
possible, which is to simply state:

    Servers which employ automatic purging of old messages
    MAY let this field influence the purging process.

Once there is a criteria of user permission, I think you can run into 
an ugly game of users having a false illusion of controls they never 
had in the first place.

-- 
HLS

Date: Tue, 29 Jul 2008 10:16:33 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Tue, 2008-07-29, Michael Welzl wrote:

> On Tue, 2008-07-29 at 00:40 -0400, Hector Santos wrote:
>> Frank Ellermann wrote:
>> > Russ Allbery wrote:
>> > 
>> >> usepro doesn't define header fields.  Header fields are
>> >> defined in usefor.  From draft-ietf-usefor-usefor-11.txt:
>> > 
>> > ACK.  Keith kind of insisted that there must be some issue
>> > with news in the proposal for mail, and I double-checked
>> > that this isn't the case.
>> 
>> IMV, the only difference is that news processing does not have to 
>> concern itself with USER options.
>> 
>>     For news, Expires has been processed as a removal concept.
>>     i.e, the news article is no longer available and/or truncated.
>> 
>> Keith desires user permission.  Difficult to apply in news groups.

> but we're not redefinining Expires for newsgroups. There is
> some similarity between these two things here, but it's
> not exactly the same.

I believe that conflating netnews and email is very misleading here.

The difference is in the concept of "ownership."

In netnews the tradition is that the originator of a message "owns" it.
Thus the author is empowered to cancel a message that he or she has posted
and to suggest the lifetime of that message by using the "Expires:" field.

However the tradition in email is that once the message is sent it is
"owned" by the recipient. Thus we have requirements that each hop make best
efforts to deliver the message and not to frivolously drop it if delivery
ia delayed. We also have not smiled on various attempts to construct a
mechanism to cancel an email once sent but perhaps not yet read.

As far as Expires: is concerned, a conflict may seem to arise in the area
of retention policy when a recipient is using an employer's systems and
equipment to receive the message, but an analysis of the "ownerships"
involved will usually resolve it. But notice that the Expires: does not
come from either of the "owners" of the message.

-- 
Bill McQuillan <[email-masked]>

Date: Tue, 29 Jul 2008 08:35:13 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Keith Moore <[email-masked]>
Cc: Michael Welzl <[email-masked]>, [email-masked]
Sender: [email-masked]

> But since Expiry-Date is a MIXER field, I should probably go dig out my
> X.400 docs and check the X.400 definition to see if what we want is
> compatible with how they defined things way back when.

I'll save you the trouble. The formal definition of the expiry-time field
in X.411 is:

  7.2.11 Expiry Time

  The Expiry Time heading field (O) identifies when the authorizing users
  consider the IPM to lose its validity. It comprises a date and time.

    ExpiryTimeField ::= Time

This is from the 1999 version but I doubt it's materiallly different in earlier
or later revisions.

It should be noted that this is part of X.411, in the part that defines the
format for IPMs (interpersonal messages). The placement of the field
corresponds to that of a RFC 822 header, but in X.400 the separation between
header information (an end to end thing) and the envelope (in X.400, a wrappper
around the entire messae) is actually stronger than in Internet mail. (This
does not mean that actual implementations treat it this way, as we'll see
below.)

So those are the stated semantics of the field. I'd say they are fairly close
to what we've been discussing, although the use of the term "valid" is quite a
bit harsher than "relevant". However, this doesn't give much if any insight
into how X.400 implementations actually handled the field operationally. For
that there are three things to look at: (1) Related stuff in the X.400 series
documents, (2) The X.400 operational profiles, and (3) Actual implementations.

Prowling around in the various documents, there are error codes corresponding
to "expired message" in both the NDN and IPN formats. (It is unclear to me,
however, when the NDN codes are supposed to be used.) NDNs, or nondelivery
notifications, correspond pretty closelly to DSNs. NRNs, or nonrecipient
notifications, are similar to MDNs, but in this case the differences are pretty
substantial. (You cannot effectively gateway an NRN into an  MDN, for example.)

So here's a section of the text defining the NRN format:

  8.2.2 Discard Reason

  The Discard Reason non-receipt field (C) indicates why the subject IPM was
  discarded (subsequent to its delivery to
  the NRN's originator and prior to its receipt).

  [ ITU-T version:
    DiscardReasonField ::= ENUMERATED {
      ipm-expired (0),
      ipm-obsoleted (1),
      user-subscription-terminated (2),
      not-used (3) }
  | ISO/IEC version:
    DiscardReasonField ::= ENUMERATED {
      ipm-expired (0),
      ipm-obsoleted (1),
      user-subscription-terminated (2),
      -- The following value may not be supported by
      -- implementations of earlier versions of this Specification
      ipm-deleted (3),
     ... }
  ]

  This field may assume any one of the following values:

  a) ipm-expired: Auto-discard was in effect, expired IPMs were being discarded,
     and the time identified by the subject IPM's Expiry Time heading field had
      arrived.
  b) ipm-obsoleted: Auto-discard was in effect, obsolete IPMs were being
     discarded, and the Obsoleted IPMs heading field of another IPM, delivered
     to the NRN's originator, identified the subject IPM.
  c) user-subscription-terminated: The Interpersonal Messaging subscription of
     the NRN's originator was terminated.

  [ ITU-T version:
  d) not-used: Implementations shall not generate this value. However, since
     thisvalue is used by implementations conforming to ITU-T Recs. of the
     X.400-series | ISO/IEC 10021 to indicate ipm-deleted, messages may be
    encountered that contain this value.
  | ISO/IEC version:
  d) ipm-deleted: The subject IPM was deleted before receipt occurred. Where a
     message store is involved, deletion occurred before the IPM's status became
     processed.
  ]

So an IPMS (that's InterPersonal Message Store, what we call a Message Store or
just a Store)) does in fact have the capability to throw out an expired
message, and this is controlled by the auto-discard setting. Confirming, here's
the auto-discard description:

  12.3.1 Change Auto-discard

  The Change Auto-discard abstract operation enables or disables auto-discard,
  the automatic discard by the IPMS of expired or obsolete IPMs delivered to,
  but not yet received by the user.

  change-auto-discard ABSTRACT-OPERATION ::= {
    ARGUMENT SET {
      auto-discard-expired-IPMs [0] BOOLEAN,
      auto-discard-obsolete-IPMs [1] BOOLEAN} }

  When it auto-discards an IPM, the IPMS originates an NRN on the user's behalf
  if, and only if, one was requested of him by means of the
  Notification-requests component of the subject recipient specifier.

  This abstract operation has the following arguments:

  a) Auto-discard-expired-IPMs (M): Whether or not expired IPMs are to be
     auto-discarded. A Boolean.
  b) Auto-discard-obsolete-IPMs (M): Whether or not obsolete IPMs are to be
     auto-discarded. A Boolean.

In other words, each user can control whether or not auto-discard is in effect
for their mail. And if the auto-discard-expired bit in that setting is on then
expired messages are deleted and, if a receipt notification was requested, an
indication of that outcome is returned to the message originator.

This probably sounds pretty good at this point. But let's move on to the
second point: Operational profiles.

As you can probably tell from this example, the X.400 series specifications
nail syntax details down quite tightly. Operational behavior, howefver, is left
pretty open, with a lot of it depending on how implementors read between the
lines. This was considered unacceptable back in the day so various
organizations like, say, the US Government, developed operational profiles.

I used to have a copy of GOSIP, the profile done by the US Government, on
paper, but somwwhere along the line half of it got lost (half meaning a whole
3" ring binder stuffed to overflowing - yes, GOSIP is easily a full 6" stack of
paper). So I'm afraid I cannot look up how this is supposred to actually be
implemented. What I can say is that implenentation requirements could easily
vary a lot from one place to the next.

In terms of actual implementations, let me start by saying what ours does: We
map Expiry-date: to and from expiry-time. We provided no support for per-user
auto-discard settings. What we did provide was a configuration option check
expiry dates on in-transit messages and bounce them if the message has expired.
This setting is off by default.

This pretty clearly takes some liberties with how this is defined in X.400.
Why? Because in X.400 both final delivery and message receipt are well defined
events. In Internet email only final delivery is nailed down to a similar
extent. There is no "message has been received" event you can talk about with
any certainty in Internet mail. Accordingly, since the way we supported X.400
was to gateway it to the Internet world (the alternative of running two
separate stacks was deemed unacceptable), various things associated with
receipt ended up getting tacked on to final delivery. Including message
expiration.

So what about per-user control of auto-discard? It turns out these are part of
P7 (the X.400 equivalent of IMAP plus a little ACAP and some other stuff, kinda
sorta) and we never supported that. (P7 is optional and very few clients able
to use it were ever developed.) So this whole auto-discard mechanism was never
an issue for us. But not delivering expired messages was a requirement someone
had, so we implemented an option do it.

So what does all this mean? It means that if you gateway to a pure X.400
environment that rigorously follows all the rules and uses P7 to talk to MUAs
you end up with more or less the operational behavior Keith wants, although the
defaults may be to auto-discard. (I didn't find a default in the standard
itself, which means it's probably operational-profile-specific.) however, if
you're dealing with a real-world implementation that doesn't use P7 or worse,
operates with an Internet rather than X.400 kant, you're not going to have
per-user controls for this and you're likely to see such messages discarded
automatically with no recourse.

I will also note that while we don't support X.400 any more, since the
expiry-date check was implemented at the MTA level it is actually something we
still support doing. Of course I have no idea if anybody actually have the
feature enabled any more - I suspect not but there's no way to be sure.

				Ned

To: [email-masked]
Xref: clerew local.mime:5431
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Tue, 29 Jul 2008 10:28:47 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> Hector Santos <[email-masked]> writes:

>In my view, the conflictive issues are:

>1) Servers which employ automatic purging of old messages
>    MAY let this field influence the purging process.

>or

>2) Servers which employ automatic purging of old messages
>    MUST NOT let this field influence the purging process.

>or

>3) Servers which employ automatic purging of old messages
>    SHOULD NOT let this field influence the purging process
>    without USER PERMISSION.

But what do you mean be "servers" here? Surely you don't mean MTAs,
because they are not in the business of storing messages (beyond maybe for
7 days or so trying to deliver a message, after which then bounce it back
up the Return-Path as "undeliverable")?

Or do you mean IMAP and POP servers? AFAICS, those are the _only_ places
where some semantic action connected with the Expires header MIGHT be
specified, and even there it would have to be a user-configurable option.
But that is a matter to be dealt with in some future IMAP-bis or POP-bis
standard.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5429
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Tue, 29 Jul 2008 10:16:30 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Hector Santos <[email-masked]> writes:

>What is more realistic is the original intent of the I-D you 
>referenced in which you tried to revive the "Expires" header:

>    http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15

But that draft expired nine years ago. It need not influence us now.

>where it defines Expires as:

>    4. Expires:

>    Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF

>    The Expires header indicates a date-time, at which this
>    message expires. The field can be used both to limit and to
>    extend the life of a message. User agents and servers which
>    employ automatic purging of old messages MAY let this field
>    influence the purging process. There is no requirement that a
>    user agent must suppress expired messages or make them
>    inaccessible to their owners.

Though that is not an unreasonable definition, and is fully compatible
with the Netnews version.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5430
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Date: Tue, 29 Jul 2008 10:20:01 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>"Frank Ellermann" <[email-masked]> writes:

>> Reviving "Expires" is already a long shot, renaming it is a
>> waste of everybody's time.  I just checked usefor-usepro-09,
>> it doesn't even mention "Expires".

>Of course not; usepro doesn't define header fields.  Header fields are
>defined in usefor.  From draft-ietf-usefor-usefor-11.txt:

Indeed, because Usepro does not specify any protocol action that has to be
taken when this header is encountered (and if it did, it would only be a
"MAY"). The Usefor draft tells you everything you need to know about it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5432
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Tue, 29 Jul 2008 10:40:55 GMT
Lines: 56
Sender: [email-masked]

In <[email-masked]> Michael Welzl <[email-masked]> writes:

>Hi all,

>On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:

>[snip]

>> IMO, if we can't make this new proposal of a Sender define "expires" 
>> header consistent with already existing standard practices, then IMO, 
>> it should be call something else.

>To repeat the nice definition that Keith gave us, and which most
>of us seem to like:

>"The sender believes this message will be irrelevant 
>after the indicated date/time."

>- hence we could call it "Relevant-until:"

>The problem that I see with using a different name at this
>point is that "Expires" already exists, with roughly the
>meaning that we want - not only in the netnews context,
>but also for MIXER (RFC 2156), as a renamed version
>of the obsolete "Expiry-Date" field according to RFC 4021.
>Additionally, despite being obsolete, Expiry-Date is
>currently in use, in the way that we want, with MS Outlook.

Yes, but RFC 2156 is only concerned with messages gatewayed from X.400 so
as to preserve the X.400 expiry information (whatever that might mean). I
am sure that any non-standard usage by MS Outlook did not derive in any
way from RFC 2156.

<rant>
In fact, when RFC 1327 invented Expiry-Date, it was just fine. It wasn't
"broke", so when they came to do RFC 2156 Jacob Palme decided to "fix" it
by taking the widely used (but at that time undocumented) Expires header
from Netnews, changing its syntax and semantics, and building it in. All
of which was a severe embarassment when we came to do the proper Netnews
definition in Usefor. We should be delighted if some 2156-bis were to
change it back again.
</rant>

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Organization: University of Innsbruck
Date: Tue, 29 Jul 2008 10:55:33 +0200
Sender: [email-masked]

On Tue, 2008-07-29 at 00:40 -0400, Hector Santos wrote:
> Frank Ellermann wrote:
> > Russ Allbery wrote:
> > 
> >> usepro doesn't define header fields.  Header fields are
> >> defined in usefor.  From draft-ietf-usefor-usefor-11.txt:
> > 
> > ACK.  Keith kind of insisted that there must be some issue
> > with news in the proposal for mail, and I double-checked
> > that this isn't the case.
> 
> IMV, the only difference is that news processing does not have to 
> concern itself with USER options.
> 
>     For news, Expires has been processed as a removal concept.
>     i.e, the news article is no longer available and/or truncated.
> 
> Keith desires user permission.  Difficult to apply in news groups.

but we're not redefinining Expires for newsgroups. There is
some similarity between these two things here, but it's
not exactly the same.

> IMV, this is thee key philosophical issue here.   All I am saying is:
> 
>    Expiration already exist outside any externally declared
>    expiration related flag. For news Expires helps the process.
>    But User permission is not required for news or email
>    storage purging.  There are default settings already in place.
> 
> So if this EXPIRES is introduced as a standard, how does it change the 
> existing default expiration practice?

For a whole lot of messages / situations, we don't want the
existing default expiration practice - but I would still like
to have the new "Expires" field for these situations.

This is going back to the old list of examples at the beginning
of this discussion: calls for papers, talk announcements and such.
We don't want systems to automatically delete such emails, but
my MUA should show them in a special way.

> What I find difficult to swallow is the attempt to make this a backend 
> transparent concept - for offline MUA only.   I don't think that is 
> realistic.

The obsolete "Expiry-Date" header is still used by MS Outlook,
but I don't know of any backend system that would automatically
delete such emails (except maybe the Exchange server, but that
doesn't count because that would be intentionally so!)

> But calling it "Expires?"  Sorry, don't be surprise if someone uses 
> this outside the proposal intent to keep backends or operators from 
> using it.  Its too juicy.  Nothing like it exist (in email) to get rid 
> of mail with zero false positive. The sender says "On this date, this 
> message is no longer useful, valid, its useless",  rest assured it 
> will be taken literally and they are not going to wait for a user to 
> get rid of it, especially when their 3rd party offline user is not 
> prepare to support it.  Centralize systems will be the key beneficiary,

Go ahead: let your server automatically delete emails
carrying an "Expiry-Date" from MS Outlook if it looks like
the email would have expired, and see if your users would
love or hate you for doing that.

Cheers,
Michael

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Chris Haynes <[email-masked]>, RFC822 <[email-masked]>
Organization: University of Innsbruck
Date: Tue, 29 Jul 2008 10:47:22 +0200
Sender: [email-masked]

On Mon, 2008-07-28 at 23:51 -0400, Hector Santos wrote:
> Chris Haynes wrote:
> 
> > IMHO there can only be two possible 'meanings' attached to the header.
> > 
> > If it is intended to be received and understood by the 
>  > mail transportation system I contend that the only possible>
>  > semantic can be:
> > 
> > 1) "After the given date the mail system MAY discard this message." 
> > 
> > The only other possible use of the 'Expires' header (so far as an 
>  > RFC822 group is concerned) is as a transparent communication
>  > between originator and recipient. In this case:
> > 
> > 2A) The mail transportation system MUST transport the header 
>  >     without modification and,
> > 2B) MUST NOT pay any attention to its presence or absence.
> > 
> > It's my assertion that, with the architecture of today's mail systems, 
>  > these are the only two possible semantics we can discuss here.
> 
>  > Debate...
> 
> In my view, the conflictive issues are:
> 
> 1) Servers which employ automatic purging of old messages
>     MAY let this field influence the purging process.
> 
> or
> 
> 2) Servers which employ automatic purging of old messages
>     MUST NOT let this field influence the purging process.
> 
> or
> 
> 3) Servers which employ automatic purging of old messages
>     SHOULD NOT let this field influence the purging process
>     without USER PERMISSION.

Well put.

Let's settle for 3, but the way it was specified by Keith
is stricter and IMO better:

"Mail Filters MUST NOT consider an expired header field as criteria to 
be considered for deleting the message unless given explicit 
instructions to do so by the recipient"

Semantically, this is not very different from 1) - they MAY do so,
but they MUST NOT do so unless the user allows it. Regarding the
email that I just sent a minute ago, where I agreed to keep the
sentence 1), I now think that this sentence should not be there
because it dilutes what we're saying. That is, if we already say
that servers MUST NOT do so without user permission, it's pointless
to additionally say that they MAY do so.

> The key point is the acknowledgment for the existence of a long time 
> related practices that don't depend on any external expiration field 
> and how a new proposed expiration related field relates to it, change 
> it or alter the long time practice.
> 
> Keith wants #3 at the very least. I hope I am not mis-characterizing 
> Keith when I say he has long expressed a legitimate concern for false 
> positives and mailers not reaching their users.

I also want #3.

> I understand it, but #1 is more realistic. I deem a EXPIRES header 
> defined by a SENDER to have an exact intent thus a zero false positive 
> result. #3 would be nice for servers to begin offering the option. I 
> am only pointing out that #1 is already in play and it will very hard 
> to convinced backends to change these automatic practices in place. So 
> you can't hold them to it.  But for me, for our system, #3 would be a 
> compromise IMV.  It may not be for the next system.

I don't understand that. I have seen wide agreement that we
don't want to specify behavior #1, so why do you call this
more realistic?

Cheers,
Michael

Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Organization: University of Innsbruck
Date: Tue, 29 Jul 2008 10:36:41 +0200
Sender: [email-masked]

On Mon, 2008-07-28 at 13:25 -0400, Hector Santos wrote:
> Michael Welzl wrote:
> > Hi all,
> > 
> > 
> > On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:
> > 
> > [snip]
> > 
> > 
> >> IMO, if we can't make this new proposal of a Sender define "expires" 
> >> header consistent with already existing standard practices, then IMO, 
> >> it should be call something else.
> > 
> > To repeat the nice definition that Keith gave us, and which most
> > of us seem to like:
> 
> But is not realistic.

Why?

> What is more realistic is the original intent of the I-D you 
> referenced in which you tried to revive the "Expires" header:
> 
>     http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15
> 
> where it defines Expires as:
> 
>     4. Expires:
> 
>     Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF
> 
>     The Expires header indicates a date-time, at which this
>     message expires. The field can be used both to limit and to
>     extend the life of a message. User agents and servers which
>     employ automatic purging of old messages MAY let this field
>     influence the purging process. There is no requirement that a
>     user agent must suppress expired messages or make them
>     inaccessible to their owners.

Let's analyze the paragraph:

* sentence 1 is fine with me.

* sentence 2, "can be used both to limit and to extend" seems
  confusing and strange to me.

* sentence 3 is fine with me.

* The last sentence is not strict enough in my opinion. One
  conclusion from this whole discussion that we're having here
  is that the field should only be advisory. Hence I prefer
  the stricter statement that Keith made, even when it's
  unusual to prescribe behavior for user agents:

"Mail Filters MUST NOT consider an expired header field as criteria to 
be considered for deleting the message unless given explicit 
instructions to do so by the recipient"

> It is quite clear of the intent and the engineerings insights for 
> forth in the Expires header:
> 
>     ... servers which employ automatic purging of old messages
>     MAY let this field influence the purging process.
> 
> You can't ignore this.

ok.

cheers,
Michael

Date: Tue, 29 Jul 2008 09:15:00 +0100
From: Paul Smith <[email-masked]>
To: Hector Santos <[email-masked]>
CC: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
> The only way I see you can do this is to give it some obscure header 
> field name that 100% relates to user rendering.
>
> But calling it "Expires?"  Sorry, don't be surprise if someone uses 
> this outside the proposal intent to keep backends or operators from 
> using it.  Its too juicy.  Nothing like it exist (in email) to get rid 
> of mail with zero false positive. The sender says "On this date, this 
> message is no longer useful, valid, its useless",  rest assured it 
> will be taken literally and they are not going to wait for a user to 
> get rid of it, especially when their 3rd party offline user is not 
> prepare to support it.  Centralize systems will be the key beneficiary,
>
+1

I have no real problem with a header which says 'you may delete this 
message after this date' (IMHO, that's what 'expires' means). I have no 
problem at all with the concept of a header which says 'you may display 
this message in a different form after this date, to signify it's past 
its "best before" date', but calling that 'expires' leads to massive 
ambiguity IMHO (maybe that should be the name for it - 'Best-before: 
...' ;-) ).

You could say 'but the spec says the mail server MUST NOT delete it 
after that date' - but anyone who's been working with email for more 
than a few months should know that most people who should know better 
don't properly read/understand the standards. (TBH, if you're reading 
this mailing list, you're already in the minority of email software 
developers/admins!). How many times have you seen timeouts which breach 
the specs? How many times have you seen big ISPs have mail servers which 
either use or can't handle line endings other than CRLF? Have you seen 
POP3 servers which allow multiple concurrent logins to the same mailbox? 
(I have, from very large ISPs - in breach of the standard, with very 
confusing consequences). Many people read standards and then treat 'MUST 
NOT' as 'SHOULD NOT', 'MUST/SHOULD' as 'MAY', 'SHOULD/MAY NOT' as 'MAY' 
etc.  Let's not give them another gun to shoot themselves with.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Date: Tue, 29 Jul 2008 04:16:48 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], ietf-822 mailing list <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: mini BOF on mail standard maintenance
Sender: [email-masked]

The mini BOF mentioned at yesterday's applications area meeting on mail 
standard maintenance will be held today at 1pm in the Gallan Suite:

	http://tools.ietf.org/agenda/72/venue/?room=gallan-suite

Tony Hansen
[email-masked]

Date: Tue, 29 Jul 2008 00:40:31 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Frank Ellermann <[email-masked]>
CC:  [email-masked]
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Sender: [email-masked]

Frank Ellermann wrote:
> Russ Allbery wrote:
> 
>> usepro doesn't define header fields.  Header fields are
>> defined in usefor.  From draft-ietf-usefor-usefor-11.txt:
> 
> ACK.  Keith kind of insisted that there must be some issue
> with news in the proposal for mail, and I double-checked
> that this isn't the case.

IMV, the only difference is that news processing does not have to 
concern itself with USER options.

    For news, Expires has been processed as a removal concept.
    i.e, the news article is no longer available and/or truncated.

Keith desires user permission.  Difficult to apply in news groups.
IMV, this is thee key philosophical issue here.   All I am saying is:

   Expiration already exist outside any externally declared
   expiration related flag. For news Expires helps the process.
   But User permission is not required for news or email
   storage purging.  There are default settings already in place.

So if this EXPIRES is introduced as a standard, how does it change the 
existing default expiration practice?

What I find difficult to swallow is the attempt to make this a backend 
transparent concept - for offline MUA only.   I don't think that is 
realistic.

> [...min default max detail...]
>> thus leaving the question to site configuration.
> 
> Thanks for info.  That should be okay even for Hector's 
> groupware scenario.  Unless Keith finds something in his
> X.400 documentation invalidating his proposed semantics.

X.400 operations also had data retention policies that were NO user based.

I recall, back in the early 80s when I first got my feet wet with 
designing the early offline mail systems, the engineers and corporate 
lawyers meetings discussing the details over captured email with these 
new "offline mail systems" which we called "Emailator" on what was 
then the employees new terminals - Personal Computers.

Then again I worked under a top security clearance area, so there were 
natural security concerns regarding:

   - Requiring tempest computers (to guard against Russians
     parked outside in vans sniffing the electronic download
     or display signals),

   - Automatic Expirations of captured email, no user option,

   - Making sure PC's had storage destruction/scrabbling
     software was installed.

When I left to concentrate on my successful moonlight shareware 
product - Silver Xpress, the 3rd offline mail system of its kind, 
after TAPCIS and QMAIL Deluxe - the 1st for Fidonet,  there was never 
a time where there wasn't some form of automatic purging for the mail 
hosting system.  SX worked on 22 different online hosting systems. All 
of them had automatic purging.  Regardless of the network, the 
software, the system, it was always there.  So I find it somewhat 
shocking that there is attempt to stop this practice or labeling it as 
some obscene bastard operation.  Very odd.

The only way I see you can do this is to give it some obscure header 
field name that 100% relates to user rendering.

But calling it "Expires?"  Sorry, don't be surprise if someone uses 
this outside the proposal intent to keep backends or operators from 
using it.  Its too juicy.  Nothing like it exist (in email) to get rid 
of mail with zero false positive. The sender says "On this date, this 
message is no longer useful, valid, its useless",  rest assured it 
will be taken literally and they are not going to wait for a user to 
get rid of it, especially when their 3rd party offline user is not 
prepare to support it.  Centralize systems will be the key beneficiary,

-- 
HLS

Date: Mon, 28 Jul 2008 23:51:31 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Chris Haynes <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Chris Haynes wrote:

> IMHO there can only be two possible 'meanings' attached to the header.
> 
> If it is intended to be received and understood by the 
 > mail transportation system I contend that the only possible>
 > semantic can be:
> 
> 1) "After the given date the mail system MAY discard this message." 
> 
> The only other possible use of the 'Expires' header (so far as an 
 > RFC822 group is concerned) is as a transparent communication
 > between originator and recipient. In this case:
> 
> 2A) The mail transportation system MUST transport the header 
 >     without modification and,
> 2B) MUST NOT pay any attention to its presence or absence.
> 
> It's my assertion that, with the architecture of today's mail systems, 
 > these are the only two possible semantics we can discuss here.

 > Debate...

In my view, the conflictive issues are:

1) Servers which employ automatic purging of old messages
    MAY let this field influence the purging process.

or

2) Servers which employ automatic purging of old messages
    MUST NOT let this field influence the purging process.

or

3) Servers which employ automatic purging of old messages
    SHOULD NOT let this field influence the purging process
    without USER PERMISSION.

The key point is the acknowledgment for the existence of a long time 
related practices that don't depend on any external expiration field 
and how a new proposed expiration related field relates to it, change 
it or alter the long time practice.

Keith wants #3 at the very least. I hope I am not mis-characterizing 
Keith when I say he has long expressed a legitimate concern for false 
positives and mailers not reaching their users.

I understand it, but #1 is more realistic. I deem a EXPIRES header 
defined by a SENDER to have an exact intent thus a zero false positive 
result. #3 would be nice for servers to begin offering the option. I 
am only pointing out that #1 is already in play and it will very hard 
to convinced backends to change these automatic practices in place. So 
you can't hold them to it.  But for me, for our system, #3 would be a 
compromise IMV.  It may not be for the next system.

-- 
HLS

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Date:  Tue, 29 Jul 2008 01:31:25 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 17
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Russ Allbery wrote:

> usepro doesn't define header fields.  Header fields are
> defined in usefor.  From draft-ietf-usefor-usefor-11.txt:

ACK.  Keith kind of insisted that there must be some issue
with news in the proposal for mail, and I double-checked
that this isn't the case.

[...min default max detail...]
> thus leaving the question to site configuration.

Thanks for info.  That should be okay even for Hector's=20
groupware scenario.  Unless Keith finds something in his
X.400 documentation invalidating his proposed semantics.

 Frank

To: [email-masked]
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 28 Jul 2008 15:36:26 -0700
Sender: [email-masked]

"Frank Ellermann" <[email-masked]> writes:

> Reviving "Expires" is already a long shot, renaming it is a
> waste of everybody's time.  I just checked usefor-usepro-09,
> it doesn't even mention "Expires".

Of course not; usepro doesn't define header fields.  Header fields are
defined in usefor.  From draft-ietf-usefor-usefor-11.txt:

3.2.5  Expires

   The Expires header field specifies a date and time when the poster
   deems the article to be no longer relevant and could usefully be
   removed ("expired").

      NOTE: This header field is useful when the poster desires an
      unusually long or an unusually short expiry time.

   expires         =  "Expires:" SP date-time CRLF

   See the remarks under Section 3.1.1 regarding the syntax of
   <date-time> and the requirements and recommendations to which it is
   subject.

      NOTE: The Expires header field is also sometimes used in Email
      with a similar meaning; see [RFC2156].

INN implements Expires in the following fashion:

       The middle field, <default>, will be used as the expiration period
       for most articles.  The other two fields, <min> and <max>, only
       come into play if the article requests a particular expiration date
       with an Expires header.  Articles with an Expires header will be
       expired at the date given in that header, subject to the
       constraints that they will be retained at least <min> days and no
       longer than <max> days.

       If <min> is set to "never", no article matching that line will ever
       be expired.  If <default> is set to "never", no article matching
       that line without an explicit Expires header will ever be expired.
       If <max> is set to "never", Expires headers will be honored no
       matter how far into the future they are.

       One should think of the fields as a lower bound, the default, and
       an upper bound.  Since most articles do not have an Expires header,
       the second field is the most important and most commonly applied.

thus leaving the question to site configuration.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 28 Jul 2008 14:36:12 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Michael Welzl wrote:
 
> > So, when we weigh the pro's against the con's, is it worth
> > changing the name to "Relevant-until"? I'm not sure...

> Reviving "Expires" is already a long shot, renaming it is a
> waste of everybody's time.  I just checked usefor-usepro-09,
> it doesn't even mention "Expires".  Rumours that Netnews is
> wildly incompatible with your idea are slightly exaggerated,
> no reason to rename this beast to "Display-Grey-After"... :-)

+1

				Ned

Date: Mon, 28 Jul 2008 22:26:45 +0100
From: Chris Haynes <[email-masked]>
Reply-To: Chris Haynes <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re[2]: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Monday, July 28, 2008 at 5:58:31 PM, Bill McQuillan wrote:

> An Observation:

> Conceptually there is a difference between how long the information in the
> message is thought to be relevant versus how long the message itself is
> thought to be relevant.

> Perhaps some of the controversy here is due to conflating these two things.

Quite. 

To put it another way, there is continuing confusion over whether the originator is communicating an expiry date to the mail transport / storage system, or to the human recipient of the message.

IMHO there can only be two possible 'meanings' attached to the header.

If it is intended to be received and understood by the mail transportation system I contend that the only possible semantic can be:

1) "After the given date the mail system MAY discard this message." 

(This is regardless of whether or not it has been delivered and/or if the recipient has seen it.)

The only other possible use of the 'Expires' header (so far as an RFC822 group is concerned) is as a transparent communication between originator and recipient. In this case:

2A) The mail transportation system MUST transport the header without modification and 
2B) MUST NOT pay any attention to its presence or absence.

It's my assertion that, with the architecture of today's mail systems, these are the only two possible semantics we can discuss here.

Anything else is _incapable_ of being defined, implemented and used in an unambiguous, universal way; it would have to cross the architectural boundary between originating (non-technical) human and receiving technical machine.

Debate...

Chris Haynes

Date: Mon, 28 Jul 2008 13:25:44 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC:  [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:
> Hi all,
> 
> 
> On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:
> 
> [snip]
> 
> 
>> IMO, if we can't make this new proposal of a Sender define "expires" 
>> header consistent with already existing standard practices, then IMO, 
>> it should be call something else.
> 
> To repeat the nice definition that Keith gave us, and which most
> of us seem to like:

But is not realistic.

What is more realistic is the original intent of the I-D you 
referenced in which you tried to revive the "Expires" header:

    http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15

where it defines Expires as:

    4. Expires:

    Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF

    The Expires header indicates a date-time, at which this
    message expires. The field can be used both to limit and to
    extend the life of a message. User agents and servers which
    employ automatic purging of old messages MAY let this field
    influence the purging process. There is no requirement that a
    user agent must suppress expired messages or make them
    inaccessible to their owners.

It is quite clear of the intent and the engineerings insights for 
forth in the Expires header:

    ... servers which employ automatic purging of old messages
    MAY let this field influence the purging process.

You can't ignore this.

-- 
HLS

Date: Mon, 28 Jul 2008 09:58:31 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Mon, 2008-07-28, Keith Moore wrote:

> Offhand, I like Expiry-Date.  I don't like Expires because NetNews 
> deletes expired messages.

> But since Expiry-Date is a MIXER field, I should probably go dig out my 
> X.400 docs and check the X.400 definition to see if what we want is 
> compatible with how they defined things way back when.

An Observation:

Conceptually there is a difference between how long the information in the
message is thought to be relevant versus how long the message itself is
thought to be relevant.

Perhaps some of the controversy here is due to conflating these two things.

-- 
Bill McQuillan <[email-masked]>

To: [email-masked]
Xref: clerew local.mime:5416
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Mon, 28 Jul 2008 13:01:01 GMT
Lines: 19
Sender: [email-masked]

In <[email-masked]> "Frank Ellermann" <[email-masked]> writes:

>Good examples apparently require some kind of mailbot
>on the sender's side.  It is less useful for ordinary
>(sending) MUAs, e.g., "happy birthday" with Expires: 
>makes no sense, or does it ?

It should expire after exactly 364 days :-) .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5417
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Mon, 28 Jul 2008 13:08:44 GMT
Lines: 45
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Frank Ellermann wrote:

>>  
>>> behavior for mail-to-NetNews gateways should also be specified.
>> 
>> Transparent, "Expires:" can be kept as is (modulo magic SP in news)

>my concern here is that (as best I recall) in NetNews, Expires pretty 
>much means the message will get deleted after that date.  I haven't 
>looked at netnews in years but I seem to recall that expires used to be 
>used mostly with periodic postings like FAQs that were reissued (and 
>perhaps revised) on a regular basis.

There are in practice two usages in Netnews:

1). Subject: Bid for my widget on ebay, auction has 24 hours to run.

In practice, very few posters insert an Expires header in such cases,
which is a pity/nuisance.

2). This FAQ will be repeated in three months time. I have set the Expires
date for then; please kepp it for at least that long.

99% of Expires headers wou will see on Usenet are of this nature, and they
are usually associated with an intelligent use of the Supersedes header.

The second case appears to have no counterpart in Email, though it might
make some sort of sense with Mailing Lists.

So we are essentially discussing an Email usage of the first sort. Note,
however, that Keith's definition (regarding the Sender's intent) actually
makes good sense for both usages.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5415
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Mon, 28 Jul 2008 12:59:55 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Chris Haynes <[email-masked]> writes:

>On Tuesday, July 22, 2008 at 10:15:06 AM, 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).

>Many of the responses so far have expressed concern about what UAs might or might not do with this information.  Debating these UA technical options are secondary to two key questions:

>1) Would the widespread introduction / use of this header by senders
>cause any damage to / loss of messages in (unmodified) UAs as currently
>deployed?

Only if they were gatewayed into Netnews, in which case obeying the
Expires header would be a desirable "feature".

>2) Can the semantics of an 'expired' message be agreed and communicated
>in a clean, simplistic, non-technical way?

Keith's definition is about right, and is fully consistent with the
Netnews definition.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15
Date:  Mon, 28 Jul 2008 16:26:49 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 12
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Michael Welzl wrote:
=20
> So, when we weigh the pro's against the con's, is it worth
> changing the name to "Relevant-until"? I'm not sure...

Reviving "Expires" is already a long shot, renaming it is a
waste of everybody's time.  I just checked usefor-usepro-09,
it doesn't even mention "Expires".  Rumours that Netnews is
wildly incompatible with your idea are slightly exaggerated,
no reason to rename this beast to "Display-Grey-After"... :-)

 Frank

Date: Mon, 28 Jul 2008 09:15:53 -0400
From: Keith Moore <[email-masked]>
To: Michael Welzl <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Offhand, I like Expiry-Date.  I don't like Expires because NetNews 
deletes expired messages.

But since Expiry-Date is a MIXER field, I should probably go dig out my 
X.400 docs and check the X.400 definition to see if what we want is 
compatible with how they defined things way back when.

Keith

Michael Welzl wrote:
> Hi all,
> 
> 
> On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:
> 
> [snip]
> 
> 
>> IMO, if we can't make this new proposal of a Sender define "expires" 
>> header consistent with already existing standard practices, then IMO, 
>> it should be call something else.
> 
> To repeat the nice definition that Keith gave us, and which most
> of us seem to like:
> 
> "The sender believes this message will be irrelevant 
> after the indicated date/time."
> 
> - hence we could call it "Relevant-until:"
> 
> 
> The problem that I see with using a different name at this
> point is that "Expires" already exists, with roughly the
> meaning that we want - not only in the netnews context,
> but also for MIXER (RFC 2156), as a renamed version
> of the obsolete "Expiry-Date" field according to RFC 4021.
> Additionally, despite being obsolete, Expiry-Date is
> currently in use, in the way that we want, with MS Outlook.
> 
> So, when we weigh the pro's against the con's, is it worth
> changing the name to "Relevant-until"? I'm not sure...
> 
> 
> Cheers,
> Michael
> 
> 

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Mon, 28 Jul 2008 14:34:05 +0200
Sender: [email-masked]

Hi all,

On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:

[snip]

> IMO, if we can't make this new proposal of a Sender define "expires" 
> header consistent with already existing standard practices, then IMO, 
> it should be call something else.

To repeat the nice definition that Keith gave us, and which most
of us seem to like:

"The sender believes this message will be irrelevant 
after the indicated date/time."

- hence we could call it "Relevant-until:"

The problem that I see with using a different name at this
point is that "Expires" already exists, with roughly the
meaning that we want - not only in the netnews context,
but also for MIXER (RFC 2156), as a renamed version
of the obsolete "Expiry-Date" field according to RFC 4021.
Additionally, despite being obsolete, Expiry-Date is
currently in use, in the way that we want, with MS Outlook.

So, when we weigh the pro's against the con's, is it worth
changing the name to "Relevant-until"? I'm not sure...

Cheers,
Michael

Date: Sun, 27 Jul 2008 13:35:57 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Pete Resnick <[email-masked]>
CC: Paul Smith <[email-masked]>, [email-masked], Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Pete Resnick wrote:

>> Don't use the wrong header name just because someone else used it ages 
>> ago for something slightly different and then deprecated it and you 
>> want to un-deprecate it. Use the right header name, or don't use 
>> anything.
> 
> I'm sorry, but I'm not at all convinced by this. To repeat Frank, the 
> "Expires:" header field *in use today* in news is defined as follows:
> 
>    The Expires header field specifies a date and time when the poster
>    deems the article to be no longer relevant and could usefully be
>    removed ("expired").
> 
> That's almost precisely what we've been talking about: A field to
> indicate the date after which the *sender* thinks you could delete this 
> message. Do you have to delete it? No. Can you color it polka-dotted? Of 
> course. But the sender is indicating that, for all he cares, you can 
> delete it after this date.

Major differences between private email vs public conference or public 
group based systems.

The key difference Pete, is that in News we have a 1 to ALL mail mail 
conferencing system. There is no 1 to 1 private end-user relationship, 
sender/user contract concerns with news groups. There is no "You." It 
is govern as a whole by the system operator, the group conference or 
newsgroup manager, if any.

Expires makes sense for News here because we don't have these user 
concerns. It was less complicated than for a private 1 to 1 system 
where there is a "You."   For news, expires is parenthetically defined 
as Remove.  However the user can't remove group mail.  Only the system 
or moderator can. He generally can not delete/expire another sender's 
or author's posting into a newsgroup. The user can, and only if 
allowed, remove (CANCEL) his own posting.

IMTO, introducing a standard "Expires" header is most definitely going 
to be considered for its worth and consequences.  I can easily see how 
it may be implemented by backends and mail distribution software. 
Easily. And that may include having a default user permission option 
that the user has to turn off - not turn on first.

IMTO, my main point is I don't think you can ignore how a new standard 
header called "expires" relates to all kinds of existing practices, 
especially on servers.

 > Is there a potential that some bastard e-mail server will take
 > this to  mean that it should delete the message behind your
 > back without your permission?

Bastard?

It already happens in wide practice.  I am surprise to see this is a 
shocking and considered a bastard?

RFC 1939 specifically says there no violation regarding these 
policies. Nothing "bastard" about this common practice.

  *  Enforce a site policy regarding mail retention on the server.

    Sites are free to establish local policy regarding the storage and
    retention of messages on the server, both read and unread.  For
    example, a site might delete unread messages from the server after
    60 days and delete read messages after 7 days.  Such message
    deletions are outside the scope of the POP3 protocol and are not
    considered a protocol violation.

RFC 2449 (CAPA) specifically briefly touches on the concepts of data 
retention and automatic deletion policies.  Nothing bastard about this.

   Discussion:

   While POP3 allows clients to leave messages on the server, RFC
   1939 [POP3] warns about the problems that may arise from this,
   and allows servers to delete messages based on site policy.

   The EXPIRE capability avoids the problems mentioned in RFC 1939,
   by allowing the server to inform the client as to the policy in
   effect.  The argument to the EXPIRE capability indicates the
   minimum server retention period, in days, for messages on the
   server.

   EXPIRE 0 indicates the client is not permitted to leave mail on
   the server; when the session enters the UPDATE state the server
   MAY assume an implicit DELE for each message which was downloaded
   with RETR.

<note>
For our system, we make Server Retention a OPERATOR option per USER.
</note>

   EXPIRE NEVER asserts that the server does not delete messages.

   The concept of a "retention period" is intentionally vague.
   Servers may start counting days to expiration when a message is
   added to a maildrop, when a client becomes aware of the existence
   of a message through the LIST or UIDL commands, when a message
   has been acted upon in some way (for example, TOP or RETR), or at
   some other event.  The EXPIRE capability cannot provide a precise
   indication as to exactly when any specific message will expire.
   The capability is intended to make it easier for clients to
   behave in ways which conform to site policy and user wishes.  For
   example, a client might display a warning for attempts to
   configure a "leave mail on server" period which is greater than
   or equal to some percentage of the value announced by the server.

<note>
I wish Offline MUA followed this recommendation.
</note>

   If a site uses any automatic deletion policy, it SHOULD use the
   EXPIRE capability to announce this.

<note>
Notice this is a SHOULD. Servers are not required to
make automatic deletion policies a user permission based idea.
Online system are better server because they have control over the 
presentation of new options as they come.  Offline 3rd party based MUA 
isers suffer in this area.
</note>

   The EXPIRE capability, with a parameter other than 0 or NEVER, is
   intended to let the client know that the server does permit mail
   to be left on the server, and to present a value which is the
   smallest which might be in force.

   Sites which permit users to retain messages indefinitely SHOULD
   announce this with the EXPIRE NEVER response.

   If the expiration policy differs per user (that is, the EXPIRE
   argument might change after authentication), the server MUST
   announce in AUTHENTICATION state the smallest value which could
   be set for any user.  This might be the smallest value currently
   in use for any user (so only one value per server), or even the
   smallest value which the server permits to be set for any user.
   The server SHOULD append the token "USER" to the EXPIRE parameter
   in AUTHENTICATION state, to inform the client that a more
   accurate value is available after authentication.  The server
   SHOULD announce the more accurate value in TRANSACTION state.
   (The "USER" token allows the client to decide if a second CAPA
   command is needed or not.)

   A site may have a message expiration policy which treats messages
   differently depending on which user actions have been performed,
   or based on other factors.  For example, a site might delete
   unseen messages after 60 days, and completely- or partially-seen
   messages after 15 days.

   The announced EXPIRE value is the smallest retention period which
   is or might be used by any category or condition of the current
   site policy, for any user (in AUTHENTICATION state) or the
   specific user (in TRANSACTION state).  That is, EXPIRE informs
   the client of the minimum number of days messages may remain on
   the server under any circumstances.

   Examples:
       EXPIRE 5 USER
       EXPIRE 30
       EXPIRE NEVER
       EXPIRE 0

   The first example indicates the server might delete messages
   after five days, but the period differs per user, and so a more
   accurate value can be obtained by issuing a second CAPA command
   in TRANSACTION state.  The second example indicates the server
   could delete messages after 30 days.  In the third example, the
   server announces it does not delete messages.  The fourth example
   specifies that the site does not permit messages to be left on
   the server.

IMO, if we can't make this new proposal of a Sender define "expires" 
header consistent with already existing standard practices, then IMO, 
it should be call something else.

-- 
HLS

Date: Sun, 27 Jul 2008 12:44:27 +0100
To: Paul Smith <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Cc: Hector Santos <[email-masked]>, [email-masked], Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Sender: [email-masked]

On 7/26/08 at 9:49 PM +0100, Paul Smith wrote:

>Hector Santos wrote:
>>
>>Well, it shouldn't be called "Expires" then.  Call it something 
>>else.  I like "Color-me-Gray-Date:" <g>
>
>A 'color-me-grey-date:' header (or 'only relevant before' or 
>'pointless after' or whatever) would be much more acceptable to me 
>than 'expires' - the word 'expires' suggests that it means that the 
>message *expires* after that date. When it has expired, it is no 
>longer, it is bereft of life, gone to meet its maker etc etc.That's 
>different from 'colored grey' (or Norwegian Blue, if that's more 
>acceptable). If you mean 'expires' use 'expires'. If you mean 'less 
>relevant after' then call the header 'less-relevant-after'.
>
>Don't use the wrong header name just because someone else used it 
>ages ago for something slightly different and then deprecated it and 
>you want to un-deprecate it. Use the right header name, or don't use 
>anything.

I'm sorry, but I'm not at all convinced by this. To repeat Frank, the 
"Expires:" header field *in use today* in news is defined as follows:

    The Expires header field specifies a date and time when the poster
    deems the article to be no longer relevant and could usefully be
    removed ("expired").

That's almost precisely what we've been talking about: A field to 
indicate the date after which the *sender* thinks you could delete 
this message. Do you have to delete it? No. Can you color it 
polka-dotted? Of course. But the sender is indicating that, for all 
he cares, you can delete it after this date.

Is there a potential that some bastard e-mail server will take this 
to mean that it should delete the message behind your back without 
your permission? Absolutely. But those same servers do exactly that 
with Date: fields that are too old, or Received: fields they don't 
like, or From: fields that make them unhappy, or.... Suffice it to 
say, servers will do bad things. This isn't helping them to do bad 
things. (Of course, if it turns out that lots of servers start doing 
bad things, senders won't use Expires: in fear of bad things 
happening. Such is life.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sat, 26 Jul 2008 21:49:05 +0100
From: Paul Smith <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked], Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
>
> Well, it shouldn't be called "Expires" then.  Call it something else. 
>  I like "Color-me-Gray-Date:" <g>
>
> Calling it expires or anything close to it, and intentionally ignoring 
> the complete picture, IMV, will make it highly probable it will be 
> used not as it was intended.  Especially when it is get mixed in with 
> other 2822 expiration concepts - DKIM.
>
A 'color-me-grey-date:' header (or 'only relevant before' or 'pointless 
after' or whatever) would be much more acceptable to me than 'expires' - 
the word 'expires' suggests that it means that the message *expires* 
after that date. When it has expired, it is no longer, it is bereft of 
life, gone to meet its maker etc etc.That's different from 'colored 
grey' (or Norwegian Blue, if that's more acceptable). If you mean 
'expires' use 'expires'. If you mean 'less relevant after' then call the 
header 'less-relevant-after'.

Don't use the wrong header name just because someone else used it ages 
ago for something slightly different and then deprecated it and you want 
to un-deprecate it. Use the right header name, or don't use anything.

Date: Fri, 25 Jul 2008 21:51:25 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Bill McQuillan <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Bill McQuillan wrote:
> 
> The reason I proposed this was I am worried that it will be TOO easy for J.
> Random Sender to determine how my message store will be managed. IMHO the
> word "expires" carries so varied a meaning that I will have to struggle to
> make any reasonable use of it.
> 
> What I am willing to grant J. R. Sender is the ability to declare one (or
> more?) "status change" date-time(s) from *his* point of view. I'm hesitant
> to use the word "expires" for that status change, both because of the
> disconnect between the sender's opinion and the recipient's as well as the
> danger of server or client developers implementing what they believe is its
> "meaning".

At this point I agree that if we wish to keep this totally backend 
transparent (which is not possible for Online MUAs), but strictly for 
store and forward offline based mail readers, then it ought to use a 
different header terminology.

Using "Expires:" has too much potential to become central with mail 
operations.  Consider DKIM with its expiration tags.   The same issues 
will apply.  How does a system single source the design?   Most will 
prefer to consolidate the logic.

Remember, this this era, it is nature of operators and vendors will 
always look for a "better feature" to offer their customers, an 
automatic way of doing things.   If this is made a standard, rest 
assured it will be used on the backend one way or another.  It is too 
enticing for an era where we don't have too many sound "indicators" to 
make automated decisions. This one is a prime candidate to be one. 
Consider if there is abuse by spammers in an vain attempt to keep mail 
"active" as long as possible on MUA work spaces, some one is sure to 
add backend logic to zoom in how Expires tags.

If we wish to minimize backend handling, then it probably will help by 
giving it a header field name whose connotation implies "FOR END USER 
DISPLAY RENDERING" only. "Color-me-Gray-Date:" comes to mind :-)

But then again, for the online system, it still means the backend has 
to be aware of it too.

-- 
HLS

Date: Fri, 25 Jul 2008 19:04:13 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To:  [email-masked]
CC: Paul Smith <[email-masked]>, Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

[email-masked] wrote:
> 
>> > When you get down to it this is really about being able to manage
>> > ever-increasing amounts of email a litte more easily. If we try and 
>> take it
>> > further than that we'll lose focus and likely derail the entire 
>> proposal.
> 
>> I guess I'm with Bill on this. My main issue with an 'expires' header is
>> that it will mean many things to many people.
> 
> Then we'll just have to agree to disagree. I thought the definition Keith
> provided was just about right in nailing down the semantics for the field.
> I think anything tighter will prevent its use and anything looser will
> be so amorphous that we won't get any traction.
> 
>                 Ned

Well, it shouldn't be called "Expires" then.  Call it something else. 
  I like "Color-me-Gray-Date:" <g>

Calling it expires or anything close to it, and intentionally ignoring 
the complete picture, IMV, will make it highly probable it will be 
used not as it was intended.  Especially when it is get mixed in with 
other 2822 expiration concepts - DKIM.

-- 
HLS

Date: Fri, 25 Jul 2008 18:36:53 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Bill McQuillan <[email-masked]>
CC: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Bill McQuillan wrote:

> For example, a conference announcement might contain:
> 
> Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
>  Warning: 1 Sep 2008 17:00 -0400,
>  Event: 8 Sep 2008 08:00 -0400,
>  Expires: 12 Sep 2008 16:30 -0400
> 
> This could indicate that the invitions must be accepted by end of business
> 1 Aug, papers are due by end of business 1 Sep, the conference starts at 8
> am on 8 Sep and is over at 4:30 pm on the 12th. (One might also infer that
> the conference will be held in the US Eastern timezone.)
> 
> A MUA could be configured to change the color highlighting of the subject
> listing for each of these intervals and perhaps archive or delete it when
> the conference is over.
> 
> One advantage of this is that I doubt that any backend systems will try to
> interpret this field and do something unwanted.

And what if your doubt is wrong?  <g>

People, operators and even vendors in the name of Cooperative 
Competition will come up with all kinds of automated ideas, especially 
one where there is a real intent in getting rid of mail declared by 
the sender as useless.  And especially when the user is taking his 
sweet time getting rid of the storage - received or unreceived.

But I think you are the right track, don't call this "EXPIRE" or any 
terminology related to "expiration" for the proposed header.

Perhaps it can be:

   Irrelevancy-Date:
   Passe-Date
   Color-me-gray-Date:
   Useless-Reading-Material-Date:
   Never-Mind-Date:

<g>

-- 
HLS

Date: Fri, 25 Jul 2008 11:55:02 -0700 (PDT)
From: [email-masked]
Subject: Re: mail relay was: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Dave Crocker <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> Arnt Gulbrandsen wrote:
> >
> > Jeff Macdonald writes:
> >> Ok, you both lost me. Or Perhaps you are agreeing with me. How does a
> >> sending MTA know that final delivery has happened?
> >
> > It only knows that final delivery will happen, not that it has happened.

> It does not know that final delivery will happen.

> An "MX" host is an incoming boundary MTA (see email-arch) for email.  It
> typically does not know all of the valid addresses within the organization and
> it certainly cannot know about all of the possible errors that could prevent
> delivery, between the time the MX host takes receipt and final delivery finally
> happens (or doesn't.)

FWIW, more and more ingress MTAs are able to perform full address validation,
and may even know things like which users are over quota and hence unable to
receive mail.

There is enormous and increasing pressure to "front load" as much validation as
possible, in order to keep the load on spam and virus filters (which for many
sites constitues the biggest overhead in email processing by far).

However, no matter how smart you make ingress MTAs, there are always going
to be boundary cases where a message is acepted and subsequently found to be
undeliverable.  

> > If you've delivered to the best MX, then that's as far as SMTP takes the
> > message.

> This, too, is often incorrect.  Between the boundary MTA and final delivery can
> be multiple email hops, all using, or not using, SMTP.

Yep. There can also be hops across the Interet using protocols other than SMTP.
it's a big world out there, and it contains lots of varying practices.

And even if every site out there only operated a single MTA and never did any
internal routing, this still fails to take the autoforwarding case into
account. It is quite common for a message to arrive and through the use of
MTA-level aliases be sent right back out again.

> > The message may have a long way to go, but that's independent
> > of SMTP and DELIVERBY. For example, the recipient may use something like
> > Thunderbird offline, in which case the recipient's inbox at the server
> > is just another spool, emptied when the recipient polls.

> Folks seem to think that receipt by a host listed with an MX in the (presumably
> public) DNS is of fundamental import to for the end-to-end process of posting
> and delivering mail.  It doesn't.  It is merely one of a potentially large
> number of hops along the way.  In fact, the email architecture has little or no
> technical details that pertain to the operation or semantics of a boundary MTA...

Yes, but let's not confuse user handling of the messages they have received
after delivery with transport before delivery. For better or worse we have
defined things like fetching messages via POP as after-delivery email
management rather than transport.

				Ned

Date: Fri, 25 Jul 2008 11:51:18 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Fri, 2008-07-25, Michael Welzl wrote:

> On Thu, 2008-07-24 at 11:40 -0700, Bill McQuillan wrote:

>> Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
>>  Warning: 1 Sep 2008 17:00 -0400,
>>  Event: 8 Sep 2008 08:00 -0400,
>>  Expires: 12 Sep 2008 16:30 -0400

> Too much, too complicated.

Quite possibly. One of my character flaws is to over-generalize solutions.
I'm working on that.   ;-)

> Earlier in this thread, we discussed whether it would be
> realistic to assume that users would be able to properly
> use the "expired" feature. Now you propose much more,
> with quite complex associated semantics; I can already
> imagine the debates that we could be having in this
> group about the exact meaning of expires vs. warning vs.
> deadline vs. whatever.

I had actually thought of that and hoped that a set of agreed upon status
keywords would result. Perhaps I was too optimistic.

> I'd really like this to become widespread and truly used,
> and if there's any chance for that at all, I firmly believe
> that the only way to achieve this is to make it REALLY
> simple - easy to implement, and above all easy to
> understand for the users.

The reason I proposed this was I am worried that it will be TOO easy for J.
Random Sender to determine how my message store will be managed. IMHO the
word "expires" carries so varied a meaning that I will have to struggle to
make any reasonable use of it.

What I am willing to grant J. R. Sender is the ability to declare one (or
more?) "status change" date-time(s) from *his* point of view. I'm hesitant
to use the word "expires" for that status change, both because of the
disconnect between the sender's opinion and the recipient's as well as the
danger of server or client developers implementing what they believe is its
"meaning".

-- 
Bill McQuillan <[email-masked]>

Date: Fri, 25 Jul 2008 14:30:01 -0400
From: Chris Eastlund <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

 > Having a stricter definition would help IMHO, as the sender would 
have > a chance to know how the recipient will interpret it, and the
 > recipient will have a chance to know what the sender meant by it.

A stricter definition should tell the recipient exactly what the
sender meant, or at least exactly what it could mean per RFC.

I don't see anyway for this to predict how the recipient will
chose to interpret it.

Or at least the probably of determining the senders intention
is a lot higher than that of determining the recipients interpretation.

IMHO, unless a response is required from the recipient, the
recipients actual interpretation is moot.  All we can ask is that
the senders intention is clear.

Chris

Date: Fri, 25 Jul 2008 18:44:37 +0100
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: mail relay was: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Jeff Macdonald writes:
>> Ok, you both lost me. Or Perhaps you are agreeing with me. How does a 
>> sending MTA know that final delivery has happened?
> 
> It only knows that final delivery will happen, not that it has happened.

It does not know that final delivery will happen.

An "MX" host is an incoming boundary MTA (see email-arch) for email.  It 
typically does not know all of the valid addresses within the organization and 
it certainly cannot know about all of the possible errors that could prevent 
delivery, between the time the MX host takes receipt and final delivery finally 
happens (or doesn't.)

> If you've delivered to the best MX, then that's as far as SMTP takes the 
> message. 

This, too, is often incorrect.  Between the boundary MTA and final delivery can 
be multiple email hops, all using, or not using, SMTP.

> The message may have a long way to go, but that's independent 
> of SMTP and DELIVERBY. For example, the recipient may use something like 
> Thunderbird offline, in which case the recipient's inbox at the server 
> is just another spool, emptied when the recipient polls.

Folks seem to think that receipt by a host listed with an MX in the (presumably 
public) DNS is of fundamental import to for the end-to-end process of posting 
and delivering mail.  It doesn't.  It is merely one of a potentially large 
number of hops along the way.  In fact, the email architecture has little or no 
technical details that pertain to the operation or semantics of a boundary MTA...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 25 Jul 2008 10:39:11 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Paul Smith <[email-masked]>
Cc: [email-masked], Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Sender: [email-masked]

> > When you get down to it this is really about being able to manage
> > ever-increasing amounts of email a litte more easily. If we try and take it
> > further than that we'll lose focus and likely derail the entire proposal.

> I guess I'm with Bill on this. My main issue with an 'expires' header is
> that it will mean many things to many people.

Then we'll just have to agree to disagree. I thought the definition Keith
provided was just about right in nailing down the semantics for the field.
I think anything tighter will prevent its use and anything looser will
be so amorphous that we won't get any traction.

				Ned

Date: Fri, 25 Jul 2008 10:11:11 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header	from draft-ietf-mailext-new-fields-15
To: Jeff Macdonald <[email-masked]>
Cc: Keith Moore <[email-masked]>, ietf-822 <[email-masked]>
Sender: [email-masked]

> On Thu, 2008-07-24 at 09:49 -0400, Keith Moore wrote:
> > Jeff Macdonald wrote:
> > >
> > > On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
> > >> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis
> > >> of an Expired header field unless given explicit instructions to do so
> > >> by the recipient."
> > >
> > > I find it very desirable to have MTAs generate a bounce if the message
> > > is older than the Expired header.
> >
> > (What does it mean for a message to be older than a header contained
> > within the message?  I assume you mean "... if the date in the Expired
> > header is after the current date.")

> yep

> > Now it might also be useful if there were a MTS feature that would let
> > a
> > sender say "don't bother delivering this message if you can't get it
> > there before <date>".  But I don't think that's what we're talking
> > about
> > here.  (and if there were such a feature it should be implemented in
> > SMTP rather in the message header).

> it is what I was thinking and Ned rightly pointed out that DELIVERYBY
> handles what I was looking for.

> The only thing I don't like about that extension is it really needs a
> 3rd mode. If I understand the RFC correctly:

> * mode R
> means bounce message even if the DELIVERYBY time hasn't expired when
> delivering to an MTA that doesn't support DELIVERYBY

> * mode N
> means attempt to deliver when time has expired but notify the sender

> Neither of these does what I'd like. I need a mode that is like R but
> will deliver to MTAs that do not support DELIVERYBY. This way the
> originating can expire messages and doesn't have to worry if the rest of
> the world supports DELIVERYBY.

This would be a mode where, depending on the path the message took, in some
cases the message would bounce if delayed and in other cases it will simply be
delivered late with no notification to anybody. And not only would you get
different results for different recipients, different sender locations, or
both, you're also likely to get different results over time from
the same sender-location/recipient combinations.

Pretty major violation of the least astonishment principle here. I really have
to wonder if it is worth it.

> Unless of course I am mis-understanding section 4.1.4. I'm not sure how
> a sending MTA knows it is sending email to a relay. I'm assuming all
> receiving MTAs could be a relay.

The term "relay" here refers to sending the message on to another  system, as
opposed to performing final delivery on it.

				Ned

Date: Fri, 25 Jul 2008 18:06:07 +0100
From: Paul Smith <[email-masked]>
To: [email-masked]
CC: Bill McQuillan <[email-masked]>, RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

[email-masked] wrote:
> But even if there was justification for additional work on calendaring that
> isn't already being done somewhere else, it's a completely separate problem
> from message expiration. Message expiration is just about saying when, in the
> opinion of the sender, the content of a given message - whatever it happens to
> be - is no longer going to be useful. The semantics don't extend to inferring
> that a message with an expiration date necessarily describes some sort of event
> and that the expiration time is somehow related to the time of the event.
>
> When you get down to it this is really about being able to manage
> ever-increasing amounts of email a litte more easily. If we try and take it
> further than that we'll lose focus and likely derail the entire proposal.
>   
I guess I'm with Bill on this. My main issue with an 'expires' header is 
that it will mean many things to many people. That means that it will 
only be really useful if YOU set the expires header on messages you 
receive (which obviously is not going to be very common). Since most 
people seem to want it to be defined in a woolly way, it could mean 
absolutely anything, which means that there's only a limited amount you 
could actually do with it since you don't know what the sender actually 
meant it for. This woolliness is also going to mean that no one with any 
sense will set it, because they don't know what the recipient is going 
to do with it - some may mark it the message as more urgent if it has 
just expired, others might delete it - so the safest thing to do is not 
to set it at all...

Having a stricter definition would help IMHO, as the sender would have a 
chance to know how the recipient will interpret it, and the recipient 
will have a chance to know what the sender meant by it.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Date: Fri, 25 Jul 2008 07:55:51 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Bill McQuillan <[email-masked]>
Cc: RFC822 <[email-masked]>
Sender: [email-masked]

> On Thu, 2008-07-24, Chris Eastlund wrote:

> > Isn't this more of a calendar function than a cleanup function?

> > If I miss a meeting notice that has an EXPIRES header, I don't
> > want it deleted, I might want it highlighted so I can apologize for
> > missing the meeting.  And it would be nice if the MUA would slide
> > soon-to-expire messages to the top of some priority list.

> > Maybe it's a personal choice, but I don't want a third party being
> > able to set a firm date-to-disappear on mail in my inbox.

> This explosion of responses to the Expires header field proposal made me
> step back to see what the issue might be.

> I think that "expires" is not even the right concept here! It is phrased in
> such a way that most of us wanted to jump in and make sure that it doesn't
> interfere with *our own way* of managing email stores.

> I think that what might be needed here is something more positive and
> useful. The desire seems to be to allow the sender to categorize a message
> based on a datetime and allow a user to choose to do some automatic
> processing keyed to that header field.

> I suggest something like:

> scheduled = "Scheduled:" chron-desc *("," chron-desc)

> chron-desc = chron-name ":" date-time

> chron-name = "Invitation" |
>              "Event" |
>              "Vacation" |
>              "Deadline" |
>              "Warning" |
>              "Expires" |
>              chron-extension-name

> For example, a conference announcement might contain:

> Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
>  Warning: 1 Sep 2008 17:00 -0400,
>  Event: 8 Sep 2008 08:00 -0400,
>  Expires: 12 Sep 2008 16:30 -0400

> This could indicate that the invitions must be accepted by end of business
> 1 Aug, papers are due by end of business 1 Sep, the conference starts at 8
> am on 8 Sep and is over at 4:30 pm on the 12th. (One might also infer that
> the conference will be held in the US Eastern timezone.)

> A MUA could be configured to change the color highlighting of the subject
> listing for each of these intervals and perhaps archive or delete it when
> the conference is over.

> One advantage of this is that I doubt that any backend systems will try to
> interpret this field and do something unwanted.

Wow, for I minute I thought I was confused and reading the CALSIFY WG list.

Anyway, we already have a well defined format for specifying events,
invitations, and so on: iCalendar. (OK, it does need a little work,
which is why CALSIFY exists. But the basic format is done.) Quite a lot
of effort was expended to get agreement on this stuff. I see no point
in repeating any or all of that effort in a separate context.

But even if there was justification for additional work on calendaring that
isn't already being done somewhere else, it's a completely separate problem
from message expiration. Message expiration is just about saying when, in the
opinion of the sender, the content of a given message - whatever it happens to
be - is no longer going to be useful. The semantics don't extend to inferring
that a message with an expiration date necessarily describes some sort of event
and that the expiration time is somehow related to the time of the event.

When you get down to it this is really about being able to manage
ever-increasing amounts of email a litte more easily. If we try and take it
further than that we'll lose focus and likely derail the entire proposal.

				Ned

Date: Fri, 25 Jul 2008 12:47:47 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: mail relay was: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Fri, 25 Jul 2008, Arnt Gulbrandsen wrote:
> Jeff Macdonald writes:
> >
> > Ok, you both lost me. Or Perhaps you are agreeing with me. How does a
> > sending MTA know that final delivery has happened?
>
> It only knows that final delivery will happen, not that it has happened.

Final delivery won't happen if the message later gets bounced.

> If you've delivered to the best MX, then that's as far as SMTP takes the
> message.

SMTP can take it further if the message is relayed to an internal MTA
using non-MX routeing, and/or if the recipient address is forwarded
(aliased) somewhere else.

> The recipient's SMTP server won't know [what happens after final
> delivery], won't be able to control or prevent it. Since that's true
> even if it advertises DELIVERBY, I think it's acceptable to deliver to
> the best MX in R mode.

Yes, and the same goes for internal relaying and alias-forwarding.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST FITZROY: SOUTHWEST BECOMING VARIABLE 3 OR 4. MODERATE BECOMING
SLIGHT. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Fri, 25 Jul 2008 12:06:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: mail relay was: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Jeff Macdonald writes:
> Ok, you both lost me. Or Perhaps you are agreeing with me. How does a 
> sending MTA know that final delivery has happened?

It only knows that final delivery will happen, not that it has happened.

If you've delivered to the best MX, then that's as far as SMTP takes the 
message. The message may have a long way to go, but that's independent 
of SMTP and DELIVERBY. For example, the recipient may use something 
like Thunderbird offline, in which case the recipient's inbox at the 
server is just another spool, emptied when the recipient polls.

The recipient's SMTP server won't know that, won't be able to control or 
prevent it. Since that's true even if it advertises DELIVERBY, I think 
it's acceptable to deliver to the best MX in R mode.

Arnt

Date: Fri, 25 Jul 2008 11:07:44 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Thu, 24 Jul 2008, Arnt Gulbrandsen wrote:
>
> Isn't that what I said in the text you don't quote?

Yes. I just wanted to point out that "final delivery" has nothing to do
with MXs, and it is clearly defined in RFC 2821 so you don't need to
wonder about or guess at its meaning.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BAILEY FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6, INCREASING 7
AT TIMES. MODERATE OR ROUGH. SHOWERS WITH FOG PATCHES. MODERATE OR GOOD,
OCCASIONALLY VERY POOR.

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Fri, 25 Jul 2008 09:23:29 +0200
Sender: [email-masked]

On Thu, 2008-07-24 at 11:40 -0700, Bill McQuillan wrote:

[snip]

> I suggest something like:
> 
> scheduled = "Scheduled:" chron-desc *("," chron-desc)
> 
> chron-desc = chron-name ":" date-time
> 
> chron-name = "Invitation" |
>              "Event" |
>              "Vacation" |
>              "Deadline" |
>              "Warning" |
>              "Expires" |
>              chron-extension-name
> 
> For example, a conference announcement might contain:
> 
> Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
>  Warning: 1 Sep 2008 17:00 -0400,
>  Event: 8 Sep 2008 08:00 -0400,
>  Expires: 12 Sep 2008 16:30 -0400

Too much, too complicated.

Earlier in this thread, we discussed whether it would be
realistic to assume that users would be able to properly
use the "expired" feature. Now you propose much more,
with quite complex associated semantics; I can already
imagine the debates that we could be having in this
group about the exact meaning of expires vs. warning vs.
deadline vs. whatever.

I'd really like this to become widespread and truly used,
and if there's any chance for that at all, I firmly believe
that the only way to achieve this is to make it REALLY
simple - easy to implement, and above all easy to
understand for the users.

Cheers,
Michael

Date: Thu, 24 Jul 2008 17:59:11 -0400
From: Keith Moore <[email-masked]>
To: Jeff Macdonald <[email-masked]>
CC: Tony Finch <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: mail relay was: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Jeff Macdonald wrote:
> 
> On Thu, 2008-07-24 at 18:34 +0100, Tony Finch wrote:
>> On Thu, 24 Jul 2008, Arnt Gulbrandsen wrote:
>>> Not within the SMTP universe. The best-priority MX will do final delivery,
>>> whatever that means
>> RFC 2821 defines "final delivery" and it has nothing to do with MXs. It
>> simply means delivery into a message store or some other non-SMTP system.
> 
> Ok, you both lost me. Or Perhaps you are agreeing with me. How does a
> sending MTA know that final delivery has happened?

it doesn't.  only the receiving MTA can know this.

Keith

Date: Thu, 24 Jul 2008 17:58:29 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Expires: vs. Supersedes:
Sender: [email-masked]

Frank Ellermann wrote:
> Keith Moore wrote:
> 
>> there's a practical problem with gatewaying mail with
>> an expired header to netnews.
> 
> Gateway operators will manage.  Syntax and semantics are
> almost identical.

In theory, perhaps.  But we don't want the email expires to work the 
same way that it works in practice with netnews.  So if the semantics of 
the two turn out to be identical in practice, we would consider that a 
failure from the email perspective.

I'm a lot more concerned with having email work well, than I am with 
having email and netnews work the same way.

Keith

Subject: mail relay was: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Jeff Macdonald <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Organization: e-Dialog
Date: Thu, 24 Jul 2008 20:57:50 +0000
Sender: [email-masked]

On Thu, 2008-07-24 at 18:34 +0100, Tony Finch wrote:
> On Thu, 24 Jul 2008, Arnt Gulbrandsen wrote:
> >
> > Not within the SMTP universe. The best-priority MX will do final delivery,
> > whatever that means
> 
> RFC 2821 defines "final delivery" and it has nothing to do with MXs. It
> simply means delivery into a message store or some other non-SMTP system.

Ok, you both lost me. Or Perhaps you are agreeing with me. How does a
sending MTA know that final delivery has happened?

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Expires: vs. Supersedes:
Date:  Thu, 24 Jul 2008 20:45:41 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 19
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> there's a practical problem with gatewaying mail with
> an expired header to netnews.

Gateway operators will manage.  Syntax and semantics are
almost identical.  Mail2news (or v.v.) is typically used
for mailing list to newsgroup (or v.v.), and that limits
meaningful Expires: uses on both sides to "compatible".
=20
> not that I care a huge amount.  AFAICS netnews is dead.

Last time I checked it it was still alive and kicking, at
least the de.* part.  NANA* also still existed, but not
more what it used to be.  I read all mailing lists (incl.
this list) on a stand alone (=3D unrelated to Usenet) NNTP
server. =20

 Frank

Date: Thu, 24 Jul 2008 11:40:39 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Thu, 2008-07-24, Chris Eastlund wrote:

> Isn't this more of a calendar function than a cleanup function?

> If I miss a meeting notice that has an EXPIRES header, I don't
> want it deleted, I might want it highlighted so I can apologize for
> missing the meeting.  And it would be nice if the MUA would slide
> soon-to-expire messages to the top of some priority list.

> Maybe it's a personal choice, but I don't want a third party being
> able to set a firm date-to-disappear on mail in my inbox.

This explosion of responses to the Expires header field proposal made me
step back to see what the issue might be.

I think that "expires" is not even the right concept here! It is phrased in
such a way that most of us wanted to jump in and make sure that it doesn't
interfere with *our own way* of managing email stores.

I think that what might be needed here is something more positive and
useful. The desire seems to be to allow the sender to categorize a message
based on a datetime and allow a user to choose to do some automatic
processing keyed to that header field.

I suggest something like:

scheduled = "Scheduled:" chron-desc *("," chron-desc)

chron-desc = chron-name ":" date-time

chron-name = "Invitation" |
             "Event" |
             "Vacation" |
             "Deadline" |
             "Warning" |
             "Expires" |
             chron-extension-name

For example, a conference announcement might contain:

Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
 Warning: 1 Sep 2008 17:00 -0400,
 Event: 8 Sep 2008 08:00 -0400,
 Expires: 12 Sep 2008 16:30 -0400

This could indicate that the invitions must be accepted by end of business
1 Aug, papers are due by end of business 1 Sep, the conference starts at 8
am on 8 Sep and is over at 4:30 pm on the 12th. (One might also infer that
the conference will be held in the US Eastern timezone.)

A MUA could be configured to change the color highlighting of the subject
listing for each of these intervals and perhaps archive or delete it when
the conference is over.

One advantage of this is that I doubt that any backend systems will try to
interpret this field and do something unwanted.

-- 
Bill McQuillan <[email-masked]>

Date: Thu, 24 Jul 2008 20:18:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Tony Finch writes:
> RFC 2821 defines "final delivery" and it has nothing to do with MXs. 
> It simply means delivery into a message store or some other non-SMTP 
> system.

Isn't that what I said in the text you don't quote?

Arnt

Date: Thu, 24 Jul 2008 11:03:09 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Keith Moore <[email-masked]>
Cc: Hector Santos <[email-masked]>, [email-masked], Jeff Macdonald <[email-masked]>, ietf-822 <[email-masked]>
Sender: [email-masked]

> Hector Santos wrote:
> > Keith,
> >
> > I was referring to widely practiced Standard Email Compliance Policies
> > that include archiving, expiration, mining, etc following and/or meeting
> > required data retention regulations outside the considerations of user
> > rights.

> offhand, I don't see how an expires header field generated by a sender,
> especially one outside a recipient's enterprise, should affect this sort
> of data archiving at all.

In the case of compliance archiving, I agree. Just because a message expires
at some point doesn't change the fact that it was sent or received.

More generally, these sorts of hints may alter user behavior in various ways,
but what the user ended up doing is what counts.

Operational archiving and cleanup is another matter, however. The minute you
start talking about schemes that move messages to secondary storage, or expire
them after some period of time, you enter a realm where it makes quite a bit of
sense for operational policies to consider expiration dates.

> > Nothing insane, irresponsible or illegal about them.

> we'll probably just have to disagree about the insane part.  but you
> were referring to something different than I was.

Well, anyone who thinks this stuff is all sweetness and light really ought to
try reading the actual laws in various jurisdictions first. (SOX is an
excellent starting point.) Insane is too kind, actually, because that label
effectively absolves the authors of this dreck of responsibility for it.
Incompetent and unaware of technical realities comes a lot closer to the mark.

Mind you, I have no issue at all with the intent of these laws. The devil is
all in the details.

> > While you may not
> > feel is our job to bless the practice, I'm sure others will take all
> > these related issues into account. You made it quite clear your view
> > point;  backends MUST not deal with this header and if they do only with
> > user permission.  Well, the devil is in the details; e.g., if user
> > permission is provided (assuming it is even offered at all),  it can not
> > defeat what may be already in place.   It can only serve to accelerate
> > the expired classification.  Not extend it  - unless of course an
> > implementation wishes to consider that logic.

> and if the sender is allowed to accelerate the expired classification
> this can result in the sender being allowed to destroy evidence that
> might otherwise be retained on the recipient's system?  right.

Exactly. I suppose expiration dates might be relevant in some instances in that
setting one might speak to the sender's intent in some way, but it makes no
sense for compliance archiving to honor such a field.

				Ned

Date: Thu, 24 Jul 2008 18:34:10 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Thu, 24 Jul 2008, Arnt Gulbrandsen wrote:
>
> Not within the SMTP universe. The best-priority MX will do final delivery,
> whatever that means

RFC 2821 defines "final delivery" and it has nothing to do with MXs. It
simply means delivery into a message store or some other non-SMTP system.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: EAST OR SOUTHEAST 4 OR 5, INCREASING 6 AT
TIMES. SLIGHT BECOMING MODERATE. FOG PATCHES. GOOD, OCCASIONALLY VERY POOR.

Date: Thu, 24 Jul 2008 12:59:51 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Jeff Macdonald <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Jeff Macdonald wrote:
> Neither of these does what I'd like. I need a mode that is like R but
> will deliver to MTAs that do not support DELIVERYBY. This way the
> originating can expire messages and doesn't have to worry if the rest of
> the world supports DELIVERYBY.
>
> Unless of course I am mis-understanding section 4.1.4. I'm not sure how
> a sending MTA knows it is sending email to a relay. I'm assuming all
> receiving MTAs could be a relay.
Sending to a smart host?

-- 
HLS

Date: Thu, 24 Jul 2008 18:57:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Jeff Macdonald writes:
> Unless of course I am mis-understanding section 4.1.4. I'm not sure=20
> how a sending MTA knows it is sending email to a relay. I'm assuming=20
> all receiving MTAs could be a relay.

Not within the SMTP universe. The best-priority MX will do final=20
delivery, whatever that means =E2=80=94 I'd say it means the message =
crosses=20
the border from where SMTP applies to somewhere else, such as where=20
X.400 applies or where local policy applies.

Arnt

Date: Thu, 24 Jul 2008 12:44:21 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked], Jeff Macdonald <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
> Keith,
> 
> I was referring to widely practiced Standard Email Compliance Policies 
> that include archiving, expiration, mining, etc following and/or meeting 
> required data retention regulations outside the considerations of user 
> rights.

offhand, I don't see how an expires header field generated by a sender, 
especially one outside a recipient's enterprise, should affect this sort 
of data archiving at all.

> Nothing insane, irresponsible or illegal about them. 

we'll probably just have to disagree about the insane part.  but you 
were referring to something different than I was.

> While you may not 
> feel is our job to bless the practice, I'm sure others will take all 
> these related issues into account. You made it quite clear your view 
> point;  backends MUST not deal with this header and if they do only with 
> user permission.  Well, the devil is in the details; e.g., if user 
> permission is provided (assuming it is even offered at all),  it can not 
> defeat what may be already in place.   It can only serve to accelerate 
> the expired classification.  Not extend it  - unless of course an 
> implementation wishes to consider that logic.

and if the sender is allowed to accelerate the expired classification 
this can result in the sender being allowed to destroy evidence that 
might otherwise be retained on the recipient's system?  right.

Keith

Date: Thu, 24 Jul 2008 12:29:00 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Keith Moore <[email-masked]>
CC:  [email-masked], Jeff Macdonald <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Keith,

I was referring to widely practiced Standard Email Compliance Policies 
that include archiving, expiration, mining, etc following and/or meeting 
required data retention regulations outside the considerations of user 
rights.

Nothing insane, irresponsible or illegal about them. While you may not 
feel is our job to bless the practice, I'm sure others will take all 
these related issues into account. You made it quite clear your view 
point;  backends MUST not deal with this header and if they do only with 
user permission.  Well, the devil is in the details; e.g., if user 
permission is provided (assuming it is even offered at all),  it can not 
defeat what may be already in place.   It can only serve to accelerate 
the expired classification.  Not extend it  - unless of course an 
implementation wishes to consider that logic.

-- 
HLS

Keith Moore wrote:
>
> Hector Santos wrote:
>
>> As you know Ned,  expiration that is out of the control of the MUA 
>> (user) is already in practice.
>
> That's irrelevant for a discussion of a standard.  There are lots of 
> things that are "already in practice" that are irresponsible or 
> completely insane.
>
> Our job is NOT to bless those practices, it is to define practices 
> that are sane.
>
> We can't stop people from implementing things that are irresponsible 
> or insane.  But there are things that we can do.   We can make it 
> clear that such behavior is a violation of the standard.  And in some 
> cases we can design protocols in such a way that such violations are 
> observable, so that the responsible parties can be held accountable by 
> whatever means is available (legal or economic or social).
>
> Keith
>
>

Date: Thu, 24 Jul 2008 12:29:28 -0400
From: Chris Eastlund <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Isn't this more of a calendar function than a cleanup function?

If I miss a meeting notice that has an EXPIRES header, I don't
want it deleted, I might want it highlighted so I can apologize for
missing the meeting.  And it would be nice if the MUA would slide
soon-to-expire messages to the top of some priority list.

Maybe it's a personal choice, but I don't want a third party being
able to set a firm date-to-disappear on mail in my inbox.

Chris Eastlund
ATT

Keith Moore wrote:
> 
> Paul Smith wrote:
>>   So, what would you want the recipient MUA to do with these. The 
>> consensus seems to be that they should still receive them - so what 
>> difference does the 'expires' make? Automatically moving them into 
>> another folder when they arrive is nearly the same as automatically 
>> deleting them as far as many users goes! Showing them in grey or 
>> another colour doesn't stop people having to read them to see if 
>> they've missed something important.
> 
> often you can tell from the subject line whether a message is something 
> you actually need to read.  if the subject line of an expired message is 
> shown in grey, that's just another clue to help the recipient decide 
> whether to read the message or delete it.
> 
>> "confirm your subscription to list X in the next 3 days" is still 
>> important if you receive it 4 days later. Now you know you need to try 
>> again to get onto the list.
> 
> right, some messages become _more_ important after a given date...
> 
> it's at least possible that ordinary users might eventually learn how to 
> use such things as expiry dates.  for instance, many of my younger, 
> non-geek friends now seem to understand the value of Bcc.  I don't think 
> that was true 10 years ago.
> 
>> "I'm out of the office until ..." may be important, you may have been 
>> bad-mouthing a contact because they hadn't replied to you earlier, and 
>> now you'll know why
> 
> a good example of why automatically deleting a message based on expiry 
> date is a bad idea.
> 
>> "special offer valid until ..." may still be important from the 
>> sender's point of view as a "buy our wonderful flying car for only 
>> $15,000 before 30th July, look how amazing it is..." is still a good 
>> advertisement if it's received on the 1st August, and the recipient 
>> may still want it even though the special offer has expired.
> 
> yes, but most readers would not want it.  again, automatic deletion is a 
> bad idea but when the reader sees the summary line of the advert in grey 
> he'll likely infer that the offer has since expired.
> 
> I could imagine looking at the message summary in my ietf-announce 
> folder and seeing some LAST CALL announcements in grey and others in 
> black - and that would be useful in letting me know which messages to 
> ignore.
> 
> (I could even imagine configuring my MUA to show a message in red if the 
> expiry date were within say three days...but that probably wouldn't be 
> the right thing for most messages nearing expiration.)
> 
>> 'expires' only makes sense (IMV) if it would reduce the mail to be 
>> read by the recipient by getting rid of stuff that's absolutely no use 
>> any more. 
> 
> disagree.  I think it's useful as a tool to help people decide which 
> messages to read.   but my assumption is that other people do like I do 
> and look at the subject lines of messages to decide which ones to read.
> 
> Keith
> 

Date: Thu, 24 Jul 2008 11:48:39 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Expires: vs. Supersedes:
Sender: [email-masked]

Frank Ellermann wrote:
> Keith Moore wrote:
> 
>>>> behavior for mail-to-NetNews gateways should also be specified.
> 
>>> Transparent, "Expires:" can be kept as is (modulo magic SP in news)
>  
>> my concern here is that (as best I recall) in NetNews, Expires
>> pretty much means the message will get deleted after that date.
> 
> Yes, that is what *expiration* does, depending on the server and 
> the group.  But servers are in now way forced to honour Expires:.
> Expires: is only a recommendation roughly matching your proposed
> semantics.  Quoting the MISSREF-blocked RFC (section 3.2.5):
> 
>  The Expires header field specifies a date and time when the poster
>  deems the article to be no longer relevant and could usefully be
>  removed ("expired").

yeah, I know.  but when widespread practice is to delete expired netnews 
messages,  there's a practical problem with gatewaying mail with an 
expired header to netnews.  (this is exacerbated by the lack of clean 
separation between message format and transport protocol in netnews.)

not that I care a huge amount.  AFAICS netnews is dead.

Keith

Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
From: Jeff Macdonald <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: ietf-822 <[email-masked]>
Organization: e-Dialog
Date: Thu, 24 Jul 2008 11:22:46 -0400
Sender: [email-masked]

On Thu, 2008-07-24 at 09:49 -0400, Keith Moore wrote:
> Jeff Macdonald wrote:
> > 
> > On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
> >> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
> >> of an Expired header field unless given explicit instructions to do so 
> >> by the recipient."
> > 
> > I find it very desirable to have MTAs generate a bounce if the message
> > is older than the Expired header.
> 
> (What does it mean for a message to be older than a header contained 
> within the message?  I assume you mean "... if the date in the Expired 
> header is after the current date.")

yep

> Now it might also be useful if there were a MTS feature that would let
> a 
> sender say "don't bother delivering this message if you can't get it 
> there before <date>".  But I don't think that's what we're talking
> about 
> here.  (and if there were such a feature it should be implemented in 
> SMTP rather in the message header).

it is what I was thinking and Ned rightly pointed out that DELIVERYBY
handles what I was looking for.

The only thing I don't like about that extension is it really needs a
3rd mode. If I understand the RFC correctly:

* mode R
means bounce message even if the DELIVERYBY time hasn't expired when
delivering to an MTA that doesn't support DELIVERYBY

* mode N
means attempt to deliver when time has expired but notify the sender

Neither of these does what I'd like. I need a mode that is like R but
will deliver to MTAs that do not support DELIVERYBY. This way the
originating can expire messages and doesn't have to worry if the rest of
the world supports DELIVERYBY.

Unless of course I am mis-understanding section 4.1.4. I'm not sure how
a sending MTA knows it is sending email to a relay. I'm assuming all
receiving MTAs could be a relay.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Expires: vs. Supersedes: (was: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15)
Date:  Thu, 24 Jul 2008 16:37:45 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 41
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

>>> behavior for mail-to-NetNews gateways should also be specified.

>> Transparent, "Expires:" can be kept as is (modulo magic SP in news)
=20
> my concern here is that (as best I recall) in NetNews, Expires
> pretty much means the message will get deleted after that date.

Yes, that is what *expiration* does, depending on the server and=20
the group.  But servers are in now way forced to honour Expires:.
Expires: is only a recommendation roughly matching your proposed
semantics.  Quoting the MISSREF-blocked RFC (section 3.2.5):

 The Expires header field specifies a date and time when the poster
 deems the article to be no longer relevant and could usefully be
 removed ("expired").

    NOTE: This header field is useful when the poster desires an
    unusually long or an unusually short expiry time.

 expires         =3D  "Expires:" SP date-time CRLF

 See the remarks under Section 3.1.1 regarding the syntax of
 <date-time> and the requirements and recommendations to which it is
 subject.

    NOTE: The Expires header field is also sometimes used in Email
    with a similar meaning; see [RFC2156].

> I haven't looked at netnews in years but I seem to recall that
> expires used to be used mostly with periodic postings like FAQs
> that were reissued (and perhaps revised) on a regular basis.

Possibly.  But FAQs typically use "Supersedes:" for this purpose.
"Supersedes:" is a combination of a cancel-message for article A
posting a replacement article B.  And news servers are also free=20
to ignore "Supersedes:" and cancel-messages =3D> local policy.=20

 Frank

Date: Thu, 24 Jul 2008 09:56:27 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked], Jeff Macdonald <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:

> As you know Ned,  expiration that is out of the control of the MUA 
> (user) is already in practice.

That's irrelevant for a discussion of a standard.  There are lots of 
things that are "already in practice" that are irresponsible or 
completely insane.

Our job is NOT to bless those practices, it is to define practices that 
are sane.

We can't stop people from implementing things that are irresponsible or 
insane.  But there are things that we can do.   We can make it clear 
that such behavior is a violation of the standard.  And in some cases we 
can design protocols in such a way that such violations are observable, 
so that the responsible parties can be held accountable by whatever 
means is available (legal or economic or social).

Keith

Date: Thu, 24 Jul 2008 09:49:42 -0400
From: Keith Moore <[email-masked]>
To: Jeff Macdonald <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Jeff Macdonald wrote:
> 
> On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
>> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
>> of an Expired header field unless given explicit instructions to do so 
>> by the recipient."
> 
> I find it very desirable to have MTAs generate a bounce if the message
> is older than the Expired header.

(What does it mean for a message to be older than a header contained 
within the message?  I assume you mean "... if the date in the Expired 
header is after the current date.")

I absolutely would not want an MTA to do that, because as been widely 
observed here, even expired messages are sometimes relevant to a 
recipient - just in a more limited set of circumstances than before they 
expired.

(And in general I'm pretty fed up with MTS components deleting messages 
that I need to receive because they think they know better than me what 
I need to read. I recently had a spam filter trash a job offer in my 
incoming mail.   I'd love to hunt down the person who wrote that filter 
rule....)

Now it might also be useful if there were a MTS feature that would let a 
sender say "don't bother delivering this message if you can't get it 
there before <date>".  But I don't think that's what we're talking about 
here.  (and if there were such a feature it should be implemented in 
SMTP rather in the message header).

Keith.

Date: Thu, 24 Jul 2008 09:43:33 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Frank Ellermann wrote:

>  
>> behavior for mail-to-NetNews gateways should also be specified.
> 
> Transparent, "Expires:" can be kept as is (modulo magic SP in news)

my concern here is that (as best I recall) in NetNews, Expires pretty 
much means the message will get deleted after that date.  I haven't 
looked at netnews in years but I seem to recall that expires used to be 
used mostly with periodic postings like FAQs that were reissued (and 
perhaps revised) on a regular basis.

whereas for email we seem to want something different - a hint to the 
recipient about the relevance of the message.  which argues for a 
different header field name to minimize the potential for confusion.

Keith

Date: Thu, 24 Jul 2008 09:39:33 -0400
From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Paul Smith wrote:
>   
> So, what would you want the recipient MUA to do with these. The 
> consensus seems to be that they should still receive them - so what 
> difference does the 'expires' make? Automatically moving them into 
> another folder when they arrive is nearly the same as automatically 
> deleting them as far as many users goes! Showing them in grey or another 
> colour doesn't stop people having to read them to see if they've missed 
> something important.

often you can tell from the subject line whether a message is something 
you actually need to read.  if the subject line of an expired message is 
shown in grey, that's just another clue to help the recipient decide 
whether to read the message or delete it.

> "confirm your subscription to list X in the next 3 days" is still 
> important if you receive it 4 days later. Now you know you need to try 
> again to get onto the list.

right, some messages become _more_ important after a given date...

it's at least possible that ordinary users might eventually learn how to 
use such things as expiry dates.  for instance, many of my younger, 
non-geek friends now seem to understand the value of Bcc.  I don't think 
that was true 10 years ago.

> "I'm out of the office until ..." may be important, you may have been 
> bad-mouthing a contact because they hadn't replied to you earlier, and 
> now you'll know why

a good example of why automatically deleting a message based on expiry 
date is a bad idea.

> "special offer valid until ..." may still be important from the sender's 
> point of view as a "buy our wonderful flying car for only $15,000 before 
> 30th July, look how amazing it is..." is still a good advertisement if 
> it's received on the 1st August, and the recipient may still want it 
> even though the special offer has expired.

yes, but most readers would not want it.  again, automatic deletion is a 
bad idea but when the reader sees the summary line of the advert in grey 
he'll likely infer that the offer has since expired.

I could imagine looking at the message summary in my ietf-announce 
folder and seeing some LAST CALL announcements in grey and others in 
black - and that would be useful in letting me know which messages to 
ignore.

(I could even imagine configuring my MUA to show a message in red if the 
expiry date were within say three days...but that probably wouldn't be 
the right thing for most messages nearing expiration.)

> 'expires' only makes sense (IMV) if it would reduce the mail to be read 
> by the recipient by getting rid of stuff that's absolutely no use any 
> more. 

disagree.  I think it's useful as a tool to help people decide which 
messages to read.   but my assumption is that other people do like I do 
and look at the subject lines of messages to decide which ones to read.

Keith

Date: Thu, 24 Jul 2008 12:34:40 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: MUA auto-configuration, was Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Thu, 24 Jul 2008, Keith Moore wrote:
>
> I'm curious to know more.  Is there an I-D or web page?

Only an old rant. http://fanf.livejournal.com/39428.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: SOUTHWESTERLY 3 OR 4, INCREASING 5 AT TIMES. SLIGHT OR MODERATE.
THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Thu, 24 Jul 2008 07:23:40 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Tony Finch wrote:
> On Thu, 24 Jul 2008, Keith Moore wrote:
>> Tony Finch wrote:
>>> Not if you store the settings that you negotiated the first time
>>> (ssh-style "leap of faith") and allow the user to check the stored
>>> settings.
>> It seems to me that this defeats the purpose as the whole point of this kind
>> of "security negotiation" (or most of the point, anyway) is to keep the user
>> from needing to be aware of such details.
> 
> At the moment they have to manually type the details into dialog boxes, so
> they are forced to be aware of them. With my design, the MUA fills in the
> dialog boxes and users can pay as much or as little attention to them as
> they wish. "Allow" does not mean "require". Auto-configuration does not
> imply keeping users in the dark.

I'm curious to know more.  Is there an I-D or web page?

thanks,

Keith

Date: Thu, 24 Jul 2008 12:22:28 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Thu, 24 Jul 2008, Keith Moore wrote:
> Tony Finch wrote:
> >
> > Not if you store the settings that you negotiated the first time
> > (ssh-style "leap of faith") and allow the user to check the stored
> > settings.
>
> It seems to me that this defeats the purpose as the whole point of this kind
> of "security negotiation" (or most of the point, anyway) is to keep the user
> from needing to be aware of such details.

At the moment they have to manually type the details into dialog boxes, so
they are forced to be aware of them. With my design, the MUA fills in the
dialog boxes and users can pay as much or as little attention to them as
they wish. "Allow" does not mean "require". Auto-configuration does not
imply keeping users in the dark.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHERLY BACKING EASTERLY, 4 OR 5, OCCASIONALLY 6 LATER IN
WEST. MODERATE OR ROUGH. FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY
POOR.

Date: Thu, 24 Jul 2008 07:15:11 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Tony Finch wrote:
> On Wed, 23 Jul 2008, Keith Moore wrote:
>> Tony Finch wrote:
>>
>>> Of course MUAs should just use the protocol's negotiation features to
>>> auto-configure the most secure settings possible.
>> strongly disagree.  the problem is that when you try to negotiate the most
>> secure settings possible, you often create a way for the negotiation to be
>> dumbed down by an attacker to the least secure setting possible.
> 
> Not if you store the settings that you negotiated the first time
> (ssh-style "leap of faith") and allow the user to check the stored
> settings.

It seems to me that this defeats the purpose as the whole point of this 
kind of "security negotiation" (or most of the point, anyway) is to keep 
the user from needing to be aware of such details.

Keith

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Thu, 24 Jul 2008 12:53:22 +0200
Sender: [email-masked]

Hi,

I don't understand your point. I wholeaheartedly agree that
online MUAs should also be supported - so what? I don't see
how this affects the rules that Keith Moore beautifully
laid out in this email:
http://www.imc.org/ietf-822/mail-archive/msg06348.html

In our University's webmail system, I can define folders
and set some filters; by default, the system should only
highlight expired emails somehow (which it could), and
it might allow me to automatically have them deleted,
or moved somewhere...

I just don't see a difference with regards to usage
of the expiry date.

Cheers,
Michael

On Wed, 2008-07-23 at 19:56 -0400, Hector Santos wrote:
> Michael,
> 
> I think it should be made clear what we are talking about when it
> comes to the type of MUA.
> 
> There is typical a propensity to think of offline MUA, like Outlook,
> ThunderBird, Eudora, Unix based offline mail readers etc.
> 
> But you also have online based MUAs as well.
> 
> The difference?
> 
> Offline Storage vs Online Storage
> 
> Both present a different set of technical and very important legal
> engineering design requirements.  
> 
> Obviously, the options for Online MUAs (i.e. WebMail)  are defined by
> what the backend provides the user.    Offline MUA options are defined
> by what the vendors of offline mail writer/reader programs provides.
> The consistency in the options between the two should not be presumed
> to exist.
> 
> So I think it is short on design to think that a proposed IETF 2822
> header of this caliber is only useful for offline MUA systems.  The
> design considerations must also be consistent for Online MUAs,
> including Offline MUAs in regards to the stored mail kept on the
> server which generally is the same used for online MUA connectivity as
> well.
> 
> So in my view,  being that we offer a mail process entity for each
> stage of the total mail system, including multiple MUA softwares
> (offline, Online, and Mixed,  text, html and GUI),  I think the
> question is which one processes in the end to end flow process can use
> this and how.   If the proposal mandates the Expire Header is for MUAs
> only, then for the online based MUA, this implies the backend has to
> support and work with it too.
> 
> My Point?
> 
> It isn't as simple as it might appear when we only consider the
> offline mail write/reader software MUA.  It would be a half baked,
> incomplete and only partial consideration within the many variant and
> complete mail systems as we know it today.
> 
> How about mobile?  
> 
> One the key issues here is redundant, wasteful mail  downloads because
> of the "Keep On Mail Server" idea which forces backends to not mark
> mail as received allowing user to get their mail on mobile and back in
> the office/home desktop.
> 
> If the Expire Header can be one small additional part of the complete
> process to eliminate "irrelevant" mail,  then it will have a "some"
> payoff for mobile users as well of offline users.
> -- 
> HLS
> 
> Michael Welzl wrote: 
> > > So, would you still be happy to have your MUA silently delete
> > > expired  messages?
> > 
> > Believe it or don't: yes.
> > Granted, when I said "silently delete", I meant "silently move it to my
> > trashcan folder, which is what my MUA does when I delete emails. This way, if I
> > lose something and start to wonder what's wrong, I can still look things up
> > in the trash. If I don't start to wonder what's wrong, I believe I have the
> > right to assume it's the sender's fault that their message never reached me. This
> > is what they risk when falsely setting the expiry date.
> > 
> > Other people could use it to automatically move emails to a suitable
> > folder, which makes email reading more efficient and still doesn't
> > let them miss the stuff that you mention above. But they can regard
> > it as low priority and go through it if and when they consider it
> > appropriate.
> > 
> > 
> >   
> > > AFAICS, the only safe way to use 'expire' would either be for it not to
> > > move/delete messages at all (in which case, what's the point) or to have
> > > different rules handling expire differently from different senders (when
> > > you know how THAT sender uses it), but this would only be useful if you
> > > repeatedly got expired messages from particular people (which is doubtful)
> > >     
> > 
> > I disagree, on the basis of what I said above.
> > 
> > 
> >   
> > > (I do wonder, how important is this anyway? How often do you receive
> > > messages after they would have expired? The only time I can think it
> > > would be even slightly useful is if you've just come back from a
> > > vacation and haven't checked your mail whilst you've been away, but then
> > > a few CFP or talk announcements is going to be irrelevant amongst all
> > > the other thousands of semi-junk messages you'll have received!)
> > >     
> > 
> > I agree that this would be especially useful (but not "the only time
> > when this would be even slightly useful") after a holiday. The few
> > announcements are not going to be irrelevant among the other
> > semi-junk things.
> > 
> > Something more time consuming, to give you one more example:
> > 
> > "Michael, please do this until ... messages" - where you have to
> > carefully read the whole thing, only to find out that the sender
> > has absolutely no use for what he demanded by the time you
> > read this message. That happens to me on a regular basis and
> > is really annoying.
> > 
> > Putting all of this together, for me and I'm sure that a lot of other
> > people, an expired field would be well worth having. You shoudln't
> > make your own personal preferences and daily life with email the
> > standard.
> > 
> > Probably we (as we discuss on this list) are not even good examples.
> > There are newspaper articles and even books discussing how to
> > deal with emails, for higher level managers - I'm sure that, for these
> > people, any small contribution to reducing the number of daily emails
> > is extremely valuable.
> > 
> > 
> >   
> > > I don't have a massive problem with an 'expires' header, I just see it
> > > as, at best, pointless, and at worst, dangerous in the hands of an
> > > unthinking user (of which there are many using the Internet).
> > >     
> > 
> > Pointless: this is based on your personal preference which you
> > outlined above.
> > 
> > Dangerous: no, because of its strictly advisory nature. You would have
> > to be unthinking enough to set your mail client to always delete expired
> > emails on purpose, then wonder what's wrong. This is equivalent to
> > formatting a hard disk on purpose, then wondering what's wrong - that
> > a user could do that is the inevitable risk that comes with every
> > functionality
> > you give him (for once, I think it's actually better to use the male form,
> > for
> > the sake of political correctness!  :-)   ), but this should not be at the
> > cost
> > of the rest of us.
> > 
> > Cheers,
> > Michael
> > 
> > 
> > 
> >   
> 
> 

Date: Thu, 24 Jul 2008 11:32:51 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Wed, 23 Jul 2008, Keith Moore wrote:
> Tony Finch wrote:
>
> > Of course MUAs should just use the protocol's negotiation features to
> > auto-configure the most secure settings possible.
>
> strongly disagree.  the problem is that when you try to negotiate the most
> secure settings possible, you often create a way for the negotiation to be
> dumbed down by an attacker to the least secure setting possible.

Not if you store the settings that you negotiated the first time
(ssh-style "leap of faith") and allow the user to check the stored
settings.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FISHER GERMAN BIGHT: VARIABLE 3 OR 4 BECOMING EASTERLY 4 OR 5, OCCASIONALLY 6
LATER. SLIGHT OR MODERATE. FOG PATCHES. GOOD, OCCASIONALLY VERY POOR.

Date: Thu, 24 Jul 2008 00:02:23 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: Tony Finch <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

> I guess you both right - Heck, by far I find sysops prefer to use POP 
> BEFORE SMTP as the easiest - no instructions, less support required 
> method to give their users instant auto-temporary-access to SMTP relay. 

works great except for

a) message stores that support POP with cleartext passwords
b) message stores that support IMAP rather than POP (there are a number 
of cases where supporting POP makes no sense)
c) users who submit their mail via another submission agent than the one 
that handles their incoming mail.
etc.

in other words, it's not very general at all.

Keith

Date: Wed, 23 Jul 2008 23:57:26 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Tony Finch wrote:

> Of course MUAs should just use the protocol's negotiation features to
> auto-configure the most secure settings possible.

strongly disagree.  the problem is that when you try to negotiate the 
most secure settings possible, you often create a way for the 
negotiation to be dumbed down by an attacker to the least secure setting 
possible.

e.g. for an MUA that tries first to use an "SSL port" and if that fails, 
tries to use the normal port without SSL (and sending the password in 
cleartext) all the attacker has to do is arrange for the client to see 
an ICMP port unreachable packet or TCP RST at the right time, after 
which the client will happily send the user's password in cleartext.

Keith

Date: Wed, 23 Jul 2008 19:56:36 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC:  [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040005040006050702030101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

I think it should be made clear what we are talking about when it comes 
to the type of MUA.

There is typical a propensity to think of offline MUA, like Outlook, 
ThunderBird, Eudora, Unix based offline mail readers etc.

But you also have online based MUAs as well.

The difference?

Offline Storage vs Online Storage

Both present a different set of technical and very important legal 
engineering design requirements. 

Obviously, the options for Online MUAs (i.e. WebMail)  are defined by 
what the backend provides the user.    Offline MUA options are defined 
by what the vendors of offline mail writer/reader programs provides.  
The consistency in the options between the two should not be presumed to 
exist.

So I think it is short on design to think that a proposed IETF 2822 
header of this caliber is only useful for offline MUA systems.  The 
design considerations must also be consistent for Online MUAs, including 
Offline MUAs in regards to the stored mail kept on the server which 
generally is the same used for online MUA connectivity as well.

So in my view,  being that we offer a mail process entity for each stage 
of the total mail system, including multiple MUA softwares (offline, 
Online, and Mixed,  text, html and GUI),  I think the question is which 
one processes in the end to end flow process can use this and how.   If 
the proposal mandates the Expire Header is for MUAs only, then for the 
online based MUA, this implies the backend has to support and work with 
it too.

My Point?

It isn't as simple as it might appear when we only consider the offline 
mail write/reader software MUA.  It would be a half baked,  incomplete 
and only partial consideration within the many variant and complete mail 
systems as we know it today.

How about mobile? 

One the key issues here is redundant, wasteful mail  downloads because 
of the "Keep On Mail Server" idea which forces backends to not mark mail 
as received allowing user to get their mail on mobile and back in the 
office/home desktop.

If the Expire Header can be one small additional part of the complete 
process to eliminate "irrelevant" mail,  then it will have a "some" 
payoff for mobile users as well of offline users.

-- 
HLS

Michael Welzl wrote:
>> So, would you still be happy to have your MUA silently delete 
>> expired  messages?
>
> Believe it or don't: yes.
> Granted, when I said "silently delete", I meant "silently move it to my
> trashcan folder, which is what my MUA does when I delete emails. This way, if I
> lose something and start to wonder what's wrong, I can still look things up
> in the trash. If I don't start to wonder what's wrong, I believe I have the
> right to assume it's the sender's fault that their message never reached me. This
> is what they risk when falsely setting the expiry date.
>
> Other people could use it to automatically move emails to a suitable
> folder, which makes email reading more efficient and still doesn't
> let them miss the stuff that you mention above. But they can regard
> it as low priority and go through it if and when they consider it
> appropriate.
>
>
>   
>> AFAICS, the only safe way to use 'expire' would either be for it not to
>> move/delete messages at all (in which case, what's the point) or to have
>> different rules handling expire differently from different senders (when
>> you know how THAT sender uses it), but this would only be useful if you
>> repeatedly got expired messages from particular people (which is doubtful)
>>     
>
> I disagree, on the basis of what I said above.
>
>
>   
>> (I do wonder, how important is this anyway? How often do you receive
>> messages after they would have expired? The only time I can think it
>> would be even slightly useful is if you've just come back from a
>> vacation and haven't checked your mail whilst you've been away, but then
>> a few CFP or talk announcements is going to be irrelevant amongst all
>> the other thousands of semi-junk messages you'll have received!)
>>     
>
> I agree that this would be especially useful (but not "the only time
> when this would be even slightly useful") after a holiday. The few
> announcements are not going to be irrelevant among the other
> semi-junk things.
>
> Something more time consuming, to give you one more example:
>
> "Michael, please do this until ... messages" - where you have to
> carefully read the whole thing, only to find out that the sender
> has absolutely no use for what he demanded by the time you
> read this message. That happens to me on a regular basis and
> is really annoying.
>
> Putting all of this together, for me and I'm sure that a lot of other
> people, an expired field would be well worth having. You shoudln't
> make your own personal preferences and daily life with email the
> standard.
>
> Probably we (as we discuss on this list) are not even good examples.
> There are newspaper articles and even books discussing how to
> deal with emails, for higher level managers - I'm sure that, for these
> people, any small contribution to reducing the number of daily emails
> is extremely valuable.
>
>
>   
>> I don't have a massive problem with an 'expires' header, I just see it
>> as, at best, pointless, and at worst, dangerous in the hands of an
>> unthinking user (of which there are many using the Internet).
>>     
>
> Pointless: this is based on your personal preference which you
> outlined above.
>
> Dangerous: no, because of its strictly advisory nature. You would have
> to be unthinking enough to set your mail client to always delete expired
> emails on purpose, then wonder what's wrong. This is equivalent to
> formatting a hard disk on purpose, then wondering what's wrong - that
> a user could do that is the inevitable risk that comes with every
> functionality
> you give him (for once, I think it's actually better to use the male form,
> for
> the sake of political correctness!  :-)   ), but this should not be at the
> cost
> of the rest of us.
>
> Cheers,
> Michael
>
>
>
>   

--------------040005040006050702030101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
I think it should be made clear what we are talking about when it comes
to the type of MUA.<br>
<br>
There is typical a propensity to think of offline MUA, like Outlook,
ThunderBird, Eudora, Unix based offline mail readers etc.<br>
<br>
But you also have online based MUAs as well.<br>
<br>
The difference?<br>
<br>
Offline Storage vs Online Storage<br>
<br>
Both present a different set of technical and very important legal
engineering design requirements.&nbsp; <br>
<br>
Obviously, the options for Online MUAs (i.e. WebMail)&nbsp; are defined by
what the backend provides the user.&nbsp;&nbsp;&nbsp; Offline MUA options are defined
by what the vendors of offline mail writer/reader programs provides.&nbsp;
The consistency in the options between the two should not be presumed
to exist.<br>
<br>
So I think it is short on design to think that a proposed IETF 2822
header of this caliber is only useful for offline MUA systems.&nbsp; The
design considerations must also be consistent for Online MUAs,
including Offline MUAs in regards to the stored mail kept on the server
which generally is the same used for online MUA connectivity as well.<br>
<br>
So in my view,&nbsp; being that we offer a mail process entity for each
stage of the total mail system, including multiple MUA softwares
(offline, Online, and Mixed,&nbsp; text, html and GUI),&nbsp; I think the
question is which one processes in the end to end flow process can use
this and how.&nbsp;&nbsp; If the proposal mandates the Expire Header is for MUAs
only, then for the online based MUA, this implies the backend has to
support and work with it too.<br>
<br>
My Point?<br>
<br>
It isn't as simple as it might appear when we only consider the offline
mail write/reader software MUA.&nbsp; It would be a half baked,&nbsp; incomplete
and only partial consideration within the many variant and complete
mail systems as we know it today.<br>
<br>
How about mobile?&nbsp; <br>
<br>
One the key issues here is redundant, wasteful mail&nbsp; downloads because
of the "Keep On Mail Server" idea which forces backends to not mark
mail as received allowing user to get their mail on mobile and back in
the office/home desktop.<br>
<br>
If the Expire Header can be one small additional part of the complete
process to eliminate "irrelevant" mail,&nbsp; then it will have a "some"
payoff for mobile users as well of offline users.<br>
<pre class="moz-signature" cols="72">-- 
HLS

</pre>
Michael Welzl wrote:
<blockquote cite="mid:001c01c8ecd5$a2914e00$0200a8c0@fun" type="cite">
  <blockquote type="cite">So, would you still be happy to have your MUA
silently delete expired&nbsp; messages?<br>
  </blockquote>
  <pre wrap=""><!---->
Believe it or don't: yes.
Granted, when I said "silently delete", I meant "silently move it to my
trashcan folder, which is what my MUA does when I delete emails. This way, if I
lose something and start to wonder what's wrong, I can still look things up
in the trash. If I don't start to wonder what's wrong, I believe I have the
right to assume it's the sender's fault that their message never reached me. This
is what they risk when falsely setting the expiry date.

Other people could use it to automatically move emails to a suitable
folder, which makes email reading more efficient and still doesn't
let them miss the stuff that you mention above. But they can regard
it as low priority and go through it if and when they consider it
appropriate.

  </pre>
  <blockquote type="cite">
    <pre wrap="">AFAICS, the only safe way to use 'expire' would either be for it not to
move/delete messages at all (in which case, what's the point) or to have
different rules handling expire differently from different senders (when
you know how THAT sender uses it), but this would only be useful if you
repeatedly got expired messages from particular people (which is doubtful)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I disagree, on the basis of what I said above.

  </pre>
  <blockquote type="cite">
    <pre wrap="">(I do wonder, how important is this anyway? How often do you receive
messages after they would have expired? The only time I can think it
would be even slightly useful is if you've just come back from a
vacation and haven't checked your mail whilst you've been away, but then
a few CFP or talk announcements is going to be irrelevant amongst all
the other thousands of semi-junk messages you'll have received!)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I agree that this would be especially useful (but not "the only time
when this would be even slightly useful") after a holiday. The few
announcements are not going to be irrelevant among the other
semi-junk things.

Something more time consuming, to give you one more example:

"Michael, please do this until ... messages" - where you have to
carefully read the whole thing, only to find out that the sender
has absolutely no use for what he demanded by the time you
read this message. That happens to me on a regular basis and
is really annoying.

Putting all of this together, for me and I'm sure that a lot of other
people, an expired field would be well worth having. You shoudln't
make your own personal preferences and daily life with email the
standard.

Probably we (as we discuss on this list) are not even good examples.
There are newspaper articles and even books discussing how to
deal with emails, for higher level managers - I'm sure that, for these
people, any small contribution to reducing the number of daily emails
is extremely valuable.

  </pre>
  <blockquote type="cite">
    <pre wrap="">I don't have a massive problem with an 'expires' header, I just see it
as, at best, pointless, and at worst, dangerous in the hands of an
unthinking user (of which there are many using the Internet).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Pointless: this is based on your personal preference which you
outlined above.

Dangerous: no, because of its strictly advisory nature. You would have
to be unthinking enough to set your mail client to always delete expired
emails on purpose, then wonder what's wrong. This is equivalent to
formatting a hard disk on purpose, then wondering what's wrong - that
a user could do that is the inevitable risk that comes with every
functionality
you give him (for once, I think it's actually better to use the male form,
for
the sake of political correctness!  :-)   ), but this should not be at the
cost
of the rest of us.

Cheers,
Michael

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>

--------------040005040006050702030101--

Date: Wed, 23 Jul 2008 18:55:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To:  [email-masked]
CC: Jeff Macdonald <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

[email-masked] wrote:

 >> Jeff wrote:
 >>
 >> I find it very desirable to have MTAs generate a bounce if
 >> the message is older than the Expired header.
 >
 > I do not. The problem with trying to do this at the MTA level
 > is that the preferences of the recipient cannot be properly taken
 > into account.
 >
 > If you want this sort of service at the transport level, use
 > the DELIVERBY extension, not an Expired: header. This is what it
 > is for. IMO Expired: should only be used as an MUA-level facility.

For our system,  I can easily see this as a desirable feature (new 
checkboxes) for the backend mail policy definitions. 

   [X]  Days to Expire Read Private mail:      7
   [X]  Days to Expire Unread Public or Private mail:  30
   [X]  Days to Expire External (sent) mail: 30
   [_]  Delete External user email once delivered (sent) by SMTP
   [X] Allow Personal Mail Deletion

   [X]  Support RFC xxx  Expire Flags for Received Mail
   [X]  Support RFC xxx  Expire Flags for UnReceived Mail

Anything that helps the operator make a decision would be useful.

As you know Ned,  expiration that is out of the control of the MUA 
(user) is already in practice.  The question/design issue would be, IMV, 
if an external sender-defined flag can be used to accelerate/trigger the 
existing backend practice.  Of course, it can not be used to defeat the 
existing practice.

-- 
HLS

Date: Wed, 23 Jul 2008 18:41:08 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Jeff Macdonald <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Expire header for Various Mail Processes
Sender: [email-masked]

Jeff Macdonald wrote:
> On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
>   
>> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
>> of an Expired header field unless given explicit instructions to do so 
>> by the recipient."
>>     
>
> I find it very desirable to have MTAs generate a bounce if the message
> is older than the Expired header.
>
>
>   
Hell, filters exist the delete/reject mail that is POST Dated to some 
future date!  :)

I think we can view this among the different processes:

MUA-SENDER

    !  - Optional EXPIRE Date Input Field during mail creation

MSA - port 25

    ?  - Rejection/Warning based on Validation of PUBLIC PORT mail 
submission

MSA - port 587

    !  - Rejection/Warning based on Validation of PRIVATE PORT mail 
submission

MTA

    ! -  MUST never tampered with passthru mail - this will make it 
consistent with legal precedence.

MDA -  Optional Reject
    
    ? - Local Policy Offers user permission option
    ? - AVS System MAY offer RFC XXXX expire rules

MAIL STORES

    ? - Use to augment existing backend arching/expiration policies.
      
MUA-RECIPIENT - OFFLINE and ONLINE

    ! - Add Symbolic, Iconic, Color, Notification Message display 
classification
    ? - Add/offer two options common MUA Server Account settings:

       [X] Delete Received Mail when Expired (RFC XXXX)
       [X] Server May Delete Unreceived Mail based on RFC XXXX expire flag

-- 
HLS

Date: Wed, 23 Jul 2008 18:19:08 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Keith Moore <[email-masked]>
CC: Frank Ellermann <[email-masked]>, [email-masked], Michael Welzl <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Keith Moore wrote:
> How about this: "The sender believes this message will be irrelevant 
> after the indicated date/time."

+1

> "This field is primarily intended for use between senders and 
> recipients and their agents, rather than by message transport.   

+0.7, If you referring to the receiver applying a rule before accepting 
the message.  I would prefer to be optional.

The thing is,  there might end up being used by the backend mail storage 
system.

The reason is because it already exist - that is, archiving, deletion 
and/or expiring of mail based on a system's existing archiving/audit  
local policy mail policies which is an important part of the mail system 
regardless of this flag.

I can only see this serving as a *helper* in the mail status archiving, 
packing, maintenance decision logic.

>  It is suggested that the default behavior of an MUA with respect to 
> the expires header field should be to display such a message in a 
> distinguished way.  For example, the message could be displayed with 
> gray text rather than black, or in a different font than normal, or 
> (in summaries) with an image of an hourglass with the sand at the 
> bottom."
+0.7

But  I think this is implementation subjective - are we teaching 
ergonomics to users?   This color is good, that color is bad?   Is GUI 
(hourglass states) assumed to be part of the process? 

I think just a general discussion on the idea of classification and how 
a MUA may present this classification with examples based on the common 
devices in use today is sufficient.   Text based rendering have a 
different set design then HTML and/or native GUI.

> "It is also suggested that MUAs allow setting of an expiration date as 
> an option when composing messages"

+1, and I think, off hand, it should be OFF by default to not surprise 
people, and end results.

> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the 
> basis of an Expired header field unless given explicit instructions to 
> do so by the recipient."

Yes and No

No: 

As we know,  "Expiring messages" is already a common practice.   So if 
the user has not picked up (or displayed via online) his mail, it may 
eventually expire based on the local policy.  The difference is that it 
is not based on some explicit sender defined Expire Header flag which 
can only serve to accelerate an expiration process already in place - 
not defeat it.

Yes,

However, there are US EPCA provisions that relate to this.   Unexpected 
deletion or breaking of vendor/user contracts that cause harm is a great 
basis for a malpractice, censorship lawsuit.   So backends need to check 
with their legal council to see if this engineering design usage of an 
EXTERNAL EXPIRE FLAG (not internal local policy) is legally acceptable 
and/or presents product liability risk.

The legal question in court precedence has been who is in control of the 
message, the sender, the recipient, or the middle ware just holding the 
message - the passthru/storage system.    In one case of mail sniffing, 
a  lower court sided with the defendant - the middle ware, passthru, 
storage system - but this on appeal as it smacks against 20+ years of 
mail system tradition.  

This would be different (sniffing) than when a middle ware deletes the 
message, but similar if there is a design presumption that an external 
sender defined flag prevails over local policy - which is never going to 
happen.

Maybe we need two flags:

  Expire-Unreceived:  or Must-Delivery-By:
  Expire-Received:

The latter is for MUA, the former for backends as a "helper".

> "Mail Filters MUST NOT consider an expired header field as criteria to 
> be considered for deleting the message unless given explicit 
> instructions to do so by the recipient"

I think it depends on who created the mail filter.  the backend or the 
user?    Again, expiration of mail is already common place.  So all we 
really talking about here is an acceleration of that process.

Also,  what about new technology like DKIM which has expiration tags 
too?  I think the same issues apply here.  We should view the 
considerations here as well.

I agree in principle users should have a say on what happens to mail 
containing these sender defined flags or tags  before receiving the 
mail, but I don't think it should burned in stone with a MUST design.   
Backend can use this too,  but I agree they SHOULD provide the user option.

The reality though, in this era of AVS, everyone is constantly trying to 
come up with new AVS rules for their wares.  And among their AVS rules, 
they use it for other rule based messaging needs.  This one would be an 
easy one to add at both ends.  

>
> behavior for mail-to-NetNews gateways should also be specified.

For the most part, both the legal technical engineering behind this has 
to satisfy 1 to 1 private mail first.   

For public systems,  it changes - user legal rights are more relaxed 
when moving the mail for 1 to ALL.   For example, if we keep with a user 
permission system, then who is the USER in a 1 to ALL environment?

-- 
HLS

-- 
HLS

Date: Wed, 23 Jul 2008 16:50:53 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Tony Finch <[email-masked]>
CC: Keith Moore <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Tony Finch wrote:
> On Tue, 22 Jul 2008, Keith Moore wrote:
>   
>> yet another configuration knob to twiddle for an interface (MUA to message
>> store) that's already notoriously hard for users to get right.
>>
>> heck, we still have WAY too many people using POP or IMAP with cleartext
>> passwords, mostly because that's the configuration that "works" with all
>> clients and servers, and partially because there's no uniform language to
>> describe the other configurations.  (does "use secure authentication" mean
>> APOP, or POP+SSL over a reserved port, or POP with the STARTTLS command?)
>>     
>
> Usually none of the above :-) i.e. Microsoft proprietary authentication.
>
> Of course MUAs should just use the protocol's negotiation features to
> auto-configure the most secure settings possible. I get so annoyed that
> they don't.
>
> Tony.
>   

Are you referring to CAPA  Tony?

I guess you both right - Heck, by far I find sysops prefer to use POP 
BEFORE SMTP as the easiest - no instructions, less support required 
method to give their users instant auto-temporary-access to SMTP relay. 
:-)   And thats a big item because its far easier than having to provide 
a link to variant MUA brand server login setup page.

In regards to the common MUA Server Account settings

     [X] Keep Mail on Server for _XX_ days

I always found this default setting to be sort of pompous on the side of 
MUA to assume they have real say on what servers do with received and 
unreceived mail storage.  

Nonetheless, if this 2822 Expire proposal moves on, I can only it see it 
being part of this common setup section.  There would be two parts to 
consider:

  a) Online storage where the server having unreceived messages with 
expire flags

     [X] Server MAY expire unreceived mail using RFC XXXX

  b) offline storage (picked up mail) which expires on the  MUA side.

     [X] Delete Expired Mail On Server

Also, I think this proposal will need to touch base with DKIM expiration 
tags as well.

-- 
HLS

Date: Wed, 23 Jul 2008 20:35:11 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Hector Santos <[email-masked]>, Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Tue, 22 Jul 2008, Keith Moore wrote:
>
> yet another configuration knob to twiddle for an interface (MUA to message
> store) that's already notoriously hard for users to get right.
>
> heck, we still have WAY too many people using POP or IMAP with cleartext
> passwords, mostly because that's the configuration that "works" with all
> clients and servers, and partially because there's no uniform language to
> describe the other configurations.  (does "use secure authentication" mean
> APOP, or POP+SSL over a reserved port, or POP with the STARTTLS command?)

Usually none of the above :-) i.e. Microsoft proprietary authentication.

Of course MUAs should just use the protocol's negotiation features to
auto-configure the most secure settings possible. I get so annoyed that
they don't.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: VARIABLE 3, BECOMING EAST 4 OR 5 LATER. SLIGHT OR MODERATE. FOG
PATCHES. GOOD, OCCASIONALLY VERY POOR.

Date: Wed, 23 Jul 2008 21:20:34 +0200
From: [email-masked]
To: undisclosed-recipients:;
Sender: [email-masked]

kalyani.oryx.com with esmtp id 1216840834-15340-215 for
[email-masked]; Wed, 23 Jul 2008 21:20:34 +0200
Message-Id: <[email-masked]>
Date: Wed, 23 Jul 2008 21:18:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from
  draft-ietf-mailext-new-fields-15
References: <[email-masked]>
  <[email-masked]> <[email-masked]>
  <[email-masked]> <[email-masked]>
  <1216822884.17711.202.camel@jmac>
In-Reply-To: <1216822884.17711.202.camel@jmac>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0

Jeff Macdonald writes:
> On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
>>  "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the 
>>  basis of an Expired header field unless given explicit instructions 
>>  to do so by the recipient."
>
> I find it very desirable to have MTAs generate a bounce if the message 
> is older than the Expired header.

We already have an RFC specifying that, 2852.

Arnt

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Jeff Macdonald <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: ietf-822 <[email-masked]>
Organization: e-Dialog
Date: Wed, 23 Jul 2008 15:08:31 +0000
Sender: [email-masked]

On Wed, 2008-07-23 at 07:51 -0700, Ned Freed wrote:

> If you want this sort of service at the transport level, use the DELIVERBY
> extension, not an Expired: header. This is what it is for. IMO Expired: should
> only be used as an MUA-level facility.

Thanks for the pointer Ned.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

From: "Michael Welzl" <[email-masked]>
To: <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Wed, 23 Jul 2008 17:06:07 +0200
Sender: [email-masked]

> > People are different. I'd be more than happy to let my MUA
> > even silently delete past:
> >
> > * talk announcements
> > * CFPs
> > * special offers
> > * "out of the office messages"
> >
> (I'd happily just delete special offers and out of office messages,
> whatever the date is...)
>
> The problem is that you don't know what an 'expired' message is about
> unless you read it.
>
> People don't always do things right. So, a mailing list admin might well
> set up a 'you have 3 days to authenticate your subscription' message
> with an expiry date, or someone might send you a bill payment reminder
> with an expiry date of when it's due or whatever. You can be sure
> someone will use it in a way YOU don't want them to use it or think it
> should be used (or even ways that any standard prohibits). That's just
> the way people are... The amount of badly formed non-spam messages we
> receive is incredible, and the MIME/RFC822 standards have been around
> for years. If people can't get that right even now, you can guarantee
> that people will use 'expire' in an inappropriate way.
>
> So, would you still be happy to have your MUA silently delete expired
> messages?

Believe it or don't: yes.
Granted, when I said "silently delete", I meant "silently move it to my
trashcan
folder, which is what my MUA does when I delete emails. This way, if I
lose something and start to wonder what's wrong, I can still look things up
in the trash. If I don't start to wonder what's wrong, I believe I have the
right
to assume it's the sender's fault that their message never reached me. This
is what they risk when falsely setting the expiry date.

Other people could use it to automatically move emails to a suitable
folder, which makes email reading more efficient and still doesn't
let them miss the stuff that you mention above. But they can regard
it as low priority and go through it if and when they consider it
appropriate.

> AFAICS, the only safe way to use 'expire' would either be for it not to
> move/delete messages at all (in which case, what's the point) or to have
> different rules handling expire differently from different senders (when
> you know how THAT sender uses it), but this would only be useful if you
> repeatedly got expired messages from particular people (which is doubtful)

I disagree, on the basis of what I said above.

> (I do wonder, how important is this anyway? How often do you receive
> messages after they would have expired? The only time I can think it
> would be even slightly useful is if you've just come back from a
> vacation and haven't checked your mail whilst you've been away, but then
> a few CFP or talk announcements is going to be irrelevant amongst all
> the other thousands of semi-junk messages you'll have received!)

I agree that this would be especially useful (but not "the only time
when this would be even slightly useful") after a holiday. The few
announcements are not going to be irrelevant among the other
semi-junk things.

Something more time consuming, to give you one more example:

"Michael, please do this until ... messages" - where you have to
carefully read the whole thing, only to find out that the sender
has absolutely no use for what he demanded by the time you
read this message. That happens to me on a regular basis and
is really annoying.

Putting all of this together, for me and I'm sure that a lot of other
people, an expired field would be well worth having. You shoudln't
make your own personal preferences and daily life with email the
standard.

Probably we (as we discuss on this list) are not even good examples.
There are newspaper articles and even books discussing how to
deal with emails, for higher level managers - I'm sure that, for these
people, any small contribution to reducing the number of daily emails
is extremely valuable.

> I don't have a massive problem with an 'expires' header, I just see it
> as, at best, pointless, and at worst, dangerous in the hands of an
> unthinking user (of which there are many using the Internet).

Pointless: this is based on your personal preference which you
outlined above.

Dangerous: no, because of its strictly advisory nature. You would have
to be unthinking enough to set your mail client to always delete expired
emails on purpose, then wonder what's wrong. This is equivalent to
formatting a hard disk on purpose, then wondering what's wrong - that
a user could do that is the inevitable risk that comes with every
functionality
you give him (for once, I think it's actually better to use the male form,
for
the sake of political correctness!  :-)   ), but this should not be at the
cost
of the rest of us.

Cheers,
Michael

Date: Wed, 23 Jul 2008 07:51:22 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Jeff Macdonald <[email-masked]>
Cc: ietf-822 <[email-masked]>
Sender: [email-masked]

> On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
> > "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis
> > of an Expired header field unless given explicit instructions to do so
> > by the recipient."

> I find it very desirable to have MTAs generate a bounce if the message
> is older than the Expired header.

I do not. The problem with trying to do this at the MTA level is that the
preferences of the recipient cannot be properly taken into account.

If you want this sort of service at the transport level, use the DELIVERBY
extension, not an Expired: header. This is what it is for. IMO Expired: should
only be used as an MUA-level facility.

				Ned

Date: Wed, 23 Jul 2008 15:34:39 +0100
From: Paul Smith <[email-masked]>
To: Michael Welzl <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:
> People are different. I'd be more than happy to let my MUA
> even silently delete past:
>
> * talk announcements
> * CFPs
> * special offers
> * "out of the office messages"
>   
(I'd happily just delete special offers and out of office messages, 
whatever the date is...)

The problem is that you don't know what an 'expired' message is about 
unless you read it.

People don't always do things right. So, a mailing list admin might well 
set up a 'you have 3 days to authenticate your subscription' message 
with an expiry date, or someone might send you a bill payment reminder 
with an expiry date of when it's due or whatever. You can be sure 
someone will use it in a way YOU don't want them to use it or think it 
should be used (or even ways that any standard prohibits). That's just 
the way people are... The amount of badly formed non-spam messages we 
receive is incredible, and the MIME/RFC822 standards have been around 
for years. If people can't get that right even now, you can guarantee 
that people will use 'expire' in an inappropriate way.

So, would you still be happy to have your MUA silently delete expired 
messages?

AFAICS, the only safe way to use 'expire' would either be for it not to 
move/delete messages at all (in which case, what's the point) or to have 
different rules handling expire differently from different senders (when 
you know how THAT sender uses it), but this would only be useful if you 
repeatedly got expired messages from particular people (which is doubtful)

(I do wonder, how important is this anyway? How often do you receive 
messages after they would have expired? The only time I can think it 
would be even slightly useful is if you've just come back from a 
vacation and haven't checked your mail whilst you've been away, but then 
a few CFP or talk announcements is going to be irrelevant amongst all 
the other thousands of semi-junk messages you'll have received!)

I don't have a massive problem with an 'expires' header, I just see it 
as, at best, pointless, and at worst, dangerous in the hands of an 
unthinking user (of which there are many using the Internet).

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 23 Jul 2008 16:23:25 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 53
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Paul Smith wrote:

> what would you want the recipient MUA to do with these.

Whatever you like them to do, nothing is a valid option.

Some MUAs offer "priorities" (high-normal-bulk, or similar),
you could let your MUA treat "expired" mails as "bulk".

MUAs present "unread" mail in some order.  You could let
your MUA display "expired" mails last, or automatically
flag such mails as "read". =20

> Automatically moving them into another folder when they
> arrive is nearly the same as automatically deleting them
> as far as many users goes

Depends on the user.  I can't guarantee it, but I do check
spam folders (briefly), and rescue what's no spam.  Mostly
in an attempt to educate GMail.  With another ISP I check
the spam folder when its content is over 10 mails after
about a week.  IOW, I look at it, but only rarely.

GMail filters are not very sophisticated at the technical
side (=3D they are for ordinary users, not the folks on this
list :-), but in theory they could offer to "label" expired
mails as "expired". =20

Whatever it was that "expired" back in 2007, likely I don't
need it anymore in 2008.  "Expires:" might help to sort and
trim old mail archives.

> "confirm your subscription to list X in the next 3 days"
> is still important if you receive it 4 days later. Now you
> know you need to try again to get onto the list.

We're not in the same parallel universe.  If that was really
my subscription I'd have confirmed it immediately, therefore
it was somebody else claiming to be me while I was absent :-)

> My problem is that I can't think of anything which is=20
> *absolutely* no use after a certain date

That is no big problem, you then simply don't use this info.
There are things in e-mail (not only certain header fields)
I never use, but hopefully others can make good use of them.

The attempt to revive "Expires:" is a long shot, and maybe
it won't get traction.  But based on Keith's semantics I
think it is relatively harmless as worst case, and as best
case potentially useful.

 Frank

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Jeff Macdonald <[email-masked]>
To: ietf-822 <[email-masked]>
Organization: e-Dialog
Date: Wed, 23 Jul 2008 14:21:24 +0000
Sender: [email-masked]

On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
> of an Expired header field unless given explicit instructions to do so 
> by the recipient."

I find it very desirable to have MTAs generate a bounce if the message
is older than the Expired header.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

Date: Wed, 23 Jul 2008 07:03:19 -0700 (PDT)
From: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
To: Keith Moore <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

> How about this: "The sender believes this message will be irrelevant
> after the indicated date/time."

If memory serves, this matches the X.400 definition pretty closely. (Note that
the X.400 definition isn't something you'll find in any RFC - the various
X.400-related RFCs only define mappings, for the most part the specification of
X.400 field semantics is left to X.400 itself.)

> "This field is primarily intended for use between senders and recipients
> and their agents, rather than by message transport.    It is suggested
> that the default behavior of an MUA with respect to the expires header
> field should be to display such a message in a distinguished way.  For
> example, the message could be displayed with gray text rather than
> black, or in a different font than normal, or (in summaries) with an
> image of an hourglass with the sand at the bottom."

> "It is also suggested that MUAs allow setting of an expiration date as
> an option when composing messages"

I wonder if it is worth saying something about how it is RECOMMENDED that the
user be allowed to pick from a calender or some other graphical tool rather
than always having to type in a date directly... OK, probably not.

> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis
> of an Expired header field unless given explicit instructions to do so
> by the recipient."

> "Mail Filters MUST NOT consider an expired header field as criteria to
> be considered for deleting the message unless given explicit
> instructions to do so by the recipient"

This text seems very reasonable to me.

> behavior for mail-to-NetNews gateways should also be specified.

If someone wants to write it, sure, but I don't think defining this mapping is
a prerequisite to this specification being viable any more than I think a
mapping to MMS or any other serivce email is routinely gatewayed into is
required.

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 23 Jul 2008 15:45:19 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 39
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> How about this: "The sender believes this message will be irrelevant=20
> after the indicated date/time."
=20
> "This field is primarily intended for use between senders and =
recipients=20
> and their agents, rather than by message transport.    It is suggested =

> that the default behavior of an MUA with respect to the expires header =

> field should be to display such a message in a distinguished way.  For =

> example, the message could be displayed with gray text rather than=20
> black, or in a different font than normal, or (in summaries) with an=20
> image of an hourglass with the sand at the bottom."
=20
> "It is also suggested that MUAs allow setting of an expiration date as =

> an option when composing messages"
=20
> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the =
basis=20
> of an Expired header field unless given explicit instructions to do so =

> by the recipient."
=20
> "Mail Filters MUST NOT consider an expired header field as criteria to =

> be considered for deleting the message unless given explicit=20
> instructions to do so by the recipient"

+1 (or rather +5)
=20
> behavior for mail-to-NetNews gateways should also be specified.

Transparent, "Expires:" can be kept as is (modulo magic SP in news)

 Frank

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 15:29:25 +0200
Sender: [email-masked]

Hi,

> So, what would you want the recipient MUA to do with these. The
> consensus seems to be that they should still receive them - so what
> difference does the 'expires' make? Automatically moving them into
> another folder when they arrive is nearly the same as automatically
> deleting them as far as many users goes! Showing them in grey or
> another colour doesn't stop people having to read them to see if
> they've missed something important.

Showing them in grey (or something similar) should be the
default behavior, but a reasonable MUA would allow a user
like me to let the emails automatically be deleted (or
moved to a folder, which, as you correctly state, is
quite similar to deletion). That should be an option
for people who want it, and I guess it would.

> "confirm your subscription to list X in the next 3 days" is still
> important if you receive it 4 days later. Now you know you need to try
> again to get onto the list.

Let's apply the semantics that we all more or less seem
to agree on here, and which Keith Moore just beautifully
phrased as:

"The sender believes this message will be irrelevant 
after the indicated date/time."

Then this is a bad example, as the message does not become
irrelevant after the next 3 days. It would be foolish for
the sender to believe that it does become irrelevant (and
foolish to configure a mailing list system to act that way).

> "I'm out of the office until ..." may be important, you may have been
> bad-mouthing a contact because they hadn't replied to you earlier, and
> now you'll know why

You have no right to bad-mouth a contact when you configure
your MUA to automatically delete expired emails. Given our
previous discussion, it must have been your intention to
configure your MUA in this way, so you understand the option
well enough to know better than to bad-mouth the person
just for using an expiry date.

> "special offer valid until ..." may still be important from the
> sender's point of view as a "buy our wonderful flying car for only
> $15,000 before 30th July, look how amazing it is..." is still a good
> advertisement if it's received on the 1st August, and the recipient
> may still want it even though the special offer has expired.

No, this is truly outdated information - by making use
of the expiry date at the receiving end, you either
declare a general interest in such things that have
become irrelevant from the sender's point of view,
or not, depending on how many emails you get, how
much time you have, and what kind of person you are.

Take talk announcements and CFP's, which I used as an
example before: of course you can construct a case
where a person would be interested in such emails even
when they're over. Say you're the institute head here,
interested in how many and what kind of talks happen -
of course you also want to be informed when the talks
are in the past, but most people won't.

If the current date would be incorporated in filters
of MUAs as something to check against, such a person
could be properly served - and adding this function
would seem to be the most obvious and easy way to
deal with the expiry date in a MUA in my opinion.

> > Good examples apparently require some kind of mailbot
> > on the sender's side.  It is less useful for ordinary
> > (sending) MUAs, e.g., "happy birthday" with Expires: 
> > makes no sense, or does it ?
> >   
> No it doesn't. If 'happy birthday' arrived late, you'd still want the
> recipient to know you'd thought of them, so in that case 'better late
> than never' applies.

Right, that's just a bad example.

> 'expires' only makes sense (IMV) if it would reduce the mail to be
> read by the recipient by getting rid of stuff that's absolutely no use
> any more. In that case, it may as well be deleted automatically - but
> no one wants that. My problem is that I can't think of anything which
> is *absolutely* no use after a certain date (which *would* have been
> of some use before that date). So, you'd still need to read expired
> mail to see if it's of some use to you - in which case what's the
> point?

People are different. I'd be more than happy to let my MUA
even silently delete past:

* talk announcements
* CFPs
* special offers
* "out of the office messages"

Cheers,
Michael

Date: Wed, 23 Jul 2008 15:24:38 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Michael Welzl wrote:
> On Wed, 2008-07-23 at 10:19 +0100, Chris Haynes wrote:
>> 2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?
> 
> Yes, because these semantics aren't very complicated.

A possible justification comes from considering that hard disk space 
has become much cheaper in recent years, thus many servers allow more 
messages to live in a given mailbox, and users have to face archiving 
issues. A MUA I use offers the option to move all past month Sent 
messages to a new subfolder. I'd prefer that to be yearly. If 
archiving were driven by expiry date, it would be easier to customize.

One could then be tempted to set a default expiry date on messages 
that don't have one already. In that respect, it may make sense to 
either add an attribute specifying who did set the expiry date, or 
state that only the author is allowed to do that. If a message's 
author said it's expired, a MUA should generate a warning whenever a 
user tries to reply to it, and propose to write a new message instead, 
prompting for a new subject in case the user agrees.

Just a couple of clean, simplistic, non-technical issues...

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 15:15:54 +0200
Sender: [email-masked]

On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
> Frank Ellermann wrote:
> > Paul Smith wrote:
> > 
> >> All I can figure out so far is that the expiry of a
> >> message implies it's possibly not quite as important,
> >> urgent or valid to the sender/recipient/some-other-
> >> person as it would have been before it expired.
> >  
> >> I'm not sure that's a tight enough definition :)
> > 
> > From a sender's POV "expired" could mean "if you read
> > this mail later whatever I wanted is not more relevant".
> 
> How about this: "The sender believes this message will be irrelevant 
> after the indicated date/time."
> 
> "This field is primarily intended for use between senders and recipients 
> and their agents, rather than by message transport.    It is suggested 
> that the default behavior of an MUA with respect to the expires header 
> field should be to display such a message in a distinguished way.  For 
> example, the message could be displayed with gray text rather than 
> black, or in a different font than normal, or (in summaries) with an 
> image of an hourglass with the sand at the bottom."
> 
> "It is also suggested that MUAs allow setting of an expiration date as 
> an option when composing messages"
> 
> "MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
> of an Expired header field unless given explicit instructions to do so 
> by the recipient."
> 
> "Mail Filters MUST NOT consider an expired header field as criteria to 
> be considered for deleting the message unless given explicit 
> instructions to do so by the recipient"
> 
> behavior for mail-to-NetNews gateways should also be specified.

Beautiful! in particular the semantics, "The sender believes...
irrelevant..." - that's concise, and exactly the meaning we're
looking for, I think.

Cheers,
Michael

Date: Wed, 23 Jul 2008 15:08:54 +0200
From: [email-masked]
To: undisclosed-recipients:;
Sender: [email-masked]

kalyani.oryx.com with esmtp id 1216818534-15340-24 for
[email-masked]; Wed, 23 Jul 2008 15:08:54 +0200
Message-Id: <3YoOne/OCLp3IUWqip/[email-masked]>
Date: Wed, 23 Jul 2008 15:07:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from
  draft-ietf-mailext-new-fields-15
References: <[email-masked]>
  <[email-masked]> <[email-masked]>
  <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0

Paul Smith writes:
> So, what would you want the recipient MUA to do with these. The 
> consensus seems to be that they should still receive them - so what 
> difference does the 'expires' make?

That isn't quite correct, but RFC 2852 handles the cases where it isn't true.

2852 is fine and does a useful job for the (few) people who use it. I 
don't see what this Expir{es,y-Date} header field really offers.

Arnt

Date: Wed, 23 Jul 2008 08:16:35 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Frank Ellermann wrote:
> Paul Smith wrote:
> 
>> All I can figure out so far is that the expiry of a
>> message implies it's possibly not quite as important,
>> urgent or valid to the sender/recipient/some-other-
>> person as it would have been before it expired.
>  
>> I'm not sure that's a tight enough definition :)
> 
> From a sender's POV "expired" could mean "if you read
> this mail later whatever I wanted is not more relevant".

How about this: "The sender believes this message will be irrelevant 
after the indicated date/time."

"This field is primarily intended for use between senders and recipients 
and their agents, rather than by message transport.    It is suggested 
that the default behavior of an MUA with respect to the expires header 
field should be to display such a message in a distinguished way.  For 
example, the message could be displayed with gray text rather than 
black, or in a different font than normal, or (in summaries) with an 
image of an hourglass with the sand at the bottom."

"It is also suggested that MUAs allow setting of an expiration date as 
an option when composing messages"

"MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis 
of an Expired header field unless given explicit instructions to do so 
by the recipient."

"Mail Filters MUST NOT consider an expired header field as criteria to 
be considered for deleting the message unless given explicit 
instructions to do so by the recipient"

behavior for mail-to-NetNews gateways should also be specified.

Keith

Date: Wed, 23 Jul 2008 13:04:51 +0100
From: Paul Smith <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040707050202030006040101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Frank Ellermann wrote:
> Paul Smith wrote:
>
>   
>> All I can figure out so far is that the expiry of a
>> message implies it's possibly not quite as important,
>> urgent or valid to the sender/recipient/some-other-
>> person as it would have been before it expired.
>>     
>  
>   
>> I'm not sure that's a tight enough definition :)
>>     
>
> From a sender's POV "expired" could mean "if you read
> this mail later whatever I wanted is not more relevant".
>
> Examples:
> "confirm your subscription to list X in the next 3 days"
> "special offer valid until 2008-06-30"
> "I'm out of office until 2008-07-18"
>   
So, what would you want the recipient MUA to do with these. The 
consensus seems to be that they should still receive them - so what 
difference does the 'expires' make? Automatically moving them into 
another folder when they arrive is nearly the same as automatically 
deleting them as far as many users goes! Showing them in grey or another 
colour doesn't stop people having to read them to see if they've missed 
something important.

"confirm your subscription to list X in the next 3 days" is still 
important if you receive it 4 days later. Now you know you need to try 
again to get onto the list.

"I'm out of the office until ..." may be important, you may have been 
bad-mouthing a contact because they hadn't replied to you earlier, and 
now you'll know why

"special offer valid until ..." may still be important from the sender's 
point of view as a "buy our wonderful flying car for only $15,000 before 
30th July, look how amazing it is..." is still a good advertisement if 
it's received on the 1st August, and the recipient may still want it 
even though the special offer has expired.

> Good examples apparently require some kind of mailbot
> on the sender's side.  It is less useful for ordinary
> (sending) MUAs, e.g., "happy birthday" with Expires: 
> makes no sense, or does it ?
>   
No it doesn't. If 'happy birthday' arrived late, you'd still want the 
recipient to know you'd thought of them, so in that case 'better late 
than never' applies.

'expires' only makes sense (IMV) if it would reduce the mail to be read 
by the recipient by getting rid of stuff that's absolutely no use any 
more. In that case, it may as well be deleted automatically - but no one 
wants that. My problem is that I can't think of anything which is 
*absolutely* no use after a certain date (which *would* have been of 
some use before that date). So, you'd still need to read expired mail to 
see if it's of some use to you - in which case what's the point?

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

--------------040707050202030006040101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Frank Ellermann wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Paul Smith wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">All I can figure out so far is that the expiry of a
message implies it's possibly not quite as important,
urgent or valid to the sender/recipient/some-other-
person as it would have been before it expired.
    </pre>
  </blockquote>
  <pre wrap=""><!----> 
  </pre>
  <blockquote type="cite">
    <pre wrap="">I'm not sure that's a tight enough definition :)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
>From a sender's POV "expired" could mean "if you read
this mail later whatever I wanted is not more relevant".

Examples:
"confirm your subscription to list X in the next 3 days"
"special offer valid until 2008-06-30"
"I'm out of office until 2008-07-18"
  </pre>
</blockquote>
So, what would you want the recipient MUA to do with these. The
consensus seems to be that they should still receive them - so what
difference does the 'expires' make? Automatically moving them into
another folder when they arrive is nearly the same as automatically
deleting them as far as many users goes! Showing them in grey or
another colour doesn't stop people having to read them to see if
they've missed something important.<br>
<br>
"confirm your subscription to list X in the next 3 days" is still
important if you receive it 4 days later. Now you know you need to try
again to get onto the list.<br>
<br>
"I'm out of the office until ..." may be important, you may have been
bad-mouthing a contact because they hadn't replied to you earlier, and
now you'll know why<br>
<br>
"special offer valid until ..." may still be important from the
sender's point of view as a "buy our wonderful flying car for only
$15,000 before 30th July, look how amazing it is..." is still a good
advertisement if it's received on the 1st August, and the recipient may
still want it even though the special offer has expired.<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Good examples apparently require some kind of mailbot
on the sender's side.  It is less useful for ordinary
(sending) MUAs, e.g., "happy birthday" with Expires: 
makes no sense, or does it ?
  </pre>
</blockquote>
No it doesn't. If 'happy birthday' arrived late, you'd still want the
recipient to know you'd thought of them, so in that case 'better late
than never' applies.<br>
<br>
'expires' only makes sense (IMV) if it would reduce the mail to be read
by the recipient by getting rid of stuff that's absolutely no use any
more. In that case, it may as well be deleted automatically - but no
one wants that. My problem is that I can't think of anything which is
*absolutely* no use after a certain date (which *would* have been of
some use before that date). So, you'd still need to read expired mail
to see if it's of some use to you - in which case what's the point?<br>
<pre class="moz-signature" cols="72">-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows</pre>
</body>
</html>

--------------040707050202030006040101--

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 13:29:37 +0200
Sender: [email-masked]

On Wed, 2008-07-23 at 11:20 +0100, Paul Smith wrote:
> Chris Haynes wrote:
> > 2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?
> >   
> I'm not sure they can be expressed in any way at all... All I can figure 
> out so far is that the expiry of a message implies it's possibly not 
> quite as important, urgent or valid to the 
> sender/recipient/some-other-person as it would have been before it expired.
> 
> I'm not sure that's a tight enough definition :)

I think that this is as good as it gets. In a previous email, I wrote:

> "it becomes less important after that date because it is somehow
> bound to it".

which has the same meaning. We automatically agree on this meaning
because it's obvious, so defining it cleanly shouldn't be too difficult.

Cheers,
Michael

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Wed, 23 Jul 2008 13:14:19 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 23
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Paul Smith wrote:

> All I can figure out so far is that the expiry of a
> message implies it's possibly not quite as important,
> urgent or valid to the sender/recipient/some-other-
> person as it would have been before it expired.
=20
> I'm not sure that's a tight enough definition :)

>From a sender's POV "expired" could mean "if you read
this mail later whatever I wanted is not more relevant".

Examples:
"confirm your subscription to list X in the next 3 days"
"special offer valid until 2008-06-30"
"I'm out of office until 2008-07-18"

Good examples apparently require some kind of mailbot
on the sender's side.  It is less useful for ordinary
(sending) MUAs, e.g., "happy birthday" with Expires:=20
makes no sense, or does it ?

 Frank

To: [email-masked]
Xref: clerew local.mime:5338
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Wed, 23 Jul 2008 09:54:12 GMT
Lines: 35
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

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

I think the most any standard would say is that agents MAY consign that
message to the bit bucket after that date.

But, traditionally, we do not prescribe the inner workings of MUAs (though
we might drop hints as to the *intended* use of some feature). One would
hope that implementation of that "MAY" would be a configurable option in
any decent MUA (but has anyine ever seen a "decent" MUA :-( ).

Of more interest is whether any standard introducing this header should
also try to update the IMAP and POP3 standards by defining circumstances
where such messages could be dropped (but, again, some user configuration
would have to be built in - but then user configuration is already a
feature of IMAP).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 12:34:43 +0200
Sender: [email-masked]

On Wed, 2008-07-23 at 10:19 +0100, Chris Haynes wrote:
> 
> On Tuesday, July 22, 2008 at 10:15:06 AM, 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).
> 
> Many of the responses so far have expressed concern about what UAs might or might not do with this information.  Debating these UA technical options are secondary to two key questions:
> 
> 1) Would the widespread introduction / use of this header by senders cause any damage to / loss of messages in (unmodified) UAs as currently deployed?

Surely not: for these UAs, it's just a new, so far unknown,
header, and such headers are generally ignored AFAIK.

> 2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?

Yes, because these semantics aren't very complicated.

> The ues of / content of the 'Expiry' part is not a communication between protocol-implementors, it is a communication between message senders and recipients.
> 
> Where a UA provides user-configurable facilities to recognise and respond to 'Expiry', its user will have to make decisions about how she wants expired messages to be handled. So she has to know, usually in advance of receiving any specific message, just what an 'expired' message means to her, and so how she wants the UA to handle it for her.
> 
> Similarly, the sender has to be aware just how recipients will interpret the 'Expiry' date, and consider whether the recipient behaviour (conditioned by the 'generally-understood' meaning of the value) is what is intended.
> 
> It's important to note that we are not talking here about a semantic definition using the special language which satisfies IETF junkies. It has to be one that end-users (senders and recipients) can understand.
> 
> Is that possible; can the IETF editorial processes achieve the necessary linguistic clarity and simplicity? 

I say yes, if we make an effort to be clear and simple here,
because the "Expiry" concept is really a simple one.

Cheers,
Michael

Date: Wed, 23 Jul 2008 11:20:20 +0100
From: Paul Smith <[email-masked]>
To: Chris Haynes <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Chris Haynes wrote:
> 2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?
>   
I'm not sure they can be expressed in any way at all... All I can figure 
out so far is that the expiry of a message implies it's possibly not 
quite as important, urgent or valid to the 
sender/recipient/some-other-person as it would have been before it expired.

I'm not sure that's a tight enough definition :)

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:53:43 +0200
Sender: [email-masked]

> > This proposal can serve well to standardize the header itself,  thats 
> > the easy part.  But how it will apply is a different ball of wax.   The 
> > MUA side can deal with it by moving it into folders or deleting it.    
> 
> ...or by showing them in a different color, or optionally hiding them in 
> summaries.  if the only options most MUAs provided were effectively 
> deleting them, that would IMHO be a bad result.

Again, we could explicitly specify that this MUST NOT be done,
and include proper reasoning for this decision. One would be
stupid to implement a MUA which still does that then.

Cheers,
Michael

Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:49:20 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 13:25 -0400, Hector Santos wrote:
> Michael,
> 
> Many backend systems have their own email policies.   What you are 
> describing seem to be more preferences or hints, which is good. 

Indeed it's just a preference / hint. Welcome onboard the
already full "it should only be advisory" boat (the other
boat is entirely empty, btw   :-)    ).

> End-users can use them (2822 expiration header) with their MUAs.  
> Backends can use them too.

Right... thanks for the details you give in the rest of your
email, I totally agree that these things could be handled
(and should be possible to handle) in backend systems, and
we'll try to make sure that the spec doesn't implicitly
state something against doing this.

[snip]

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

Right

cheers,
Michael

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:45:49 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 11:53 -0400, Nathaniel Borenstein wrote:
> It seems to me that the problem that could derail this idea is the  
> difference between the notions of mandatory and advisory expiration.   
> It's the same problem that has often derailed discussions of  
> "unsending" a message.  It's fairly easy to specify how to send a  
> message that says "I'd like to withdraw that message that I just sent"  
> but impossible to agree that receiving agents should automatically  
> implement that request regardless of the recipient's preferences.   
> (The juiciest messages are the ones most likely to be withdrawn.)
> 
> As long as we are all clear that such expirations/withdrawals are  
> advisory, I don't see any problem with standardizing them.  For  

I'm 100% for "just advisory" - I always thought about
the proposal this way. From the other messages, I get the
impression that nobody's in favor of what you call "mandatory
expiration", and neither am I.

> example, I like the idea that I might configure meeting invitations to  
> automatically move from my inbox to my junk folder (or a special  
> expired folder) if I don't get to them in time, but I'm less happy  
> with the idea of such invitations simply disappearing without a  
> trace.  Others, of course, might prefer the quiet disappearance.  As  
> long as the recipient has control, and the new field simply indicates  
> the sender's desires/intentions, I think it's a great idea.  Moreover,  

This is exactly how I see it. The recommendation should probably
be to mark expired messages somehow by default, with a hint
that the user could be given some means to enable other behavior,
such as silently deleting such emails. Anyhow the spec should
clearly state that silently deleting MUST NOT be the default behavior.

> if we specify a way for one message to specify that a previous one had  
> "expired" we could solve both of these problems (advisory message  
> expiration and advisory message retraction) with a single  
> specification.  I think it's a great idea, but we should manage  
> expectations so that people are aware that these expirations/ 
> retractions can always be ignored.  -- Nathaniel

I'm against that, simply because one message refering to another
one opens up a can of worms that is too large. Let's keep this
small and simple. Anyway I don't see a big benefit from combining
these specs - the "another message has expired" spec could be
developed independently, and perhaps build upon the one that
I'm suggesting here.

Cheers,
Michael

Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:39:20 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 12:05 -0700, Dave Crocker wrote:
> 
> 
> Lisa Dusseault wrote:
> > I'd like to see commitments or indications from MUA implementors that 
> > they would plan to implement if it were standardized.
> 
> 
> Lisa,
> 
> It could be interesting to make this a regular requirement, for 
> authorizing standards work.  (The IETF used to have a version of it.)\
> 
> But it isn't common practice now, so I'm curious what prompts imposing 
> the requirement for this case?
> 
> d/

I agree that this isn't common practice now, but I also agree
that it would be useful to see such commitment. I can get in
touch with developers of MUAs and ask them for such a commitment
(without myself commiting to give up in case that they don't
react! because I think that *requiring* such a commitment
beforehand is at least unusual).

Any suggestions about which MUA implementors I should contact?

Cheers,
Michael

PS: I think that MS with its not (or no-longer) standard-conforming
approach make a point for us: they already have the feature, and
surely doing this in a conformant way would be an easy change
(they could still additionally keep their old header in emails
if they want), and potentially beneficial for them.

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:34:51 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 15:08 +0000, Jeff Macdonald wrote:
> 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.

Sounds good to me, thanks for the suggestion!

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

The way MS does it conforms with RFC 2822.
e.g.: Expiry-Date: Sat, 21 Jun 2008 12:00:00 +0200

In our proposal, in any case we'll definite it based on existing
related standards (such as "Expires" in RFC 4021 and possibly
also the netnews related expiry date that was previously mentioned)
as appropriately as possible. We'll have to look into this and
come up with a coherent and clean proposal.

Cheers,
Michael

Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Organization: University of Innsbruck
Date: Wed, 23 Jul 2008 11:27:19 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 11:04 -0400, Keith Moore wrote:
> 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.

That would be a stupid default behavior, and we could explicitly
recommend not to do this by default in the draft.

> I wonder if anyone believes that any email he sends ever becomes 
> pointless. :)

I believe in this. Again, talk (or, more general, event)
announcements and CFPs are nice examples IMO. They are
clearly bound to a date.

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

but standardization seems to be the only way to give this a try.

> After over 30+ years of email, MUA user interfaces still suck.  Granted, 
> it's a difficult problem.   When significant numbers of users still have 
> trouble dealing with the difference between reply / reply-all and 
> remembering to make a conscious decision about which to use in any 
> particular situation, I have little faith that they'll deal well with 
> relatively subtle things like expiration dates in either outgoing or 
> incoming mail.

Let MUA GUIs somehow mark expired emails by default then, by showing
them in light grey or something like that.

> >> 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.
> > 
> > Good ideas IMO. Surely the standard shouldn't prescribe
> > what exactly to do - these are things that your client
> > could do for you, or let you choose to do.
> 
> The problem is similar to that with the reply-to field.  In both cases 
> there's a conflict between the sender's expectation of what a recipient 
> _should_ do with the message, and with what the recipient actually wants 
> to do with the message.  The desire/need to avoid overly complex user 
> interfaces mudddies the waters even more.

I don't see a conflict in the "expired" semantics.

> > Simplicity is key. I propose to standardize only that one
> > thing, with the semantics being "it becomes useless after
> > that date". That really should be simple enough.
> 
> One problem with that definition is that the message is NOT useless 
> after that date.

Sorry, you're right, let me try to rephrase that:
"it becomes less important after that date because it is somehow
bound to it".

Cheers,
Michael

Date: Wed, 23 Jul 2008 10:19:38 +0100
From: Chris Haynes <[email-masked]>
Reply-To: Chris Haynes <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

On Tuesday, July 22, 2008 at 10:15:06 AM, 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).

Many of the responses so far have expressed concern about what UAs might or might not do with this information.  Debating these UA technical options are secondary to two key questions:

1) Would the widespread introduction / use of this header by senders cause any damage to / loss of messages in (unmodified) UAs as currently deployed?

2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?

The ues of / content of the 'Expiry' part is not a communication between protocol-implementors, it is a communication between message senders and recipients.

Where a UA provides user-configurable facilities to recognise and respond to 'Expiry', its user will have to make decisions about how she wants expired messages to be handled. So she has to know, usually in advance of receiving any specific message, just what an 'expired' message means to her, and so how she wants the UA to handle it for her.

Similarly, the sender has to be aware just how recipients will interpret the 'Expiry' date, and consider whether the recipient behaviour (conditioned by the 'generally-understood' meaning of the value) is what is intended.

It's important to note that we are not talking here about a semantic definition using the special language which satisfies IETF junkies. It has to be one that end-users (senders and recipients) can understand.

Is that possible; can the IETF editorial processes achieve the necessary linguistic clarity and simplicity? 

Chris Haynes

Date: Tue, 22 Jul 2008 17:28:39 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
CC: Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Hector Santos wrote:
> Keith Moore wrote:
>>
>> Michael Welzl wrote:
>>> 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.  
> 
> MUA like Firefox offer plug-in support that pretty much allow you do do 
> whatever you like.   Of course, plug-ins are not standard.

more to the point, they're not widely used enough to get traction for 
new email features.

> This proposal can serve well to standardize the header itself,  thats 
> the easy part.  But how it will apply is a different ball of wax.   The 
> MUA side can deal with it by moving it into folders or deleting it.    

...or by showing them in a different color, or optionally hiding them in 
summaries.  if the only options most MUAs provided were effectively 
deleting them, that would IMHO be a bad result.

> But how it applies with the server,  would be under the common 
> MUA/Server Interface options generally offered for the mail server 
> account.   So a new Expiration Headers option can be added:
> 
>     [X] Keep Mail on Server for Days: ____         <--- common MUA 
> feature to control server storage
>     [X] Support Expiration Headers                     <--- new RFC 
> related feature

yet another configuration knob to twiddle for an interface (MUA to 
message store) that's already notoriously hard for users to get right.

heck, we still have WAY too many people using POP or IMAP with cleartext 
passwords, mostly because that's the configuration that "works" with all 
clients and servers, and partially because there's no uniform language 
to describe the other configurations.  (does "use secure authentication" 
mean APOP, or POP+SSL over a reserved port, or POP with the STARTTLS 
command?)

> Both of which is at best a request to delete (DEL command) and no way 
> dictates or overrides what the server policy is in the area of mail 
> destruction.
> 
> A more useful MUA (OFFLINE or ONLINE) option would be to add a 3rd option:
> 
>     [X] Server MAY use Expire Headers to delete (or mail received) mail 
> before mail pickup.
> 
> As you pointed out, this can help lower the mail pickup payload 
> overhead, which can be fairly high these days with laissez-faire  usage 
> of html and attachments and over bloated wasted bandwidth of headers.

I already have way too much mail being either deleted or misfiled by 
spam filters.  The last thing I want is even more justification for MSPs 
to delete messages without my explicit consent.

Keith

Date: Tue, 22 Jul 2008 15:56:12 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Keith Moore <[email-masked]>
CC: Michael Welzl <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040705010803050804080204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Keith Moore wrote:
>
> Michael Welzl wrote:
>> 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.  

MUA like Firefox offer plug-in support that pretty much allow you do do 
whatever you like.   Of course, plug-ins are not standard.

> 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.
+1.    

This proposal can serve well to standardize the header itself,  thats 
the easy part.  But how it will apply is a different ball of wax.   The 
MUA side can deal with it by moving it into folders or deleting it.    
But how it applies with the server,  would be under the common 
MUA/Server Interface options generally offered for the mail server 
account.   So a new Expiration Headers option can be added:

    [X] Keep Mail on Server for Days: ____         <--- common MUA 
feature to control server storage
    [X] Support Expiration Headers                     <--- new RFC 
related feature

Both of which is at best a request to delete (DEL command) and no way 
dictates or overrides what the server policy is in the area of mail 
destruction.

A more useful MUA (OFFLINE or ONLINE) option would be to add a 3rd option:

    [X] Server MAY use Expire Headers to delete (or mail received) mail 
before mail pickup.

As you pointed out, this can help lower the mail pickup payload 
overhead, which can be fairly high these days with laissez-faire  usage 
of html and attachments and over bloated wasted bandwidth of headers./
/

-- 
HLS

--------------040705010803050804080204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Keith Moore wrote:
<blockquote cite="mid:[email-masked]" type="cite"><br>
Michael Welzl wrote:
  <br>
  <blockquote type="cite">That's what we have filters for! You could
let your client
    <br>
move the email to some subfolder, mark it somehow (light
    <br>
grey in the list, whatever - up to your client), or just
    <br>
delete it (like I would).
    <br>
  </blockquote>
  <br>
I'd love to believe that mail clients will be that flexible.&nbsp; </blockquote>
<br>
MUA like Firefox offer plug-in support that pretty much allow you do do
whatever you like.&nbsp;&nbsp; Of course, plug-ins are not standard.<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">But
I also have to consider that most mail clients today are still fairly
primitive as to what they can do with existing headers.&nbsp;&nbsp; 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.
  <br>
</blockquote>
+1.&nbsp;&nbsp;&nbsp;&nbsp; <br>
<br>
This proposal can serve well to standardize the header itself,&nbsp; thats
the easy part.&nbsp; But how it will apply is a different ball of wax.&nbsp;&nbsp; The
MUA side can deal with it by moving it into folders or deleting it.&nbsp;&nbsp;&nbsp;
But how it applies with the server,&nbsp; would be under the common
MUA/Server Interface options generally offered for the mail server
account.&nbsp;&nbsp; So a new Expiration Headers option can be added:<br>
<br>
&nbsp;&nbsp;&nbsp; [X] Keep Mail on Server for Days: ____&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;--- common MUA
feature to control server storage<br>
&nbsp;&nbsp;&nbsp; [X] Support Expiration Headers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;--- new RFC
related feature<br>
<br>
Both of which is at best a request to delete (DEL command) and no way
dictates or overrides what the server policy is in the area of mail
destruction.<br>
<br>
A more useful MUA (OFFLINE or ONLINE) option would be to add a 3rd
option:<br>
<br>
&nbsp;&nbsp;&nbsp; [X] Server MAY use Expire Headers to delete (or mail received) mail
before mail pickup.<br>
<br>
As you pointed out, this can help lower the mail pickup payload
overhead, which can be fairly high these days with laissez-faire&nbsp; usage
of html and attachments and over bloated wasted bandwidth of headers.<em><br>
</em><br>
<pre class="moz-signature" cols="72">-- 
HLS</pre>
</body>
</html>

--------------040705010803050804080204--

Date: Tue, 22 Jul 2008 12:05:38 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Lisa Dusseault <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

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

Lisa,

It could be interesting to make this a regular requirement, for 
authorizing standards work.  (The IETF used to have a version of it.)\

But it isn't common practice now, so I'm curious what prompts imposing 
the requirement for this case?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 22 Jul 2008 13:25:23 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Michael Welzl <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

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

Cc: Michael Welzl <[email-masked]>, [email-masked], [email-masked]
From: Lisa Dusseault <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Date: Tue, 22 Jul 2008 10:14:52 -0700
Sender: [email-masked]

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

Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Organization: e-Dialog
Date: Tue, 22 Jul 2008 15:08:09 +0000
Sender: [email-masked]

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.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

Date: Tue, 22 Jul 2008 11:04:54 -0400
From: Keith Moore <[email-masked]>
To: Michael Welzl <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header	from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

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
> become pointless. 

I wonder if anyone believes that any email he sends ever becomes 
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.

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.

After over 30+ years of email, MUA user interfaces still suck.  Granted, 
it's a difficult problem.   When significant numbers of users still have 
trouble dealing with the difference between reply / reply-all and 
remembering to make a conscious decision about which to use in any 
particular situation, I have little faith that they'll deal well with 
relatively subtle things like expiration dates in either outgoing or 
incoming mail.

>> 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.
> 
> Good ideas IMO. Surely the standard shouldn't prescribe
> what exactly to do - these are things that your client
> could do for you, or let you choose to do.

The problem is similar to that with the reply-to field.  In both cases 
there's a conflict between the sender's expectation of what a recipient 
_should_ do with the message, and with what the recipient actually wants 
to do with the message.  The desire/need to avoid overly complex user 
interfaces mudddies the waters even more.

>> (and regardless of how we define a message's expiry date, getting users 
>> to understand how to use such things consistently is even harder.)
> 
> Simplicity is key. I propose to standardize only that one
> thing, with the semantics being "it becomes useless after
> that date". That really should be simple enough.

One problem with that definition is that the message is NOT useless 
after that date.

Keith

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Tue, 22 Jul 2008 16:21:59 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 30
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:
=20
> 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. =20

 Frank

Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Organization: University of Innsbruck
Date: Tue, 22 Jul 2008 15:28:44 +0200
Sender: [email-masked]

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.

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

Good ideas IMO. Surely the standard shouldn't prescribe
what exactly to do - these are things that your client
could do for you, or let you choose to do.

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

When (s)he thinks that it's appropriate. I think it's appropriate
to do so when sending a CFP. If that feature would exist like
I envision, I would visit some of our secretaries and tell them
that it would be appropriate for the talk announcemennts that
they send around. (and there would, of course, be more examples)

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

There's really no other way than to try, and for properly
trying this, there's really no other way than to standardize
it. At most, we could try to find a company that already makes
use of the feature in Outlook, but that could be that company's
policy and not tell us much about whether the majority
of people would use it if that feature was generally standardized
and available everywhere.

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

Simplicity is key. I propose to standardize only that one
thing, with the semantics being "it becomes useless after
that date". That really should be simple enough.

Cheers,
Michael

Date: Tue, 22 Jul 2008 09:21:38 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

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)

Date: Tue, 22 Jul 2008 09:17:35 -0400
From: Keith Moore <[email-masked]>
To: Michael Welzl <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Intent to revive "expires" header from	draft-ietf-mailext-new-fields-15
Sender: [email-masked]

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

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

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date:  Tue, 22 Jul 2008 12:54:14 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 38
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

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

> if this is even the right place for this kind of discussion

Yes.  When your draft is in shape you can ask for a review
on the message-header list.  If you stick to the course "we
only want this existing news header field also for mail" it
should be simple (=3D less than three years to get the RFC :-)

 Frank

Subject: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
From: Michael Welzl <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Organization: University of Innsbruck
Date: Tue, 22 Jul 2008 11:15:06 +0200
Sender: [email-masked]

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)