On Feb 17, 2006, at 5:32 AM, SM wrote:
At 18:11 16-02-2006, Mark Delany wrote:
Not that I know when r= should be used, but, it strikes me that
having an r= specify an address outside of the domain in question
is a potential for DOSing some innocent third-party.
"r=" is used for reports and inquiries regarding the signing policy.
1) With an open-ended policy, 'r=' referenced from the email-address
domain will still create havoc.
2) When the signing policy is closed, the email-address and the
signing-domain are synonymous, but email is broken.
3) Only the signing-domain can effectively respond to abuse reports.
4) 'r=' should only be referenced from the signing-domain.
Some implementations of DKIM send out an automated message to
notify the signer of verification failures.
Should these reports go to the email-address domain owner or to the
signing-domain? Who can fix the problem?
The "r=" tag can easily be misused.
Agreed. If there are to be reports allowed, these should be reports
to the entity able to take corrective action, the signing-domain.
So, should r= only specify a localpart and the domain is implied
by the domain being queried, or if r= specifies a complete
address, should the domain be constrained to be in the policy
query domain or below?
The "r=" tag should be restricted to email addresses within the SSP
domain being queried. The host part of the email address should be
constrained to be within the SSP domain. You can then use email
addresses such as abuse(_at_)example(_dot_)com or abuse(_at_)reporting(_dot_)example(_dot_)com(_dot_)
A restriction limiting reports to the email domain will not prevent
abuse. Do not assume closed policies are in place. Do not use this
reporting mechanism as a method to punish email-address domain owners
not publishing closed policies. When the only logical choice for
open-policies is to not use 'r=' email-address vector, how does one
still allow a means to report abuse to the signing-domain?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html