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

From: "John Levine" <[email-masked]>
Date: 23 Jan 2012 21:37:49 -0000

Since Scott says he wants to move this forward, here's some comments:

In section 3, the r= option lets you specify an arbitrary address,
which is an invitation to remote mailbombing.  I have my doubts about
the utility of inviting reports from random strangers, but if you're
going to do it, make it just a local part so you can only mailbomb
yourself.

The rf= option specifies a report format.  The only plausible report
format described in an IETF standard is ARF, and it seems unlikely
that there will others, so lose this option.  If you want to make
private arrangements to use non-standard formats, that's fine, but
they don't go into the spec.

The ri=N option asks senders to discard N/(N+1) of the reports they
might generate.  It's not clear to me what this is supposed to
accomplish.  If the goal is to limit the traffic, I'd suggest making
it the maximum number of reports to send per minute or per hour.  Keep
in mind that people sending reports will do whatever they do, so hosts
MUST be prepared to deal with whatever garbage reporters send.

In 6.2, it correctly notes that an included SPF record might have an
r= field, inviting all sorts of mischief.  I'd suggest adjusting
section 3 to say that the r= ri= and ro= options should be ignored in
includes and perhaps in redirect records.

I would shrink 6.3 somewhat and just say that the envelope of any
report sent to an address found using the process in this document
MUST have an envelope that produces an SPF Pass.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2012 17:51:42 -0500

> going to do it, make it just a local part so you can only mailbomb

I agree.  I'd like to change this in -03.

> they don't go into the spec.

I'm fine with this.  Since this is going into an IANA registry, the same RFC 
that defines the report type can define this.

> MUST be prepared to deal with whatever garbage reporters send.

Here I disagree.  Assuming senders implement this as specified (and yes, I know 
they all won't) I think some kind of a global fractional rate is better than a 
per sender volume.  In applications where I've seen similar things done in 
private arrangements, the goal is to get a statistically valid sample of data 
without putting excessing strain on sending or receiving systems.

If you specify X per hour or Y perm minute then low volume senders will send 
at their normal rate while high volume senders throttle back.  This skews the 
sample data.

I find the current method a bit confusing to follow in English, but it would be 
easy enough to implement in code (I inherited it from the document split out).  
Describing the rate as a percentage of volume might be a little more 
understandable.  I could see doing either.

> includes and perhaps in redirect records.

I agree for include: as it's intended to cross administrative boundaries.  
Redirect is intended to be used within a single administrative structure and 
the target domain is the same as for the initial record (this is described in 
paragraph 6.1 of RFC 4408), so I think for redirect it is OK to process them.

> MUST have an envelope that produces an SPF Pass.

You think that's better than <> for Mail From and HELO/EHLO that Pass?  What 
about the rest of the text?  Just ditch it?  I'm not sure I'm following you 
here, so I'd appreciate it if you would amplify (with a proposed 6.3 text).

Thanks for the review,

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2012 00:42:29 -0000

>> accomplish.

>without putting excessing strain on sending or receiving systems.

If the goal is to get a sample rather than to rate limit, it makes
sense.  Please say that so you don't get the same complaint the next
time someone looks at it.  A percentage would be easier to explain and
no harder to implement.

>paragraph 6.1 of RFC 4408), so I think for redirect it is OK to process them.

Don't feel strongly either way.

>here, so I'd appreciate it if you would amplify (with a proposed 6.3 text).

You say to use a null bounce address and a HELO with a domain that
produces an SPF Pass.  I say use whatever bounce address you want, but
be sure that it produces an SPF Pass.  I don't see any practical
advantage to requiring a null bounce address.  If it's not null, and
the r= address doesn't work, the reporter might get the report bounced
back, but if I were a reporter I'd prefer to know if my reports were
going into the void so I could stop sending them.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2012 20:07:07 -0500

John Levine <[email-masked]> wrote:
...
>going into the void so I could stop sending them.

The advantage of null mail from is no bounce loops.

How would you feel about SHOULD use null mail from (with EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From,  if not null, MUST pass SPF?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2012 01:26:02 -0000

>The advantage of null mail from is no bounce loops.

Right, and the disadvantage is no feedback if it's bouncing.

>How would you feel about SHOULD use null mail from (with EHLO/HELO SPF pass), but
>MUST avoid mail loops and Mail From,  if not null, MUST pass SPF?

Make it MAY use null bounce address and we have a deal.  And whether
or not it's null, it MUST pass SPF.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jan 2012 17:47:53 -0800

> or not it's null, it MUST pass SPF.
Dear John,

It would be a bad practice to require a protocol that defeats DNS/API 
caching by incorporating local-part macros that are of no value.  Macros 
able to target a domain with a significant number of recipient generated 
transactions per message where the victim may not be evident within any 
referenced record or message.  Is MUST not use local-part macros an 
ingredient of this mustard?

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2012 22:22:26 -0500

>ingredient of this mustard?

No. This is no different than any other use of SPF.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2012 22:23:10 -0500

>or not it's null, it MUST pass SPF.
Sounds good.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2012 08:54:42 -0800

On 1/23/12 7:22 PM, Scott Kitterman wrote:
> >>>> You say to use a null bounce address and a HELO with a
> >>>> domain that produces an SPF Pass. I say use whatever bounce
> >>>> address you want, but be sure that it produces an SPF Pass.
> >>>> I don't see any practical advantage to requiring a null
> >>>> bounce address. If it's not null, and the r= address doesn't
> >>>> work, the reporter might get the report bounced back, but if
> >>>> I were a reporter I'd prefer to know if my reports were going
> >>>> into the void so I could stop sending them.
> >>> The advantage of null mail from is no bounce loops. Right, and
> >>> the disadvantage is no feedback if it's bouncing.
> >>>
> >>> How would you feel about SHOULD use null mail from (with
> >>> EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From,
> >>> if not null, MUST pass SPF?
> >> Make it MAY use null bounce address and we have a deal. And
> >> whether or not it's null, it MUST pass SPF.
> > Dear John,
> >
> > It would be a bad practice to require a protocol that defeats
> > DNS/API caching by incorporating local-part macros that are of no
> > value. Macros able to target a domain with a significant number of
> > recipient generated transactions per message where the victim may
> > not be evident within any referenced record or message. Is MUST
> > not use local-part macros an ingredient of this mustard?
>

Dear Scott,

Perhaps, but to what end?

Until SPF is safe for the rest of the Internet, its use must not be 
mandated.

After all, SPF mechanisms and macros permit more than 100 reflected DNS 
transactions per message times the number of parameters checked.  This 
is suggesting a check against the Mail From and EHLO parameter that 
lacks any other form of cache-able authentication.  The use of 
local-part macros with SPF means this validation process must NEVER be 
assumed cache-able.

Until SPF copes with the current Internet environment, its use should 
not be mandated.

What happens when the client and server do not share the same version of 
Internet Protocol and one of their Internet providers compensates by 
translating between the two?

This might lead to nonsensical SPF records containing "exists:icann.org" 
or ending with "+all".

Regards,
Doug Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 12:13:15 -0500

> Until SPF is safe for the rest of the Internet, its use must not be

Safe or not, it's not mandated.  This spec is completely optional and is only 
applicable to domains doing SPF already.

> local-part macros with SPF means this validation process must NEVER be

This use of SPF is no different than any other, so it's no better or worse 
here.  I don't think your theories about how SPF will make the Internet melt 
are on topic in the MARF working group.

> Until SPF copes with the current Internet environment, its use should

Safe or not, it's not mandated.  This spec is completely optional and is only 
applicable to domains doing SPF already.

> translating between the two?

This use of SPF is no different than any other, so it's no better or worse 
here.  I don't think your theories about how SPF will make the Internet melt 
are on topic in the MARF working group.

> This might lead to nonsensical SPF records containing "exists:icann.org"

No specification can ensure people don't do odd things.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2012 09:47:12 -0800

On 1/25/12 9:13 AM, Scott Kitterman wrote:
> > What happens when the client and server do not share the same
> > version of Internet Protocol and one of their Internet providers
> > compensates by translating between the two?
>  This use of SPF is no different than any other, so it's no better or
>  worse here. I don't think your theories about how SPF will make the
>  Internet melt are on topic in the MARF working group.

Dear Scott,

A requirement for an SPF PASS seems illogical for assessing SPF failure 
feedback.  Disparities involving use of different IP protocols seems 
poorly considered in this case, does it not?

The SPF macro concern is also unlikely to impact the email providers 
facilitating a targeted attack.

What prevents use of DKIM as the only required vetting for feedback?

> > This might lead to nonsensical SPF records containing
> > "exists:icann.org" or ending with "+all".

A specification should not require a protocol that expects an 
inappropriate processing of macros, nor should it inhibit the 
communications that it intends to support.

Regards,
Doug Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 12:54:52 -0500

> poorly considered in this case, does it not?

Logical or not, the spec doesn't actually do that, so you can relax.

> facilitating a targeted attack.

To this extent that is a problem (and we'll have to agree to disagree on 
this), this is no different than any other application of SPF, so it's not 
relevant to the discussion.

> What prevents use of DKIM as the only required vetting for feedback?

The issue in question is about the envelope and looping reports.  I think DKIM 
is orthogonal to the point.  Even if it's not, requiring implementation of an 
entirely separate technology (DKIM) to prevent loops is overkill and there's 
no evidence of any need for it to support interoperation.

> communications that it intends to support.

I think we're OK on those grounds here.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 09:58:37 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, January 25, 2012 9:13 AM
> To: [email-masked]
> Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02
> 

I concur.  Design concerns with SPF itself are not within the MARF scope.

-MSK, as co-chair