[ietf-dkim] DKIM verification actors
hsantos at santronics.com
Mon Apr 24 10:02:11 PDT 2006
----- Original Message -----
From: "Douglas Otis" <dotis at mail-abuse.org>
To: "Hector Santos" <hsantos at santronics.com>
Cc: "DKIM Mailing List" <ietf-dkim at mipassoc.org>
Sent: Monday, April 24, 2006 12:33 PM
Subject: Re: [ietf-dkim] DKIM verification actors
>> SMTP is now and still going to be primary method of transport, and
>> even if there other non-SMTP transport methods, new or old, the
>> vendors are still going to include SMTP.
> Protections afforded by DKIM include transports beyond SMTP that
> extend from the originator to the recipient, as noted in the charter,
> threat, and base draft. While delivery failure retry within for SMTP
> is a component of a key retention requirement, a greater period of
> retention may be necessary to accommodate other transit latencies.
I label these practical delays as:
t1 - Transit (MTA -> MDA)
t2 - Processing (MDA/MFA processing)
t3 - Pickup (MUA pickup from backend msg database)
t1 is well defined for over 20+ years.
t2 depends on the big the receiver site is. Scalarability and message
queuing places a tremendous factor on how dynamic operations are
implemented. I will venture this t2 delay is less than 1 day and approaches
zero the smaller the site is:
size of receiver system ------>
0 < t2 < 1 day (SWAG)
The only true variable is t3, which is the time that the mail was already
received and processed by the system, possibly transformed, posted for user
pick and the MUA finally picks it up and/or Logins into the host and reads
the mail on line.
I agree with you, t3, is an important consideration IFF there is no design
consideation at the backend. How big that consideration is directly
proportional and largely dependent on a site's user base ergonomics and
behavior with mail pickup and/or login frequencies. In my view, if you are
writing a DKIM-ready MUA, you have no choice but to make sure it also
supports a non-DKIM-aware backend.
> There is no certainty where in the transport sequence a message is
> signed by the originator, or where in the sequence verification of
> the signature is important to the recipient. Short key retention
> will not offer protection for common circumstances involving the
> transit from the originator to the recipient.
So if a domain realizes this, why would they use a short retention time?
> SMTP delivery failure retry is not the only circumstance that
> warrants consideration for key retention.
It is the only absolute minimum we have based on SMTP standards, BCP and
legacy operations. Why would a Key Management software writer ignore this
obvious 4-5 day (t1) transit delay?
> Is there a reason why key retention should not consider latencies
> related to originators and recipients over other transports?
No, which why I think this seems to be a mountain out a mole hill issue. If
a domain sees a problem with its signatures, then only he can decide how
long the key retention issue and if a ISP/ESP sees complains from the user,
there is not much he can do but to tell them:
- Not our problem. We are not DKIM aware.
- Check in more often.
- Talk to your MUA vendor.
You are not going to cover ALL belated t3 period (MUA) situations unless
there are specific DKIM helper technology that specifically addresses this
issue. But this also requires DKIM-awareness intelligence on the backend.
Here is a possible DKIM "Helper" solution I call:
"Partial DKIM Verifier Support using a
DKIM-Received Trace Header"
This is a possible solution that will help this particular issue and also
offer a migration path for DKIM implementation wishing to get started.
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim