> 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.")
> yep
> > Now it might also be useful if there were a MTS feature that would let
> > a
> > 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
> > about
> > 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.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.