On 19/Oct/11 20:37, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>>
>> DKIM-Canonicalized-Body is not required, but that is not the same as
>> saying that the first part of it suffices. For example, if l=0 or the
>> body is empty, the spec says it should be canonicalized to a CRLF.
>
> If it's included, it has to be complete or it's not useful. If
> "l=0" or the body is empty, DKIM-Canonicalized-Body (if included)
> must be the base64 encoding of a CRLF, because that's the
> canonicalized body in that instance.
All right, I think the amount of guesswork is minimal (e.g. what if
l=1?) and the recipient should be prepared to "massage" the datum
anyway, according to what format was saved on signing, for comparison.
>> Sure, but "negative" ought to be defined, and it should be comparable
>> with the ro= values defined by the relevant per-method specs (which
>> may change between report generation and reception.)
>
> I suppose that can't hurt. Something like this:
>
> 3.1:
>
> Authentication-Results: MUST appear exactly once. It MUST be formatted
> according to
> [AUTH-RESULTS], and MUST reflect only a single authentication failure.
> To report
> multiple failures for a single message, multiple reports MUST be
> generated.
>
> We could also include a note that says "failure" doesn't include
> stuff like temp-failures, but I don't think that's really
> necessary.
However, SPF reporting (sect 4.1) has the following for ro=
e Reports are requested for messages that produced an SPF result of
"TempError" or "PermError.
>> With multiple reports, can the Auth-Failure field help determining why
>> a report was generated? It is important for people who need to fine
>> tune their ro=.
>
> Indeed, Auth-Failure is the only way to know why the report was
> generated, as far as I can tell.
Yes, if "Auth-Failure: spf" and "spf=temperror" in A-R, then the
recipient knows it was ro= in their SPF record to trigger the report.
Constraining A-R further would only make sense if we wanted to avoid
multiple reports.
> We can't reference the other drafts from this one as it'll be
> published first, unless there's some reason that they all need to
> go out together.
There is also no reason why the drafts should be published
independently, since defining further failure types, e.g. VBR, will
need to redefine stuff in authfailure-report anyway. IMHO, we should
feel free to reference the drafts from one another if that improves
clarity.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
