On 10/4/11 1:39 PM, Scott Kitterman wrote:
On Tuesday, October 04, 2011 01:02:13 PM Murray S. Kucherawy wrote:
With the changes you and John proposed to the document in WGLC, the
requirement to report DKIM and SPF results even if you don't check them is
gone, and furthermore you don't have to include the other fields that are
irrelevant to what you did check. It seems to me that leaves us in an
agnostic place with respect to which message authentication methods you're
choosing to execute and report, which satisfies what you and John were
after while also enabling one to report a "sender-id" result.
What am I missing with this thinking?
I'm not understanding who plans to use sender-id and why add that and not all
the other auth-results?
Wd do need to define what to do with results for auth-methods one doesn't
implement or understand (ignore them). I don't want to force implementers to
deal with having to write code for methods they aren't interested in.
It's been 5 years since I took a serious look at the Sender ID specs. I do
not know how well the SPF modifier proposed in a Sender ID record. There are
some subtle differences between the two record types and someone who was
interested enough in Sender ID to investigate it should take a look before we
move forward on it.
First, the term authentication does not describe what can be deduced
from the application of either DKIM or SPF.
DKIM verifies a domain signed a portion of a message. DKIM verification
does not confirm the domain submitted the message to the unsolicited
recipient, the common reason for issuing feedback.
Some view SPF as a method for domains to authorize the return path to
ensure DSNs.
Some receivers extend this authorization as a potentially inaccurate
method for assessing accountability. While accountability could be
safely extended to the EHLO, it might be inaccurately extended to the
Mail From (return path), or the PRA.
When based upon the Mail From or the PRA, SPF verification will not
reliably select domains accountable for messages. It is fairly common
for domains to share common outbound MTAs. Disputes about whether SPF
applies to the Mail From or to the PRA as delineated from an SPF address
list confound the accuracy of the deductions.
Feedback should attempt to report what the purported domain intended.
After all, SPF syntax often fails to exclude possible mis-interpretations.
Did the purported domain expect their authorization to apply to the:
1 - EHLO
2 - Return Path
3 - PRA
If so, how was such intent confirmed?
Critical aspects related DKIM/SPF feedback should clarify any remaining
ambiguity within the reporting scheme. To better assure against any
remaining ambiguity, there should be some type of indication whether the
MARF source-IP address was used in the SPF confirmation. This
information is not normally included in the Authentication-Results
headers. SPF allows for non-address confirmation methods, but
disambiguating this issue has been missed in the MARF report details.
There should also be confirmation what message element was used to
confirm the purported domain as well.
-Doug
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
