Subject: [marf] Comments on draft-ietf-marf-spf-reporting

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Aug 2011 14:34:47 -0700

A few comments on this draft:

Section 3 should probably include a sentence at the end that says "In the absence of an 'r=' tag in the SPF record, all other fields defined above MUST be ignored."

Some of the stuff in Section 6 looks like it might have been copied verbatim from [ARF] or [DSN] (though I've not confirmed this).  If that's the case, I'd prefer to see them incorporated by reference rather than by value.  I also wonder if any copied from draft-ietf-marf-authfailure-report and/or draft-ietf-marf-dkim-reporting should also be incorporated by reference, and normative references added accordingly.

I think there's still an open question about whether Section 5.1 belongs here or in the fledgling SPFbis effort.  I think we have a few choices there:

1) Do it this way, since the future and path of SPFbis is uncertain.

2) Do it as its own memo and see if APPSAWG will pick it up right away.  It would only contain the "exp" and "redirect" entries just for the sake of creating the registry, and would be marked as "updates 4408".  Then, this memo simply updates that registry, and SPFbis can update it as well if needed.  This might be the cleanest solution.  (Barry, thoughts?)

3) Replace Section 5 with text that basically says we know SPF doesn't allow unknown modifiers, but proceed anyway because people that want this will be able to make the distinction somehow.  That might warrant demoting this to Experimental and upgrading it later.  Then SPFbis or a separate action can create the registry and make it all formal when its future is more clear.

I'm quite in favour of 1 and/or 2.

In Section 4.1, PermError needs an end-quote.

I think [DKIM] is an informative reference here, not a normative one.

In Appendix A, my last name is spelled incorrectly.  :)

Finally, does anyone know of any SPF implementations under current maintenance that are entertaining the idea of implementing these extensions?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Aug 2011 17:46:39 -0400

On Thursday, August 18, 2011 05:34:47 PM Murray S. Kucherawy wrote:
> Finally, does anyone know of any SPF implementations under current
> maintenance that are entertaining the idea of implementing these
> extensions?

I'm planning on doing it, but there is some other work I have to do first.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Aug 2011 17:54:40 -0400

On Thursday, August 18, 2011 05:34:47 PM Murray S. Kucherawy wrote:
> I think there's still an open question about whether Section 5.1 belongs
> here or in the fledgling SPFbis effort.  I think we have a few choices
> there:
> 
> 2) Do it as its own memo and see if APPSAWG will pick it up right away.  It
> would only contain the "exp" and "redirect" entries just for the sake of
> creating the registry, and would be marked as "updates 4408".  Then, this
> memo simply updates that registry, and SPFbis can update it as well if
> needed.  This might be the cleanest solution.  (Barry, thoughts?)
> 
> 3) Replace Section 5 with text that basically says we know SPF doesn't
> allow unknown modifiers, but proceed anyway because people that want this
> will be able to make the distinction somehow.  That might warrant demoting
> this to Experimental and upgrading it later.  Then SPFbis or a separate
> action can create the registry and make it all formal when its future is
> more clear.
> 

My preference would be to leave it here until 4408bis has some traction, but 
I'm OK with either 1 or 2.  4408 does allow unknown modifiers (unknown 
mechanisms aren't allowed), the registry just ensures the namespace is managed 
to avoid collisions.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Aug 2011 15:25:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Kitterman
> Sent: Thursday, August 18, 2011 2:55 PM
> To: [email-masked]
> Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting
> 

Ah, OK.  That makes life easier.

Then it's really just a matter of whether or not it's acceptable to do something in MARF that really APPSAWG or SPFBIS should be handling.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Aug 2011 09:20:44 -0400

> I think there’s still an open question about whether Section 5.1 belongs
> would only contain the “exp” and “redirect” entries just for the sake of
> creating the registry, and would be marked as “updates 4408”.  Then, this
> 3) Replace Section 5 with text that basically says we know SPF doesn’t allow
> unknown modifiers, but proceed anyway because people that want this will be
> able to make the distinction somehow.  That might warrant demoting this to
> Experimental and upgrading it later.  Then SPFbis or a separate action can
> create the registry and make it all formal when its future is more clear.

I think the best path for now is (1) -- assume that SPF is as it is,
and don't predict the future.  It's likely that this document will go
out before anything changes with SPF, and any SPF working group can
pick this up later and incorporate it, and flag itself as "updates
[this]".

Barry

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Aug 2011 00:07:28 +0200

On 18 August 2011 23:34, Murray S. Kucherawy wrote:

> Section 3 should probably include a sentence at the end that says “In the
> absence of an ‘r=’ tag in the SPF record, all other fields defined above
> MUST be ignored.”

+1

I don't see the difference between exp= and rs=, if it is in fact almost
the same an explanation of exp= in the context of MARF would be better
than a new modifier.

IMO result SOFTFAIL implies "want report", there should be no opt-out in
ro=.  Any PERMERROR or SOFTFAIL must be interesting for somebody wishing
to get reports at all (limited by ri= if desired).

A FAIL report is slightly dubious, if it's a bug in the policy senders
got an ordinary bounce (or a "go away" for their FAILing EHLO), and need
no extra report blowing up their logfile.  They certainly need no report
if some spammer forges their EHLO or MAIL FROM in thousands of FAILing
mails, eliminating backscatter is one of the main points of SPF.

It makes no sense to replace backscatter by opt-in FAIL reports.  If the
receiver does not reject FAIL curious senders might be interested in the
fact, but then ro=f could be limited to "unrejected" mail, or let's just
say ro=f is bogus.

OTOH ro=n could be very interesting, if it is something that should be
PASS or FAIL instead of NEUTRAL.  Suggestion:

ro=debug or ro=default, where "debug" asks for any NEUTRAL reports in
addition to the default PERMERROR and SOFTFAIL.  Obviously there can't
be SOFTFAIL reports for a policy without SOFTFAIL outcome, and that is
as it should be, but explaining it in the draft helps.

All bytes in an SPF policy are precious, ro=d for "debug" and no ro= at
all for "default" might be good enough.

> Some of the stuff in Section 6 looks like it might have been copied
> verbatim from [ARF] or [DSN] (though I’ve not confirmed this).  If
> that’s the case, I’d prefer to see them incorporated by reference
> rather than by value.

Okay, but for very important security points explaining what the given
reference is about helps.  The author can demonstrate to know what it
says, readers have no excuse to say that it was hidden in a reference.

> I also wonder if any copied from draft-ietf-marf-authfailure-report
> and/or draft-ietf-marf-dkim-reporting should also be incorporated
> by reference

SPF and DKIM tend to be orthogonal (as designed in the case Of DKIM),
what do you have in mind?  I have not yet understood the difference
between the r= address in I-D.ietf-marf-spf-reporting and section 7.2
in I-D.ietf-marf-reporting-discovery-01.

> there’s still an open question about whether Section 5.1 belongs
> here or in the fledgling SPFbis effort.

Quite a lot of folks volunteered to help with 4408bis, I hope that
can be done (= ready and published) in a few months.  If that's the
case it is not really necessary to create an SPF modifier registry
now:  IOW, there won't be any conflicts with the MARF SPF modifiers.

IIRC and if I did not miss something in 2009 or 2010 these are the
first *new* suggestions for modifiers since RFC 4408 got its number.

The simplified ro= proposed above could be queezed into op= options
to save bytes, or better, some remarks about "new modifiers in SPF"
in the old op= draft can be adopted in I-D.ietf-marf-spf-reporting.

> Replace Section 5 with text that basically says we know SPF doesn’t
> allow unknown modifiers

That is not exactly the case, see RFC 4408 section 6 intro.  The main
problem are new yes/no SPF modifiers claiming to have a default, and
"opting in" SPF policies published years before the modifier existed.

This would be strictly against the SPF design, working policies are
supposed to work without "upgrades" as long as they describe the IPs
permitted to send MAIL FROM, etc.  No need to "opt-out" from any new
tricks, the main topic of the old op= SPF draft.

Where precisely is the ball or token wrt a 4408bis WG at the moment?

-Frank