Re: Re: New SPF modifiers

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!

Philip

On 25-Jan-11 10:49 AM, Tim Draegen wrote:
> Hi, I posted some feedback on the proposed SPF modifiers on the MARF IETF list.  Here are my relevant-to-SPF comments:
>
> =======================================
> - I'm having a hard time understanding how the SPF "reportopts" will be used.  The publisher of the record adds the policy piece of SPF that leads to a (fail, softfail, neutral) result, usually by adding something like "-all" or "~all" to their record.
>
> EG, using the proposed syntax, I could write "v=spf1 ip4:1.2.3.4 report=email.address reportopts=f ~all". This would specify that I want reports on all SPF "fails" (distinct from "softfails").  However, my "~all" means that all my non-authorized email will end up receiving "softfails", resulting in me receiving zero reports.
>
> - Lots of real-world SPF records "include:" other records.  What if two report-related extensions appear due to the use of include:?
>
> - SPF records describe "mechanisms" for identifying authorized servers and "modifiers".  The extensions are "modifiers", but I'm uncertain if these will break existing SPF code, or if various implementors did the right the thing.
>
> - "reportsmtp=" is redundant with SPF's existing "exp:" modifier.
> =======================================
>
> Overall I like the idea of adding a feedback mechanism to SPF.  I'm keen on fleshing out exactly what is useful and possible, and then using that experience to improve SPF.  So, add "feedback mechanism" to the SPF-improvements bucket.
>
> Cheers,
> =- Tim
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/835710-69e7d341
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20110125104945:D79EB85E-289A-11E0-AED1-B6EF547047BC
> Powered by Listbox: http://www.listbox.com
>
>
>