Hi Murray,
At 23:01 02-10-2011, Murray S. Kucherawy wrote:
Yes, please. In particular, do you have an alternate suggestion?
The draft is an extension of ARF which uses the
Authentication-Results header field. I suggest reusing the RFC 5451
approach to avoid problematic terms:
This memo registers an extension report type to ARF to be used for
reporting forensic information about messages that fail one or more
message authentication effort.
BTW, you used "effort" and "checks".
I noticed that Authentication-Results (Section 3.1) can appear only
once. A message may have one or more such header fields.
Indeed, but this is essentially creating a profile of ARF (by
creating a new feedback type) for the purpose of reporting messages
that fail authentication checks. I don't think there's anything
wrong with saying "for this profile, Reported-Domain is mandatory".
There may be more than one "Reported-Domain". It is about the same
problem as Authentication-Results. Do you want one report for each
occurrence or do you want one report per message? In the first case,
we are reporting failures whereas the second case is about delivery
status (Section 3.2.1).
It's not specified what actually happened. The term is recycled
from RFC5451, where "policy" basically means "other, per local
policy configuration", such as rejecting a signature because "l=" is
in use (i.e., not required by DKIM, but certainly legal at the
discretion of the receiver).
RFC 5451 states that:
"The message was signed but the signature or signatures were
not acceptable to the verifier."
This is not an authentication failure (Section 3.2.1).
BTW, ARF was initially designed as a format for reporting email
abuse. This draft seems to be tackling deliverability even though
that is not mentioned explicitly. If I understood the charter
correctly, the aim was to specify integration of ARF in DKIM-aware
environments and to generate phishing reports. For example, if
someone is generating a "fake" DKIM-Signature header, the domain
being "phished" can receive reports of such occurrences. There are
times when it may a technical glitch instead of a phish, e.g. DKIM
signature not verifying. The report can convey debugging information
to identify such issues.
There isn't any discussion in the draft about the problem being
addressed. The document comes out as trying to report back as much
information as possible without any explanation.
Regards,
-sm
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
