Re: [spfbis] What unused means

[Alessandro Vesely <[e-mail]>]

On Fri 20/Jul/2012 19:52:55 +0200 Hector Santos wrote:
> Scott Kitterman wrote:
>> On Friday, July 20, 2012 05:55:47 PM Alessandro Vesely wrote:
>>> As Scott said, a receiver who plays SPFbis MAY want to omit
>>> SPF checking for that particular record.  If the claim that
>>> those dangerous macros are unused is correct, that is a
>>> holdable choice for new or upgraded implementations.  OTOH,
>>> older software and records can continue to work undisturbed and
>>> still be compliant, which is a good interpretation of "backward
>>> compatibility".
>>
>> Note: I didn't say I thought this was a good idea.  I don't.  I
>> merely think it's better than partial implementations of the
>> protocol issuing errors for things that are valid, but they've
>> chosen not to implement.

draft-schlitt-spf-classic-00 discouraged PTR in 2004, so dropping it
in 2012 shouldn't come as much of a surprise.

> If I read this correct, then this a broken protocol by BIS design
> which is not what BIS is suppose to be about.
> 
> IMTO, we should spit the issues up.  PTR vs %p are two different
> things. PTR is used, %p is rare.

I'm unable to guess the meaning of that "T" in "IMTO".  True?  Tough?
 Typical?  Tergiversatory?

> Alternatively, if the ITCH is that big to have deprecated, removed,
> obsolete features, then do a SPF3.0 but do it properly so there is
> logic backward and upward path for both:
> 
>    v=spf1  continues supporting PTR, %p
>    v=spf3  does not support PTR, %p and whatever else you wish to strip.

I don't see how this would help anything, since the publisher doesn't
have a say about what SPF version, if any, receivers apply.  Let's
consider Stuart's example: "v=spf1 ?ptr:isp.com -all".  That client
wouldn't know what to write in a v=spf3 record, so I'm unable to guess
what advantages might result from a version change.

More on that example:

On Thu 19/Jul/2012 06:49:48 +0200 Stuart Gathman wrote:
> the ISP provides no SPF record of its own, but the smtp servers all
> end in "isp.com".

IMHO, the trick lays in the problem statement:  How can one know that
all their smtp servers end in "isp.com", given that the most obvious
place to make such a statement would be an SPF record?  Obviously,
ISPs can change host names without notice.

How meaningful is that name suffix?  RFC 5451 formalizes an "iprev"
authentication method, which is similar to the PTR mechanism, but
easier to pass, as it doesn't take such name.  A receiver who
implements both methods could mark a message from that client like so:

   Authentication-Results: SPFbis.example;
      iprev=pass policy.iprev=192.0.2.30;
      spf=neutral smtp.mailfrom=client-of-isp.com
   Received-SPF: neutral mechanism=ptr client-ip=192.0.2.30

I note that the speculated "isp.com" string is not reported.  In case
the message is abusive, I wouldn't know where to send a complaint.

RFC 5451 doesn't use the term "discouraged", but says:

 There is some contention regarding the wisdom and reliability of this
 test.  For example, in some regions it can be difficult for this test
 ever to pass because the practice of arranging to match the forward
 and reverse DNS is infrequently observed.  Therefore, the actual
 implementation details of how a verifier performs an "iprev" test are
 not specified here.  The verifier MAY report a successful or failed
 "iprev" test at its discretion having done some kind of check of the
 validity of the connection's identity using DNS.  It is incumbent
 upon an agent making use of the reported "iprev" result to understand
 what exactly that particular verifier is attempting to report.

 Extensive discussion of reverse DNS mapping and its implications can
 be found in [DNSOP-REVERSE].  In particular, it recommends that
 applications avoid using this test as a means of authentication or
 security.  Its presence in this memo is not an endorsement, but is
 merely acknowledgement that the method remains common and provides
 the means to relay the results of that test.

NB: [DNSOP-REVERSE] is the "blancmange" document that Andrew referred
in a parallel thread a couple of days ago.  An interesting reading,
rich of historical details, that document is alas also an example of a
topic which can yield not-published-as-an-RFC.  There's plenty of
different topics to discuss in 4408bis.


[DNSOP-REVERSE]
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06