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
