[Top] [All Lists]

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

2008-07-25 10:40:25

On Thu, 2008-07-24 at 09:49 -0400, Keith Moore wrote:
Jeff Macdonald wrote:

On Wed, 2008-07-23 at 08:16 -0400, Keith Moore wrote:
"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."

I find it very desirable to have MTAs generate a bounce if the message
is older than the Expired header.

(What does it mean for a message to be older than a header contained
within the message?  I assume you mean "... if the date in the Expired
header is after the current date.")


Now it might also be useful if there were a MTS feature that would let
sender say "don't bother delivering this message if you can't get it
there before <date>".  But I don't think that's what we're talking
here.  (and if there were such a feature it should be implemented in
SMTP rather in the message header).

it is what I was thinking and Ned rightly pointed out that DELIVERYBY
handles what I was looking for.

The only thing I don't like about that extension is it really needs a
3rd mode. If I understand the RFC correctly:

* mode R
means bounce message even if the DELIVERYBY time hasn't expired when
delivering to an MTA that doesn't support DELIVERYBY

* mode N
means attempt to deliver when time has expired but notify the sender

Neither of these does what I'd like. I need a mode that is like R but
will deliver to MTAs that do not support DELIVERYBY. This way the
originating can expire messages and doesn't have to worry if the rest of
the world supports DELIVERYBY.

This would be a mode where, depending on the path the message took, in some
cases the message would bounce if delayed and in other cases it will simply be
delivered late with no notification to anybody. And not only would you get
different results for different recipients, different sender locations, or
both, you're also likely to get different results over time from
the same sender-location/recipient combinations.

Pretty major violation of the least astonishment principle here. I really have
to wonder if it is worth it.

Unless of course I am mis-understanding section 4.1.4. I'm not sure how
a sending MTA knows it is sending email to a relay. I'm assuming all
receiving MTAs could be a relay.

The term "relay" here refers to sending the message on to another  system, as
opposed to performing final delivery on it.


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