----- Original Message -----
From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>
At 2:08 PM -0400 4/21/06, Hector Santos wrote:
Any MUA DKIM-Ready software using the current time is going to quickly
slammed and classified as buggy, broken software.
You are free to do such slamming. Others won't.
Actually its not my style, but you darn know well who would be the first to
use, non-stop, cliches such as "Fix your Software".
I'm pretty confidence it won't get to that point though. Authors will
clearly see the issue once they run into their first false positive.
From the Jabber session yesterday:
Resolution: Suggest using received time "if reliably available", else
current time. Arvel and Jim aren't sure, but accept it if it's "MAY".
Stephen will propose text.
Seems pretty clear to me...
What is clear Paul? MAY is your path of the least resistance? You know, I
am not convince you understand this issue in its entirety, atleast I don't
see you do.
Anyway, the goal was accomplished. The current time only semantics was
functionally and technically incorrect and that was changed to allow a more
reliable time that would benefits all verifiers. Job was done.
Proof:
If the current time presumed to be correct at point 1, it
would therefore be fundamentally incorrect to use a newer
current time at point 2 and expect to always get the same
result in a time comparison logic.
Paul,
The current time is fine for instant dynamic, on the spot, verification
concepts, AKA hooks, plugins, shims, callouts, whatever you prefer to call
it. By dynamic, it means the moment you get the transaction from the
outside world.
But once you move away from instant dynamics concepts, there is only one
current RFC 2821 SMTP standard to pass the near current time/reception time
with an exact non-ambiguous ABNF Received: header.
From RFC 2821:
4.4 Trace Information
...
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
Unless you wish to propose a new 2822 header to pass a easy to parse
timestamp, which seems to me to only objective, it seems pretty clear to me
the logical timestamp to use is the network trace reception header. For
SMTP, that's the
Received header:
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html