Subject: [ietf-dkim] x= date format and support logic

From: "Hector Santos" <[email-masked]>
Date: Fri, 21 Apr 2006 02:16:14 -0400

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