Subject: Re[2]: sieve: vacation extension

From: "Chris Bartram" <[email-masked]>
Date: Fri, 21 Nov 1997 19:15:26 -0500

In <[email-masked]> [email-masked] writes:

> > Chris Bartram wrote:
> >
> > > It might be reasonable to suggest that no repeat messages get sent as l> o
> ong
> > > as the "vacation" command/action is in effect. If it is changed/deleted>
> -and-
> > > added-back, then a new log is to be created
> >
> > I tend to agree with Chris B. about oneshot vacation notices. At least
> > it allow side-stepping the issues he described. It seem to me that
> > having a vacation notice repeated at some interval is more a function of
> > the original sender's individual memory refresh rate (which may vary
> > from time to time :) than anything else.
> >
> > Is there any strong arguments for having repeated vacation notices?
> >
> > A nice touch would be if the originator's MUA understood the vacation
> > notice good enough to politely make a reminder during the vacation
> > period each time the sender tries to submit another message. I guess
> > it's only a dream of mine...

Not so far off perhaps... If the vacation notices were wrapped in a standard
format (like the MDN/DSNs) then software could potentially handle such
notices automatically. At least, as long as an RFC is being developed for
vacation messages anyway, why not go ahead and dictate that the vacation
messages utilize one of the standardized notification formats??

              -Chris Bartram

---

From: Tomas Fasth <[email-masked]>
Date: Sun, 23 Nov 1997 16:43:16 +0100

> messages utilize one of the standardized notification formats??

I like your idea, let's see where this can lead us...

I can see at least two approaches to handle incoming messages for
vacated users. One is to delay final delivery at the MTA level and
sending an appropriate "delayed" DSN, the other is to complete the final
delivery and and send an appropriate "dispatched" MDN.

In the case of a delayed final delivery the proposed vacation extension
in Sieve is not useful since Sieve is intended to be applied at the
point of final delivery. When the user have activated the vacation state
on the maildrop, messages will not be finally delivered until end of the
vacation period.
What complications can this imply on the MTA level?
For the user to gain access to the queued messages before end of the
vacation period the vacation state have to be cancelled and possibly
reinstated after having the queued messages delivered to the maildrop.

Looking into the use of DSN for vacation notices raises some questions.
Using Action:delayed seem to most appropriate in such an approach. The
most appropriate status code seem to be 4.2.1 as taken from RFC 1893:
  4.X.X   Persistent Transient Failure
  X.2.X   Mailbox Status
  X.2.1   Mailbox disabled, not accepting messages
There seem to be no code for vacation, do we need to define such?

Then we should try to communicate the duration of the vacation period.
Is it sufficient to use the optional "Will-Retry-Until" header?
Or one might want to use the "Diagnostic-Code" with type "vacation"
(certainly not standard yet :) and a text argument containing meta
information about the vacation. There is also the choice of using
extension headers. Comments?

Regarding the alternative approach of completing the final delivery and
emitting an MDN as vacation notice, the following might do the trick:
  Disposition-action-mode = automatic-action
  Disposition-action-mode = MDN-sent-automatically
  Disposition-type = "dispatched"
  Disposition-modifier = "vacation" (or "x-vacation" until registered)
Resulting in a complete disposition field as:
  Disposition: automatic-action/MDN-sent-automatically ;
               dispatched/x-vacation

Comments?
-- 
Tomas Fasth                  mailto:[email-masked]
EuroNetics Operation         telephone:+46-13-218-181
Mjärdevi Science Park        cellular:+46-708-870-957
58330 Linköping, Sweden      facsimile:+46-708-870-258
TwinSpot Network is a subsidiary of EuroNetics Operation