On Sep 20, 2006, at 4:23 PM, Tim Draegen wrote:

  - My largest customers will not deploy DKIM verification if it
    requires making a DNS query (or two) for every single non-signed
email that they receive. Even if it makes no real-world difference,
    some people just won't do it.

You might add non-cached DNS queries.


1.  Intro

  - "In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822], the verifier of a message MUST determine whether
    messages from that sender are expected to be signed, and what
    signatures are acceptable."

    MUST -->  MAY.  In reality, my customers won't do this for every
    email they receive.  They'll want to control this behavior, for
    whatever reason.

Agreed.

- "Without such a mechanism ... unsigned messages will always need to
    be considered to be potentially legitimate."

    I believe there is quite a bit of existing technology in place to
    determine what is legitimate, regardless of signed status.  :->
    SSP as-a-way-to determine the validity of unsigned email seems a
    bit misguided.

Agreed.

This effort is also possibly pointless when look-alike attacks are considered.

- "Expressions of signing practice which require outside auditing are
    out of scope for this specification because they fall under the
    purview of reputation and accreditation."

    SSP makes no sense to me unless I view it through a 'reputation'
    lense.  Without going out of scope, I'm hoping SSP describes how
    either a DKIM-verifier or a reputation-agent can determine a
    domain's signing policy.

Agreed.

Here reputation must be viewed as something not defined in a classic sense of avoiding spam, but rather what might be considered "trustworthy" from the basis of transactional messages. The important aspect needed for discerning what is "trustworthy" might be partially covered by section 4.5. In other words, one MUST NOT assume an entire domain is "trustworthy" and this is where policy can help.

-Doug




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

Reply via email to