On 02/Dec/11 01:00, [email protected] wrote:
> Filename : draft-ietf-marf-authfailure-report-05.txt
I still have some problems with the example. It seems that ".com" and
".net" were swapped at least in one place, and in any case it is
difficult to avoid confusion with them. Perhaps it's me, but wouldn't
it be possible to replace the domain names (tentatively) like so?
s/example.com/originator.example/
s/example.net/verifier-reporter.example/
Specific nits in the text/rfc822-headers (3rd) part are as follows:
* There is no "To:" header field,
* the topmost Received has ".com" and ".net" swapped,
* there are more than three minutes between internal servers
handling, and they are inconsistent with the Date field. I'd
change those lines with, say,
Received: from anexample.example.com ([192.0.2.1])
by mta1011.mail.tp2.example.net with ESMTP
Sat, 08 Oct 2011 04:16:24 -0700 (PDT)
Received: from internal-client-001.example.com
by mail.example.com (an alias for anexample)
with SMTP id o3F3BwdY028431;
Sat, 08 Oct 2011 04:16:23 -0700 (PDT)
Date: Sat, 8 Oct 2011 09:16:23 -0400 (EDT)
* the DKIM-Signature has d=example.net rather than d=example.com, and
* the A-R field misses a semicolon at the end of the first line while
the second line conflates two methods. I'd rewrite it taking three
lines, e.g.
Authentication-Results: mta1011.mail.tp2.example.net;
spf=pass smtp.mailfrom=anexample.example.com;
dkim=fail (bodyhash) header.d=examle.com;
For the second part, this should instead be
Authentication-Results: mta1011.mail.tp2.example.net;
dkim=fail (bodyhash) header.d=examle.com;
Also in the second part, where would Reported-URI be derived from?
Then, the report would be sent from the verifier/reporter back to
example.com. Instead, the outermost "Received:" field is "from
mail.example.com by mx.example.net". The IP address 192.0.2.1 doesn't
seem to belong here. Do we need an outermost Received field? If the
intent is to exemplify a generated but not yet sent report, it can be
omitted as well as Return-Path and Authentication-Results. If not,
I'd also add a DKIM-Signature.
One more nit, there is an unbalanced parenthesis in the last line of
the second paragraph of Section 3.2.4
DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body
of the message as generated by the verifier. The encoded content
MUST be limited to those bytes that contribute to the DKIM body
hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM].
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
