[ietf-dkim] Authorizing List Domains
dotis at mail-abuse.org
Tue Sep 28 15:02:16 PDT 2010
On 9/27/10 9:47 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.
> > Agreed, but not having a defense against trivial exploitation of
> > an authorization is not better. When a defensive requirement
> > proves unused, it can be removed without impact. Since this
> > information sets authorization requirements, adding the information
> > at a later date would not be compatible with existing
> > implementations.
> That seems antithetical to the idea that this is all experimental
> work, explicitly not on the standards track.
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
> > Perhaps we can work on the bare essentials independent of the
> > notation used.
> > Types of authentication that might be used for existing
> > third-party services-
> > 1) DKIM 2) TLS 3) SPF 4) EHLO/ADR
> I wasn't aware we were scoping something intended to be universally
> used. My focus has been strictly on DKIM. Other than TLS, we're not
> talking about particularly strong authentication systems here so I'm
> not sure we should spend the cycles to be that accommodating.
> However, as I said before, decoupling ATPS from ADSP is a trivial
> matter if that turns out to be the right way to go.
DKIM is unable to unilaterally authorize third-party services which
impedes use of restrictive acceptance criteria. With few exceptions,
DKIM/ADSP "discardable" disrupts normal email use, and ADSP/SPF "all" is
ineffective at blocking spoofed domains. TPA-Label can remedy
inappropriate message rejection or acceptance while also avoiding
You seem to agree TLS could be included as a compliance option in
conjunction with restrictive acceptance assertions. TPA-Label offers a
fallback to other authentication/verification methods for graceful DKIM
While SPF does not authenticate a source domain, SPF "-all" currently
represents the predominate restrictive acceptance assertion aimed at
mitigating loss of email credibility caused by domain spoofing. The
TPA-Label scheme offers fallback options that don't wait for universal
DKIM adoption to improve legitimate domain acceptance and spoofed domain
Perhaps TLS will be adopted as a means for IPv6 email acceptance based
upon a domain, and might even become a governmental requirement. After
all, restrictive assertions requiring Author Domain DKIM signatures
accompany the From header field is disruptive for most third-party
services, when compared with restrictive SPF assertions. In addition,
DKIM signatures will not be as good at protecting domain reputations
when compared with the use of TLS.
> 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.
> > Additional header field requirements ensure message sorting or
> > presentation. The header field requirement is to offer simple
> > tactics against most phishing exploits:
> > a) Sender b) List-ID
> Why would one base any kind of security mechanism on a trivially
> spoofed header field?
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
> > The most visible name to recipients is the domain found in the From
> > header, whether used as a basis for sorting, or when displayed in
> > addition to that of the friendly name.
> Then why create semantics around other fields?
The From header field is not strictly bound to specific email sources,
especially for third-party services. In reviewing the number of such
sources involved, a dedicated effort at constructing comprehensive _tpa
zones can fully encompass all legitimate sources and avoid most of the
issues related with SPF and ADSP discardable/all. Ensuring inclusion of
Sender or List-ID header fields helps isolate third-party service mail
streams and provides recipients a means to differentiate direct and
More information about the ietf-dkim