ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Notes from DKIM jabber meeting on 20 April 2006

2006-04-21 10:23:37

----- Original Message -----
From: "Sandy Wills" <sandy(_at_)WEIJax(_dot_)com>


Hector Santos wrote:

Right.  Defining the timestamp is important.  I believe it should be
generically described as the transaction reception time - the time
it arrived at the host system, not the time it was actually verified
or received by the user.

    Exactly what I'm trying to say.  The discussion seems to have
condensed around deciding which "reception time" is relevant, which, to
me, misses the whole purpose of the task at hand.  Who cares, in
sender-authentication terms, when the email is received, tossed, read,
or replied to?  What is relevant, is when the post was _sent_, and
whether or not _that_ timestamp is before or after the expiration
timestamp.

    Or am I missing the whole point?

Sent implies receive.

So overall, the debate is the design for where and who is going to validate
the message and knowing where tells you when.

    MUA1 --> MSA/MTA ---> MDA --> MFA ---> MUA2

User MUA1 sends mail this his ISP (MSA), and the ISP's router (MTA) sends it
to the recipient's host at MDA who receives it. The AVS checker at MFA
passes it and saves its for MUA2 to pick or read.

Where is the DKIM signer?  Where is the DKIM verifier?

DKIM is being modeled mostly for a MDA verification concept, but it could
also work at the MFA and/or MUA2.

You have three different times:

     MDA -  Transaction received at current time T1
     MFA -  Message Accepted, Queued and analyzed at current time T2
     MUA -  Message saved and picked up at current time T3

What's common between them is the timestamp in the required 2822.Received:
header added at the MDA.  All MDAs must add this.

This timestamp would be the current time T1.  T2 would be greater, and T3
will be greater.  So using T2 and T3 increases the potential false positive
expirations.

To make it work right, with lower false positives, the MFA and MUA should be
using the 2822.Received: timestamp.

I don't see it as a big deal, but some indicated that they might be trouble
reading or parsing the timestamp from the 2822.Received.

---
Hector


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html