Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt

From: Julian Mehnle <[email-masked]>
Date: Sun, 10 Jul 2011 03:24:09 +0000

Scott Kitterman wrote:

> On Tuesday, June 28, 2011 09:35:07 AM [email-masked] 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?

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.)

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 ..."

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).

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.

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.

The same paragraph refers to a description of a reporting format
registry in section 5, but section 5 does not establish such a registry.

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).

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?

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 "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=".

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.

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.

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".

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.

So long,

- -Julian

---

From: Barry Leiba <[email-masked]>
Date: Sun, 10 Jul 2011 09:34:22 -0400

> posing the formal question.)

Indeed; this is a question we'll have to discuss with our AD, to
figure out what the right way to go is.  There are some people wanting
to clean up the SPF spec and put it on Standards Track.  Perhaps this
document can wait for that.  Perhaps this document can be made
Experimental, and then both docs can move to Standards Track at the
same time.  Perhaps we can get the IESG to allow the down-ref.  We'll
have to see.

Barry, as MARF chair

---

From: "McDowell, Brett" <[email-masked]>
Date: Sun, 10 Jul 2011 09:11:47 -0600

This is an important topic for sure.

---
Sent from my mobile phone

On Jul 10, 2011, at 9:36 AM, "Barry Leiba" <[email-masked]> wrote:

> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Jul 2011 15:25:14 -0400

> same time.  Perhaps we can get the IESG to allow the down-ref.  We'll

I've started working on such an update in conjunction with one of the original 
RFC 4408 authors.  Obviously I didn't make the cut off for this IETF, but I 
don't expect this to be a particularly long or difficult process (the 
clarifications needed for a 4408bis are reasonably well documented and minor).

There is a roughly zero percent chance of there being technical changes in 
4408bis that would affect draft-ietf-marf-spf-reporting.  The one thing that 
might affect it would be, depending on the relative timing, if we moved the SPF 
modifier registry from draft-ietf-marf-spf-reporting to 4408bis.

My intent is to proceed (for now) as if the downref will be allowed.  Doing 
this as experimental and then revising it shortly thereafter seems like 
pointless paperwork to me.  If, down the road, it needs to be adjusted, I'll 
adjust.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Jul 2011 18:31:35 -0400

> 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.

> posing the formal question.)

Addresses already in a different sub-thread.

>   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).

> standard, so s/policy/SPF record/ (the remainder of the sentence can then

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.

> contain any WSP at all, not even in the modifier value.

Fixed.

> 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.

> 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.

> 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.

> 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.

> 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.

> "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.

> 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.

> 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.

> in section 6.6, "Reporting Multiple Incidents".

Adjusted.

> 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