ietf-822
[Top] [All Lists]

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

2008-07-29 19:18:45

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

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