Subject: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Dec 2011 20:14:10 +0100

All,
as we known, the %{s} and %{l} SPF macros allow to publish records
that include a "tracking exists:" mechanism.  The quoted message below
contains a live example.

RFC 4408 says "it can be useful" (Section 9.1).  However, these
tracking mechanisms don't work well with DNS caches, may be
unavailable for domains that outsource DNS, and may be considered
unfair inasmuch as they force verifiers to also provide feedback.

OTOH, a different kind of mechanism can provide for delivering SPF
failure reports separately from compliant SPF verification.  That
might be easier to both set up and understand.

* Could decoupling feedback from verification gain more adoptions?

* Would it be feasible to consider making tracking mechanisms
  optional and/or deprecated in SPFbis?

TIA for any response.

On 28/Jan/11 00:55, Philip Gladstone wrote to spf-discuss:
> In many cases, you can do reporting today with SPF. If you have a
> stunt DNS, then you can make the receiver do specific lookups and
> thereby you can track what is going on.
> 
> In particular, this was much of the motivation behind the macro
> language in SPF.
> 
> I have a fairly nasty SPF record -- including things like
> '-exists:%{i}.%{l1r-}.user.%{d}'   This allows me to drop any mail
> that doesn't come from a valid user in my domain. Because of where
> this comes in my SPF record (after the allows for my normal servers),
> I get to see what is going on.
> 
> For example, I see:
> 
> 213.244.228.130.ga6uhifg.user.spf.gladstonefamily.net
> 140.177.205.131.ostmaster.user.spf.gladstonefamily.net
> 
> I suspect that in the second case, either there is an incompetent
> forger who can spell postmaster, or there is a buggy spf
> implementation that leaves off the first character!

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 14 Dec 2011 17:21:45 -0500

Centuries ago, Nostradamus foresaw that on 12/14/2011 02:14 PM, 
> * Could decoupling feedback from verification gain more adoptions?
Possibly for spfv3.  You would have to be more specific on exactly what 
a tracking specific mechanism would do, but having it optional for 
verification purposes (in case a checker wants to opt out of tracking) 
is a great idea.  For spfv3.  This idea should go on the spf-discuss 
list, as spfbis is not designing spfv3.
>    optional and/or deprecated in SPFbis?
No.  This is a no brainer.  No functional changes for SPFbis.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Dec 2011 16:16:47 +0100

On 14/Dec/11 23:21, Stuart D Gathman wrote:
> Possibly for spfv3.  You would have to be more specific on exactly
> what a tracking specific mechanism would do, but having it optional
> for verification purposes (in case a checker wants to opt out of
> tracking) is a great idea.

Sorry, I thought it was clear which mechanism I alluded to.  Scott is
writing it withing MARF.  I was wandering if and how it would
correlate with SPFbis and Julian's scope.
http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/

> For spfv3.  This idea should go on the
> spf-discuss list, as spfbis is not designing spfv3.

Thanks

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 15 Dec 2011 19:02:26 -0500

> http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/

I think that they are largely independent.  

The exists: trick has been known since 2003 or 2004, but is very rarely used 
because it's complex.  

Including SPF as part of a more general authentication failure feedback 
mechanism (which is what we are doing in MARF) will provide a technically more 
simple mechanism that's common with that used by other related technoglies 
such as DKIM.  

The MARF effort will, however, produce an approach that requires two willing 
parties to work, so it doesn't entirely replace the exists: trick for domains 
interested in using it.

In any case, the features used for the exists: trick are in use, so I don't 
see them being removed as part of the SPFbis effort.

Will it gain more adoptions?  I think so, but I think it targets a slightly 
difference audience than using exists:, so the efforts should proceed 
independently.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Dec 2011 13:36:27 +0100

> I think that they are largely independent.  

Ok, at this point I agree.

> see them being removed as part of the SPFbis effort.

There was much discussion about evilness of local macros.  In theory,
a hairy SPF implementation could provide for (optionally) disabling
them.  If we were aware of such an implementation, we could add an
informative paragraph in SPFbis to discourage local macros in favor of
spf-reporting.  That's where I saw the possibility of a connection.

Since neither us nor any implementation we know of wish to treat local
macros differently from what RFC 4408 says, I see no (other) reason to
bundle spf-reporting and SPFbis.

---

From: Dotzero <[email-masked]>
Date: Fri, 16 Dec 2011 09:18:11 -0500

> spf-reporting.  That's where I saw the possibility of a connection.

This might appropriately be addressed in a BCP.

> _______________________________________________
>