Propose:
Expiration Timestamp Format:
x=date.time
where
The date is 8 digits in the format YYYYMMDD, where YYYY is the
four digits of the year, MM is the two digits of the month (with
leading zero, if appropriate), and DD is the day of the month (with
leading zero, if appropriate).
The time is 6 digits in the format HHMMSS with HH being hours on
the 24-hour clock, MM minutes 00-59, and SS seconds 00-59.
The timestamp MUST be in GMT timezone.
Support Logic (and feed for semantics author)
The expiration timestamp is compared against the smaller time
between the verifier current time and the network recorded
transaction reception time (TRT) representing the time
the transaction was received at the [MX] host system.
This Transaction Reception Time (TRT) MAY be equal to the
current time depending at the location of the verifier. It
MAY be extracted from the topmost 2822.Received: timestamp.
NOTE: We need to be careful calling this "Received
Time" since that can be confused with the time the
user has received and thus marked as read in the
message storage.
Informative notes:
We have the following TRT times:
T1 - Time the MTA transferred and MDA received the
DATA block transaction (2822.Received)
Per RFC x821, all SMTP receivers are required
to open a temporary transfer storage with the
initial two Headers:
Return Path: <2821.MailFrom>
Received: .......; time-stamp
The time-stamp will be the current time the
SMTP receiver reads from the computer system.
T2 - Time of the Verifier is activated.
Here we have three possible times:
T2.1 -- DATA level verifier which will probably
just use the current time.
T2.2 -- Post SMTP level verifier within the
server domain such as a MFA (Mail
Filtering Agent) where Sieve, Spam-Assassin
and other proprietary filter/scripting
processes might be active.
T2.3 -- MUA level verifier. The presumption is
that the MUA will activate a DKIM
verification once it picks up the
mail. In order to be consistent and
to minimum false expirations, the time
should be compared against the backend
reception time (2822.Received).
In summary,
TRT = minimum(T1, T2.1, T2.2, T2.3)
In practice,
T1 <= T2.1 Verifier MAY use current time.
T2.1 < T2.2 Verifier SHOULD use 2822.Received: time.
T2.2 << T2.3 Verifier SHOULD use 2822.Received: time.
In short people, as one of many implementators, I have no interest in
creating expiration false positives.
The time of interest is when our system received the message. Depending on
where we add our verifier, the TRT could be the current time or the
2822.Received: timestamp.
If we add our verifier at the DATA state (T2.1), these two times will
basically be the same as we will mostly grab the current time at the moment
the verifier starts.
However if we design our system to place the verifier further away from the
SMTP transaction, again, as a implementator, it would be prudent to use the
time that would produce less false positives.
That time would be the 2822.Received: timestamp.
But then again, it all depends on how fast the post-smtp verifier processes
the new messages. The larger the system is, the higher the verification
will delays. So again, designers will most likely use a TRT extracted from
the 2822.Received line which by the way, will ALWAYS be the first received
line at the top of the file.
If our verifier was added to our MUA, we have no logical reason to use the
MUA current pickup time. This would be a no brainer to use the
2822.Received: time.
Overall, I think that we are not given the implementator the benefit of the
doubt here. The Transaction Reception time is the most logical time to use
for expiration comparison. As with most dynamic operations, if the verifier
is a hook into SMTP, the current time might be use with little to no false
positives. But as further away it is, we have no choice but to use the
2822.Received: time.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html