----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
That basically means that x= must be used if there is a planned event
for selector removal within 7 days.
When the transport includes IMAP and POP, this 7 day advice is far
too short of a period to ensure verification.
Agreed. This SWAG must be from the recommended SMTP retry limits:
| RFC 2821:
| 4.5.4.1 Sending Strategy
|
| ...
|
| Retries continue until the message is transmitted or the sender gives
| up; the give-up time generally needs to be at least 4-5 days. The
| parameters to the retry algorithm MUST be configurable.
But for the time-shifted application, if the message reception time
(Received: header) is used, then it shouldn't matter.
Just consider that in a offline MUA like Outlook, where it shows two
possible dates in its message list, the dates are from:
Sent: Column <-- Date: Header
Received: Column <-- Topmost Received: Header (ISP MDA timestamp)
The MUA (today) only understands these two dates. Why would it want to use
the current time for a DKIM plug-in? That doesn't make sense. You want
to emulate the idea of real time reception so you would use the MDA
reception time. Not the pick up time.
---
Hector
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html