ietf-822
[Top] [All Lists]

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

2008-07-27 10:59:19

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

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