> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Alessandro Vesely
> Sent: Wednesday, October 19, 2011 11:25 AM
> To: [email protected]
> Subject: Re: [marf] New Version Notification -
> draft-ietf-marf-authfailure-report-03.txt
>
> 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.
Section 3.2.3 in the -03 draft talks about this.
The content of that field is the canonicalized form of the body specified per
the signature that's being reported. DKIM specifies how to do that; this
document doesn't have to, other than to require the base64 encoding of it for
transport.
> 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.
> 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.
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.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
