One could view DKIM as a mechanism that establishes an accountable
domain for the messages contained within the email message transport
system. By limiting the scope of DKIM to being a mechanism that
provides an accountable domain for the transport system, a great deal
of benefit can be derived without threatening the integrity of the
transport system. As such, policies that are established by various
methods MUST BE with respect to the email message transport system,
and NEVER a specific header unrelated to the email message transport
system, see RFC2822.
Justifications for Anti-Phishing policies:
----
Special policies for email-address constraints may be established as
a response to domains that have become "phishing" targets.
Nevertheless, these policies should be considered outside the scope
of DKIM. In such "phishing" messages, links are often included that
take the recipient to fraudulent websites. An urgent response to
this situation is not addressed by a complex scheme that requires
parsing of several text and binary DNS records, and where a sequence
of additional DNS records may also be required in attempts to
mitigate problems created for the general case.
In addition, an immediate response to the "phishing" threat would
include far more restrictions than just for the RFC2822 From header.
These constraints should include all headers, and email parameters.
These restrictions should also limit links that may appear in such
messages. Rather than complex SSP records, a more expedient solution
would be a simple DNS lookup of the domain, where when any record is
returned, the exigent "anti-phishing" restrictions then apply. This
could be done at each domain or as an industry provided service. The
fastest to implement and lowest cost solution may simply require
verification of the EHLO for such domains, rather than a DKIM signature.
SSP as defined does not adequately address "phishing", nor would any
mechanism that applies even moderate protective email-address
constraints. No such constraint would be suitable for general use.
Such an email-address header constraint mechanism should be
considered outside the scope of the DKIM effort.
----
Identifying the message originator or author:
----
The goals of OpenPGP and S/MIME were aimed at providing a mechanism
to identify the author or originator of the message and to ensure
elements that verify the author are apparent to the recipient. This
is not trivial.
Polices related to DKIM should not attempt to identify the author or
originator, but instead limit the verification to that of the message
signature deemed related to the email message transport system. No
reasonable policy can ensure that elements used verifying the
signature are apparent to the recipient with today's MUAs.
Constrictions that some email-address MUST BE within the same domain
as the signing-domain WILL cause a significant portion of the email
traffic to be refused or deleted.
[I-D.allman-dkim-ssp-01]:
2.9 Verifier Acceptable Third Party Signature
,---
| Verifiers SHOULD NOT accept signatures from identities that
| have no known relationship with the message other than their
| appearance in the "DKIM-Signature" header.
'---
Such a constraint makes it impractical for a large portion of the
current email traffic to be signed. Efforts aimed at forcing a
binding to a specific header deemed related to the originator or
author should be viewed as seriously damaging the integrity of the
email transport system. Such attempts also poorly replicate and
overlap the efforts of OpenPGP and S/MIME.
Lessons from MARID:
SSP as currently defined resembles failed efforts pursued in MARID.
SSP is no less disruptive and is equally flawed. It would also seem
the failure to consider a response to DoS or Message Replay abuse is
related to expectations that path-registration will be mandated as a
solution, as suggested by Jim.
Signing policy related to any email-address MUST consider existing
RFC2822 conventions which indicate the header related to the entity
that introduced the message. In general, no policies related to a
specific header is needed. The intelligent handling of messages can
be greatly benefited by an accountable domain established for the
email message transport system. Establishing a name-basis for email
acceptance should improve the likelihood that DSN messages are sent,
and that messages are accepted.
Policies aimed at constraining what email-addresses can appear within
various headers unrelated to the entity that introduced the message
into the email transport system will seriously degrade the integrity
of the system.
----
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org