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

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