[Top] [All Lists]

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

2008-07-23 15:48:15

Keith Moore wrote:
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.

+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."

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.


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:

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?



<Prev in Thread] Current Thread [Next in Thread>