Re: [Last-Call] Last Call: <draft-billon-expires-06.txt> (Updated Use of the Expires Message Header Field) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If a message had an EXPIRES-BY header, semantically past it's "due"
date, and an intermediate store-and-forward SMTP MTA decided to look
in its queue, would it be "wrong" for it to return to sender rather
than deliver? If the header could be shown to be origin specified, and
not arbitrarily added?

I admit to having more than one view on that. I can see the utility, I
shudder at the implications for things sent but not seen, expires not
withstanding.

-G

On Tue, Dec 6, 2022 at 1:15 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 12/5/22 12:19, Alessandro Vesely wrote:
>
> > The I-D covers specified creators in Section 5:
> >
> >                                For instance, systems may allow
> >    automatic rules to clean up expired email from specific message
> >    creators or with defined characteristics, or to provide a mode to
> >    quickly handle all expired email.
>
> In my opinion, this is far too vague, and leaves too much room for
> parties other than the recipient to impose such "clean up".
>
> > Perhaps it should add that any auto-delete configuration should be
> > under direct user's control.
>
> Recipient's control.  And probably a MUST.
>
> >
> > I think that delete by the MTA would have its own merit.  Many MTAs
> > still hold undelivered messages for days, and rfc5321bis still says
> > that "the give-up time generally needs to be at least 4-5 days."  For
> > various kinds of transient messages, the give-up time could be much
> > shorter.  MTAs don't need to read Expire fields, however, since
> > RFC2852's DELIVERBY addresses exactly that use case.
>
> And DELIVERBY is presumably specified by the sender of the message,
> whereas Expires policy should only be set by the recipient.
>
> It might be good for this draft to explicitly compare Expires to
> DELIVERBY.  And it should specifically forbid intermediate systems (not
> just MTAs but also spam filters) from deleting messages based on Expires.
>
> Keith
>
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux