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.
In my view, the conflictive issues are:
1) Servers which employ automatic purging of old messages
MAY let this field influence the purging process.
2) Servers which employ automatic purging of old messages
MUST NOT let this field influence the purging process.
3) Servers which employ automatic purging of old messages
SHOULD NOT let this field influence the purging process
without USER PERMISSION.
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