[dkim-dev] [ietf-dkim] Authorizing List Domains
dotis at mail-abuse.org
Tue Sep 28 19:01:11 PDT 2010
On 9/28/10 3:27 PM, Murray S. Kucherawy wrote:
> >> On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:
> > TPA-Label involves ADSP being discussed on the dkim list.
> Unless you're talking about revising ADSP (which it seems you are
> specifically not doing since TPA is meant to cover other
> technologies as well; plus, ADSP wasn't in your list), we're talking
> about something new that is not in the current DKIM WG Charter.
The TPA-Label draft offers additional ADSP assertions having semantics
intended to support _existing_ mailing-list and third-party practices.
The DKIM charter states the following:
Consider issues related to mailing lists, beyond what is
already documented. ...
> > Some have expressed strong desires to improve DKIM deliverability
> > by allowing fallback to other adopted verification methods.
> > TPA-Label permits such fallback without also requiring the same
> > domain be used by alternative methods.
> The first sentence there seems contradictory to me; if you're
> falling back to other methods, we're no longer talking about mere
> DKIM deliverability.
Sorry, should have said DKIM/ADSP deliverability, which is based upon
DKIM Author Domain Signatures. The TPA-Label draft offers alternative
ADSP assertions that indicate the possible availability of domain
specific exceptions. When exceptions are not found, non-compliant
messages are to be rejected, as opposed to being discarded or scored in
> > DKIM is unable to unilaterally authorize third-party services which
> > impedes use of restrictive acceptance criteria.
> DKIM specifically allows a domain to give a third party signing
> authority by putting into the DNS a public key matching a private
> key that is in possession of that authorized third party. Unless
> there's an assertion being made that this mechanism creates a
> hardship, I'm still not clear why that's been dismissed as a
Utilizing a discussion list and mitigating domain spoofing is not
possible with existing ADSP assertions. Nor is publishing public keys
for all such discussion lists either a practical or a wise solution.
Inclusion of List-ID or Sender header fields as an ADSP compliance
requirement places less reliance upon only the From header fields in the
recognition of message sources whenever authorizing third-party services.
> >> Since any client can say anything it wants for an EHLO
> >> parameter, why should it be considered a type of authentication?
> > The SMTP client identified by the EHLO might resolve the IP address
> > used in the exchange. While such resolution is not required by
> > SMTP protocol, it might offer an opportunistic means to
> > authenticate the administering domain as a fallback method.
> The DNSOP working group has repeatedly advised against use of
> reverse DNS as a mechanism for client authentication. Do we claim to
> have expertise they are lacking?
The SMTP EHLO or HELO hostname must resolve the IP address of the SMTP
client. Reverse DNS is not used.
> For that matter, one could invent a scheme that mandates any piece
> of data must match any other piece of data, both of which are
> potentially (perhaps even often) under the control of a miscreant.
> I'm not sure I see how this is useful.
Requiring additional header field compliance better ensures different
mail streams remain recognizable by recipients. Many MUAs already
display Sender, and many who subscribe to mailing-lists already sort
using List-IDs. Whether or not recipients see the required header
field, their requirement helps isolate authorizations to specific mail
streams, such as messages emitted by the authorized domain's
mailing-list services. The TPA-Label response includes authentication
requirements intended to exclude miscreants. The general premise is
exceptional authorization is only given to trustworthy services.
> Moreover, identification of a client as legitimate or otherwise
> based on HELO/EHLO data has proven problematic if only because of
> common configuration errors. Enforcing something along these lines
> will likely create more operational problems than it solves.
There is no assured authentication method specified by SMTP. This
leaves a range of options that might be employed by third-party
services, such as mailing-lists. However, ADSP's convention of only
binding Author Domain DKIM signatures with the From header field
disrupts these services whenever restrictive assertions are made. A
goal of the TPA-Label draft is to leverage the strongest authorization
method available. The strongest confirmed authentication method
indicated within the TPA-Label for the domain in question reduces the
receiver's discovery efforts.
> > These header fields must match against TPA-Label specified
> > domains. The contained domains ensure the effectiveness of message
> > sorting or header display in allowing recipients a means to
> > differentiate email sources that might also contain the From header
> > used by ADSP. The source of these header fields must also
> > correspond with specified domain and authentication/verification
> > methods.
> ADSP makes a binding between the "d=" and the domain in the From:
> field, the most visible of them all, and we've seen extremely narrow
> use of this, much less success. I have doubts that expanding that
> logic to other less common or less visible fields will see more
> adoption or success.
Few are willing to allow a few percent of their mail stream to be
discarded just to mitigate domain spoofing. Those who have taken the
extreme measure of asserting ADSP "discardable" did so after realizing a
significant reduction in return business whenever recipients are not
adequately protected against spoofing. By asserting "discardable",
their domain is no longer able to exchange messages with most
mailing-lists. Use of sub-domains or cousin domains is likely to create
confusion and similar negative reactions driving away business when
mailboxes become flooded with messages containing their new unrestricted
The goal of the TPA-Label draft is to allow consolidation on to a well
protected email domain, where issues of unintended rejection or
discarding are avoided. While this requires additional effort by the
sender, the data needed to publish necessary exceptions is already
available and can be used to populate a _tpa zone. :^)
> I think if you're going to say a particular domain is authorized to
> sign your mail and verifiers should consider such mail "good", then
> you've already granted that domain the ability to pass your policies
> through at least one vector. Constraining that domain to pass your
> policies only one particular way doesn't gain you anything: Either
> the domain is not compromised in which case everything's fine
> anyway, or it does get compromised in which case the intruder can
> simply generate malicious mail within the constraints of your policy,
> and you're burned regardless of what policy you post.
While many mailing-lists adequately exclude abusive subscribers, and
properly confirm subscriptions, most simply redistribute messages as
received, flattened, annotated, with header fields added. Annotations
within the Subject line and message body, along with inclusion of
specific header fields can be leveraged to discourage exploitation of
authorized third-party services. This should offer far superior results
over that obtained using SPF -all or ADSP discardable. The TPA-Label
mechanism also offers a method to recover from damaged signatures
whenever a path related authentication remains available and offers
More information about the dkim-dev