Re: Expiry-date header from RFC 1327

[Matti Aarnio <mea@nic.funet.fi>]

On Thu, Sep 25, 2003 at 09:39:10AM +0200, Bartek Krajnik wrote:
> In general RFC 1327 describes mapping between X.400(1988) / ISO 10021.
> But I found there something about "Expiry-date" header:
> 
> Expiry Date Indication
>       Supported as new RFC 822 header (Expiry-Date:).  In general,
>       no automatic action can be expected.

And RFC 2156 a.k.a. MIXER (Mime Internet X.400 Enhanced Relay)
obsoletes that header, and replaces it with a new one... (sigh)

   IPMS.Heading.expiry-time
      Mapped to the extended RFC 822 field "Expires:".  The replaces the
      RFC 1327 field "Expiry-Date:".   Reverse mapping of the RFC 1327
      field may be supported.

> I need to generate header with this feature (no problem).
> Problem is only with MTA - it doesn't expire such a message.
> Do Zmailer has some mechanism to serve so something?
> 
> "expiry" and "expiry2" in scheduler.conf don't give me enouth flexibility.

Historically there have been serious problems in the "Date" type data
parsers -- users can produce any bad thing they want.. (Usually "divide
by zero" kind...)

My first iteration would be:
  - At the router:
    - Recognize the header, and parse its value
    - Output a meta-header with e.g. UNIX time_t value as integer
      in it to the transport specification file.
  - At the scheduler:
    - Pick the meta-header value, and use that data somehow to
      mark message expiration (apoptosis) time.
    - The value can't be in the past (minimum value is set to
      be e.g.  now + 60 seconds)
    - The value won't affect "expiry2" apoptosis timer, e.g. which
      can in the end kick before expiration timestamp.

> Regards,
>     Bartek.
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi