On Oct 18, 2005, at 4:53 PM, Arvel Hathcock wrote:
This behavior raises a security problem since such
senders will go with policies that lean towards
delivery versus potential security threats.
Use of o=- or o=~ is a matter for DKIM signers to decide; it is not
a matter for the specification documents to decide. This is my
view on this topic.
The significant header for the SSP email-address is not compliant
with RFC-2822. When the From/Sender headers do not represent the
actual sender, such messages may be forfeit had the domain contained
within the From/Sender published close-ended authorizations. SSP
policies reduce delivery integrity for other senders! : (
This loss of integrity is in the guise of protecting a visible email-
address. However, the introduction of third-party signers to
accommodate normal provider/domain-owner relationships prevents
claims an email-address is protected. In the exigent case where it is
important to protect visible headers, there is one assertions that
assures protection and makes the domain highly restricted to two-
party use, but still suitable for sensitive transactions.
- All originating headers match the signing-domain!
A responding message to such enterprises making this assertion would
be able to make exceptions for their own email-address when they are
the recipient.
There have been suggestions third-party signing-domain authorization
lists could be a remedy. This expensive third-party authorization
listing places the email-address at greater risk. Nothing within the
DKIM mechanism assures the email-address is protected by the signing-
domain, unless the signing-domain and the email-address domains are
the same. A third-party authorization list reduces emphasis on the
signing-domain and may allow the assumption the reputation is to be
unfairly accrued by the email-address.
Verifying the EHLO-domain or making assertions compliant with
RFC-2822 are low impact methods to assure DKIM has been adopted
without reducing the integrity of email delivery. All of this open-
ended/close-ended authorization would then be meaningless.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org