On Jun 28, 2008, at 4:17 AM, Frank Ellermann wrote:
Douglas Otis wrote:
While it will be unusual to have multiple From header email-
addresses, having multiple DKIM signatures will not be. This means
a message may be expected to generate several additional target-
able transactions made by receiving hosts and MUAs who evaluate
DKIM message signing.
Nobody is required to check ADSP for a valid existing signature. If
you want "signature processing limits" put them in 4871bis.
SSP-03, even after changes to satisfy polling, the draft will still
_increase_ the number of signatures that might be needed, and
therefore processed.
When a receiving host's goal is to reject bogus email, ADSP discovery
could be attempted for each From address lacking a valid Author Key
Domain signature. RFC4871 did not place a limit on the number of
invalid signatures allowed, and stipulated that invalid signatures are
not to be removed. The burden of retaining a safe process has been
left to follow-on practice schemes, especially when the scheme
introduces a need for _additional_ signatures and multiple From checks.
A receiving host and/or recipient not happy with ADSP/DKIM results
might then attempt to validate with Sender-ID. Jim has said in public
forums that he considers Sender-ID and DKIM complementary since they
have different failure modes. Such a statement invites the execution
of both. How many additional authentication/authorization
transactions are too many to be safe? When will the number of target-
able transactions become a concern? After all, email is already
heavily abused, and what is being proposed is unlikely to impact the
level of abuse. Bot-net 0wned system locations remain hidden when
DKIM signatures are forced to remain ambiguous about the on-behalf-of
identity.
The signing identity must be that of the author only when a key has a
restrictive local-part template. The restrictive template indicates
that the system is indirectly signing for the domain. Whenever a
restrictive template signature is not on behalf of the author, it
should not be considered valid for the purpose of compliance or
annotation whether or not any ADSP record is discovered. SSP-03
ignores restrictive template signatures when there is no ADSP record.
SSP-03 also fails to recognize a directly signed signature on-behalf-
of a different identity. When directly signed (as denoted by a non-
restrictive local-part template), a signature safely indicates which
identity had been authenticated, even when found nowhere or elsewhere
within the message.
Non-restrictive templates would represent signatures directly applied,
where it can be assumed the message is complaint with the Author Key
Domain policies. Such non-restrictive signatures would be complaint
when the Author Address is from the same domain regardless of ADSP,
but a different domain in the Author Address would need to be have an
OPEN ADSP assertion for full compliance. This would allow a single
signature to be used when an office admin that might be noted in the
Sender header posts a message that purports to be from their boss. As
always, it would behove the signing system to check message compliance
prior to adding their direct signature.
otis-dkim-adsp draft requires one compared to SSP-03 draft's of
three discovery transactions.
SSP-03 does not yet reflect the outcome of two polls reducing *two*
to in essence *one* for existing or "mailable" domains.
True.
John Levine's replacement for this also uses three.
Existing domain + plus practise is two, an optional "mailable" check
can take at most three queries replacing the NXDOMAIN check. That
is at most four queries, and folks can skip AAAA if they judge it as
irrelevant for their purposes.
You're right, but the hope would be that AAAA records, lacking either
A or MX, as an acceptance check could be excluded by fiat. Such an
exclusion would reduce the number of transactions needed and the
number of domains afflicted by additional email transactions.
Eventually, basing acceptance upon finding an MX record would make a
further reduction, but importantly, would protect all domains not
publishing an MX records from the additional email transactions that
all the last ditch efforts such as Sender-ID, and DKIM have added.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html