On Saturday, July 09, 2011 11:24:09 PM Julian Mehnle wrote:
> Scott Kitterman wrote:
> > On Tuesday, June 28, 2011 09:35:07 AM [email protected] wrote:
> > ...
> >
> > > Title : SPF Authentication Failure Reporting using the
> > >
> > > Abuse Report Format
> > >
> > > Author(s) : Scott Kitterman
> >
> > ...
> >
> > This is the first draft of the split out document. Please review and
> > let me know how it can be improved.
>
> Interesting. As you personally asked me to do, here's a thorough review.
>
> Shouldn't it say "Updates: 4408, 5965" at the top?
No, because it doesn't actually change those RFCs, it provides extensions.
Due to the IANA modifier registry, that might be appropriate for 4408, I'm not
sure.
> Can a Standards Track document refer *normatively* to an Experimental
> document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely
> posing the formal question.)
Addresses already in a different sub-thread.
> In section 3, "Optional Reporting Address for SPF", in the "r="
> definition, why is it a "SHOULD" in "an e-mail address to which a report
> SHOULD be sent"? Anyone following this document should be told they MUST
> send a report to that e-mail address (subject to the ri=/ro=
> specifications); anyone *not* following this document will do what they
> want anyway (with regard to this document). Perhaps it's better to word
> this as follows:
>
> "A local-part or addr-spec (...) specifying an e-mail address to which
> the domain owner expects reports to be sent when ..."
I think SHOULD is reasonable here. In general terms SHOULD = MUST unless you
have a good reason why not. I think that's OK in this context (an example
might be not sending reports if the sending system were under heavy load).
> In the same paragraph it says: "The format of this reply" —
> s/reply/report/. It says: "the domain whose policy was queried" — this
> might be ambiguous in the context of a possible future overarching policy
> standard, so s/policy/SPF record/ (the remainder of the sentence can then
> probably be removed).
What I'm going for here is to make sure that it's clear that the following
should occur:
1. Don't send an FBR due to mechanisms specified in a record that is
'included' in another domain's record. If an ISP uses these mechanisms in
their SPF record and that SPF record is included in other records by their
customers, that shouldn't be a trigger for a report.
2. If only the localpart of the email address is specified, the domain part
that should be appended should be the original domain, not the on that's
'current'. This would give a logical behavior with redirect=
The distinction between these two (and I know you know this) is that include:
is meant to traverse administrative boundaries (so the FBR policy should not
cross that boundary) and redirect= is meant to be used with an administrative
boundary, so FBR policy should follow. With this construct, using the local
part produces a per-domain reporting address for each domain within the
administrative group and using the full address produces one common address
for all domains.
I took another shot at it. Let me know if it's not clear yet.
> In the same paragraph the ABNF grammar is incorrect: the SPF grammar does
> *not* allow WSP around the "=" character. The same problem exists in the
> later grammar rules in this document. Generally, SPF modifiers may not
> contain any WSP at all, not even in the modifier value.
Fixed.
> In the "rf=" definition, I think it is questionable to REQUIRE ("MUST")
> report generators to generate reports in the first format from the list
> of preferred formats they are capable of generating. Report generators
> may have preferences of their own (for whatever reason), and there is no
> point in this document declaring a generator incompliant if it chooses to
> generate reports in a format *less* preferred by a domain owner even
> though it could theoretically generate a more preferred format. IOW,
> make this a "SHOULD". On the other hand, the last sentence specifying
> the case when no supported formats are requested should end in "then any
> reports MUST NOT be sent"; there *is* a point in declaring generators
> sending reports in unrequested formats incompliant.
I agree. Changed. If you don't want reports in a certain format, don't put
them on the list.
> The same paragraph refers to a description of a reporting format
> registry in section 5, but section 5 does not establish such a registry.
Agreed. I think that goes in draft-ietf-marf-authfailure-report and so I've
changed the reference, although it doesn't look to me like it's covered there.
> In the "ri=" definition, the semantics of the interval mechanism are
> weird. E.g., an "ri" value of 0 meaning anything other than "send no
> reports" is counterintuitive. Also the meaning of a value of 1 is
> unclear — does it mean "report on every failure" (like a value of 0) or
> "report on 1/2 of failures"? I assume this is because the mechanism was
> designed foremost to be easy to implement. However, I think it is more
> important that the mechanism be easy to understand by domain owners.
> A relative downsampling factor (a fractional number from 0 to 1) would be
> functionally equivalent but easier to understand by domain owners, while
> being similarly easy to implement. I see there is also talk about the
> possibility of an exponential backoff. Whatever satisfies the real world
> needs and is easy to understand. Consider making this extensible by
> syntax (e.g., by using a mode indicator as the "ri=" value's last
> character, so new modes can be defined in the future).
There's some ongoing discussion about this. I think it should be common
between SPF and DKIM, so I'm leaving it for now. I expect the right answer is
to define the semantics in draft-ietf-marf-authfailure-report so it's common
the the expression to the method specific drafts.
> Also, the meaning of "type of incident" is completely unclear. Does this
> refer to all SPF failures for the domain, or are SoftFail results to be
> tracked separately from Fail results? What about PermError results?
> Does this refer to the "ro=" types listed in section 4? If so, this is
> not clear. And are there perhaps even more elements to a certain "type
> of incident"? Does this interact with other authentication methods?
> Does a report on a message that failed SPF also count against the *DKIM*
> reporting interval if the message happened to also have failed DKIM?
There is currently no interaction between SPF and DKIM (by design - maybe
later). Type in this context means SPF/DKIM (if people think it should be
different, let's discuss). I've clarified and will fix it more later if people
think that's wrong.
> In the "ro=" definition, the ABNF grammar should be changed to make the
> "all" token mutually exclusive with a colon-separated list of tokens.
> Would it perhaps be more obvious to use the full SPF result code names
> instead of one-letter tokens?
The results aren't exactly SPF results (we combine TempError and PermError
into e and since these go in SPF records in DNS, I think compatctness counts,
so I think it would be more obvious in some respects, but not better to use
the full name.
> The "rs=" definition is suboptimal because the SPF grammar disallows WSP
> or quoted-atoms. While the current grammar specified by the "rs="
> definition provides for this by requiring the value to be
> quoted-printable encoded (which turns whitespace into "=20"), this is
> still not very useful because any meaningful message would eat up a lot
> of space in the SPF record, which is already limited in size due to DNS
> limitations. I think it would be more useful to have "rs=" refer to a
> DNS name, under which a TXT record with the desired message will be
> found, similar to SPF's existing "exp=" modifier. That message should
> also be subject to macro expansion just like "exp=" messages. Finally,
> it would be more consistent (with "exp=") to then call this new modifier
> "rexp=" or "re=" or "rx=".
Looking it over again, I think it's redundant with exp= and domains should
just use that. I'll remove it.
> In section 6.2, "Reports From Unrelated Domains", the scenario described
> is a problem only for domains referenced via "redirect=" modifiers, not
> for ones referenced via "include:" mechanisms, since section 3 explicitly
> specifies that r= modifiers in records found by following an "include:"
> mechanism must be ignored. However, perhaps section 3 should also say
> the same thing about records found by following a "redirect=" modifier,
> even though that makes specifying reporting parameters an inconvenience
> for domain owners who legitimately use "redirect=" a lot.
Given that redirect is intended to be used within an administrative domain, I
think it's appropriate to not have a similar rule for redirect=. I think the
modified text in the record construction paragraph makes it clearer. Let me
know what you think.
> Section 6.3, "Forgeries", commingles forgeries/fabrications and
> denial-of-service attacks, which are generally (as well as specifically
> in this context, as far I as can see) separate issues. What's the DoS
> issue in this context?
>
> The concern about forgeries remains unresolved. The section merely
> presents a few options, but then goes nowhere. I understand that the
> options presented (yet not mandated) are problematic. Does this perhaps
> *require* further discussion before this document is advanced? If no
> acceptable solutions are developed, then the section should be rephrased
> to merely warn about the possibility of fabricated reports and perhaps
> briefly explain why the apparent solutions were discarded.
I think this is no more/no less a reminder that these emails suffer the same
problems as email in general. I think that it's ~OK as is, but I'm open to
suggestions for improvement.
> Section 6.4, "Automatic Generation", seems to appeal to verifying agents'
> sense of responsibility. This seems pointless. Perhaps this section
> would be better converted into a warning to domain owners publishing "r="
> that large volumes of reports (legitimate or fabricated) should be
> expected. Similar things could be said about the volume related concerns
> in section 6.6, "Reporting Multiple Incidents".
Adjusted.
> Section B constitutes a good opportunity for explaining the semantics of
> the "ri=" modifier as well as demonstrating the multiple-tokens support
> in the "ro=" modifier. Also, the positioning of the r*= modifiers within
> the SPF record insinuates that there might be a relevance to it. Per RFC
> 4408 there is not. Either state this clearly or move the r*= modifiers
> after the "-all" mechanisms. This will help avoid misunderstandings.
I moved one of them to make this clear. Since one is now before and one
after, I think that makes it even more obvious it can go anywhere.
Scott K
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
