Subject: Re: [spfbis] #43: New requirement for mx: or ptr records

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Aug 2012 23:19:50 -0700

At 18:17 26-08-2012, spfbis issue tracker wrote:
>#43: New requirement for mx: or ptr records
>
>  Message posted by Arthur Thisell on 26 Aug 2012:
>
>  in section 4.6.4, there is a new requirement that there must not be more
>  than 10 records for mx: or ptr:.   This completely wrong for ptr: because
>  a spammer could choose to send spam from a host with more than 10 PTR
>  records, thus forcing a domain's SPF record to return permerror, instead
>  of fail.   If anything, more than 10 PTR records should cause the ptr:
>  mechanism to automatically not-match.  It should also be made clear that
>  the %{p} macro is valid no matter how many PTR records are returned.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

One of the RFC 2119 requirements appears in different sections of the 
draft.  It's better not to restate normative text as it can lead to 
different interpretations in case of ambiguity.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 06:29:11 -0700

On Wed, Aug 29, 2012 at 11:19 PM, S Moonesamy <[email-masked]> wrote:
> One of the RFC 2119 requirements appears in different sections of the draft.
> It's better not to restate normative text as it can lead to different
> interpretations in case of ambiguity.

This is something the RFC Editor will catch and send back as well.
It's best to state the normative stuff once and then reference it
elsewhere rather than repeating it.

(Also of interest: The RFC Editor will not allow document Y to use
normative language to summarize other normative language in document X
(and rightly so).  I discovered this during the final work on the
experiment document.)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 09:38:39 -0500

>>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

In 4408 it's no match which means that it's random in the case where an authorized host has more than 10 if it gets a match or not.  The current wording was intended to not leave that unreliability hidden, but to clearly make it deterministically an error.

I see your point though.  We ought to make these no match, but make it very clear ADMDs can't publish records that use PTR if the authorized hosts exceed the limit.

I'm open to suggestions.

>different interpretations in case of ambiguity.

Where?

Scott K