I see there's a new version of authfailure-report. Overall it's getting
there, but it still has some severe confusion about RFC 2119 language. In
2119-ese, MUST means that if you don't do that, it won't interoperate at
all so don't even try.
In section 3.1 of the draft:
Authentication-Results: Syntax as specified in [ARF]. Furthermore,
[ARF] specifies this field is OPTIONAL and appears at most once;
for this extension, this field MUST be present if that value is
available. It MUST be formatted according to [AUTH-RESULTS], and
MUST reflect only a single email authentication method failure.
The ARF RFC doesn't define Authentication-results, RFC 5451 does.
I don't understand what "MUST be present if that value is available"
means.
Referring to 2119, it would mean that if you have cruddy software that
doesn't record the auth results so the value isn't available, it's OK to
send a report without it, but if do you have it available but don't want
to send it, you can't send a report at all, which is silly. I understand
that some people really really REALLY want their reports to be unredacted,
but as we discussed a month or two ago, reporters will send what they're
willing to send and no more, regardless of what an RFC says. In fact, an
auth failure report without this info is often entirely usable, so just
delete this paragraph.
To report multiple failures for a single message, multiple reports
MUST be generated.
That sentence says that if you have multiple failures you have to report
all of them, or else don't report anything. Move it to just above
section 3.1 and change it to:
A single report describes a single authentication failure.
Multiple reports MAY be used to report multiple failures for a
single message.
Then there are several sections like this one with the same MUST
language:
Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore,
[ARF] specifies this field is OPTIONAL and appears at most once;
for this extension, this field MUST be present if that value is
available.
The next three similar paragraphs cover Original-Mail-From, Source-IP, and
Reported-Domain. Same problem, same solution, delete all four of them.
I suppose you could say something like it is RECOMMENDED to include these
items to help better diagnose the authentication failure.
In Section 4, the ABNF, the definition of auth-failure both says that a
token is one of a list of types and that it's imported from [MIME].
Importing seems wrong since that suggests it can be any tokenish string,
but there's nothing that says that unknown auth-failure types are ignored.
Suggest removing the references to token and instead enumerate the failure
types, similar to the list of delivery results just below it.
dkim-selector is also defined as a token, but actually it's a sub-domain.
Import it from [DKIM].
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
