ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM verification actors

2006-04-24 10:12:37

----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "DKIM Mailing List" <ietf-dkim(_at_)mipassoc(_dot_)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"

http://isdg.net/public/ietf/drafts/draft-santos-dkim-rcvd-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-rcvd-00.html

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.
http://www.santronics.com


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