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