But since Expiry-Date is a MIXER field, I should probably go dig out my
X.400 docs and check the X.400 definition to see if what we want is
compatible with how they defined things way back when.
I'll save you the trouble. The formal definition of the expiry-time field
in X.411 is:
7.2.11 Expiry Time
The Expiry Time heading field (O) identifies when the authorizing users
consider the IPM to lose its validity. It comprises a date and time.
ExpiryTimeField ::= Time
This is from the 1999 version but I doubt it's materiallly different in earlier
or later revisions.
It should be noted that this is part of X.411, in the part that defines the
format for IPMs (interpersonal messages). The placement of the field
corresponds to that of a RFC 822 header, but in X.400 the separation between
header information (an end to end thing) and the envelope (in X.400, a wrappper
around the entire messae) is actually stronger than in Internet mail. (This
does not mean that actual implementations treat it this way, as we'll see
below.)
So those are the stated semantics of the field. I'd say they are fairly close
to what we've been discussing, although the use of the term "valid" is quite a
bit harsher than "relevant". However, this doesn't give much if any insight
into how X.400 implementations actually handled the field operationally. For
that there are three things to look at: (1) Related stuff in the X.400 series
documents, (2) The X.400 operational profiles, and (3) Actual implementations.
Prowling around in the various documents, there are error codes corresponding
to "expired message" in both the NDN and IPN formats. (It is unclear to me,
however, when the NDN codes are supposed to be used.) NDNs, or nondelivery
notifications, correspond pretty closelly to DSNs. NRNs, or nonrecipient
notifications, are similar to MDNs, but in this case the differences are pretty
substantial. (You cannot effectively gateway an NRN into an MDN, for example.)
So here's a section of the text defining the NRN format:
8.2.2 Discard Reason
The Discard Reason non-receipt field (C) indicates why the subject IPM was
discarded (subsequent to its delivery to
the NRN's originator and prior to its receipt).
[ ITU-T version:
DiscardReasonField ::= ENUMERATED {
ipm-expired (0),
ipm-obsoleted (1),
user-subscription-terminated (2),
not-used (3) }
| ISO/IEC version:
DiscardReasonField ::= ENUMERATED {
ipm-expired (0),
ipm-obsoleted (1),
user-subscription-terminated (2),
-- The following value may not be supported by
-- implementations of earlier versions of this Specification
ipm-deleted (3),
... }
]
This field may assume any one of the following values:
a) ipm-expired: Auto-discard was in effect, expired IPMs were being discarded,
and the time identified by the subject IPM's Expiry Time heading field had
arrived.
b) ipm-obsoleted: Auto-discard was in effect, obsolete IPMs were being
discarded, and the Obsoleted IPMs heading field of another IPM, delivered
to the NRN's originator, identified the subject IPM.
c) user-subscription-terminated: The Interpersonal Messaging subscription of
the NRN's originator was terminated.
[ ITU-T version:
d) not-used: Implementations shall not generate this value. However, since
thisvalue is used by implementations conforming to ITU-T Recs. of the
X.400-series | ISO/IEC 10021 to indicate ipm-deleted, messages may be
encountered that contain this value.
| ISO/IEC version:
d) ipm-deleted: The subject IPM was deleted before receipt occurred. Where a
message store is involved, deletion occurred before the IPM's status became
processed.
]
So an IPMS (that's InterPersonal Message Store, what we call a Message Store or
just a Store)) does in fact have the capability to throw out an expired
message, and this is controlled by the auto-discard setting. Confirming, here's
the auto-discard description:
12.3.1 Change Auto-discard
The Change Auto-discard abstract operation enables or disables auto-discard,
the automatic discard by the IPMS of expired or obsolete IPMs delivered to,
but not yet received by the user.
change-auto-discard ABSTRACT-OPERATION ::= {
ARGUMENT SET {
auto-discard-expired-IPMs [0] BOOLEAN,
auto-discard-obsolete-IPMs [1] BOOLEAN} }
When it auto-discards an IPM, the IPMS originates an NRN on the user's behalf
if, and only if, one was requested of him by means of the
Notification-requests component of the subject recipient specifier.
This abstract operation has the following arguments:
a) Auto-discard-expired-IPMs (M): Whether or not expired IPMs are to be
auto-discarded. A Boolean.
b) Auto-discard-obsolete-IPMs (M): Whether or not obsolete IPMs are to be
auto-discarded. A Boolean.
In other words, each user can control whether or not auto-discard is in effect
for their mail. And if the auto-discard-expired bit in that setting is on then
expired messages are deleted and, if a receipt notification was requested, an
indication of that outcome is returned to the message originator.
This probably sounds pretty good at this point. But let's move on to the
second point: Operational profiles.
As you can probably tell from this example, the X.400 series specifications
nail syntax details down quite tightly. Operational behavior, howefver, is left
pretty open, with a lot of it depending on how implementors read between the
lines. This was considered unacceptable back in the day so various
organizations like, say, the US Government, developed operational profiles.
I used to have a copy of GOSIP, the profile done by the US Government, on
paper, but somwwhere along the line half of it got lost (half meaning a whole
3" ring binder stuffed to overflowing - yes, GOSIP is easily a full 6" stack of
paper). So I'm afraid I cannot look up how this is supposred to actually be
implemented. What I can say is that implenentation requirements could easily
vary a lot from one place to the next.
In terms of actual implementations, let me start by saying what ours does: We
map Expiry-date: to and from expiry-time. We provided no support for per-user
auto-discard settings. What we did provide was a configuration option check
expiry dates on in-transit messages and bounce them if the message has expired.
This setting is off by default.
This pretty clearly takes some liberties with how this is defined in X.400.
Why? Because in X.400 both final delivery and message receipt are well defined
events. In Internet email only final delivery is nailed down to a similar
extent. There is no "message has been received" event you can talk about with
any certainty in Internet mail. Accordingly, since the way we supported X.400
was to gateway it to the Internet world (the alternative of running two
separate stacks was deemed unacceptable), various things associated with
receipt ended up getting tacked on to final delivery. Including message
expiration.
So what about per-user control of auto-discard? It turns out these are part of
P7 (the X.400 equivalent of IMAP plus a little ACAP and some other stuff, kinda
sorta) and we never supported that. (P7 is optional and very few clients able
to use it were ever developed.) So this whole auto-discard mechanism was never
an issue for us. But not delivering expired messages was a requirement someone
had, so we implemented an option do it.
So what does all this mean? It means that if you gateway to a pure X.400
environment that rigorously follows all the rules and uses P7 to talk to MUAs
you end up with more or less the operational behavior Keith wants, although the
defaults may be to auto-discard. (I didn't find a default in the standard
itself, which means it's probably operational-profile-specific.) however, if
you're dealing with a real-world implementation that doesn't use P7 or worse,
operates with an Internet rather than X.400 kant, you're not going to have
per-user controls for this and you're likely to see such messages discarded
automatically with no recourse.
I will also note that while we don't support X.400 any more, since the
expiry-date check was implemented at the MTA level it is actually something we
still support doing. Of course I have no idea if anybody actually have the
feature enabled any more - I suspect not but there's no way to be sure.
Ned