Mailing List Archive: New SPF modifiers

New SPF modifiers

Jan 8, 2011, 11:41 AM

Post #1 of 6 (2686 views)

A new IETF draft posted yesterday proposes a IANA registry for a list
of all registered SPF modifier names and their defining documents.
The initial lists would consist of "exp" and "redirect" defined in
RFC 4408, and five more modifiers for reporting authentication failure.

-------- Original Message --------
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-marf-dkim-reporting-01.txt
Date: Fri, 07 Jan 2011 12:45:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

Title : Authentication Failure Reporting using the Abuse Report Format
Author(s) : M. Kucherawy, H. Fontana
Filename : draft-ietf-marf-dkim-reporting-01.txt
Pages : 31
Date : 2011-01-07

This memo presents extensions to the Abuse Reporting Format (ARF),
DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF)
specifications to allow for detailed reporting of message
authentication failures in an on-demand fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: New SPF modifiers [ In reply to ]

tim at eudaemon

Jan 25, 2011, 7:49 AM

Post #2 of 6 (2606 views)

Permalink

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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110125104945:D79EB85E-289A-11E0-AED1-B6EF547047BC
Powered by Listbox: http://www.listbox.com

Re: New SPF modifiers [ In reply to ]

julian at mehnle

Jan 25, 2011, 8:38 AM

Post #3 of 6 (2601 views)

Permalink

Tim Draegen wrote:

> Hi, I posted some feedback on the proposed SPF modifiers on the MARF
> IETF list.

I'll have to check that out.

> 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:?

I'll have to check out that draft-ietf-marf-dkim-reporting draft, but I'd
hope that all non-top-level "report=" modifiers are to be ignored.
I think such a modifier should only ever concern the *sender* domain
("sender" as specified in RFC 4408, section 4.1).

> - 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.

They SHOULD ignore unknown modifiers, but I hear what you're saying.
FWIW, the RFC 4408 test suite <http://www.openspf.org/Test_Suite> has a
test case named "modifier-charset-good" that effectively tests for
whether unknown modifiers are tolerated and ignored:

http://www.openspf.org/svn/project/test-suite/rfc4408-tests-2009.10.yml

-Julian

-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110125113852:A95B04A0-28A1-11E0-8B79-2CC1F559ED1D
Powered by Listbox: http://www.listbox.com

Re: Re: New SPF modifiers [ In reply to ]

scott at kitterman

Jan 25, 2011, 6:51 PM

Post #4 of 6 (2602 views)

Permalink

On Tuesday, January 25, 2011 11:38:45 am you wrote:
> Tim Draegen wrote:
> > Hi, I posted some feedback on the proposed SPF modifiers on the MARF
> > IETF list.
>
> I'll have to check that out.
>
> > 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:?
>
> I'll have to check out that draft-ietf-marf-dkim-reporting draft, but I'd
> hope that all non-top-level "report=" modifiers are to be ignored.
> I think such a modifier should only ever concern the *sender* domain
> ("sender" as specified in RFC 4408, section 4.1).

I generally agree, with the slight modification that I think such modifiers
which appear after following redirect= should also be applied (this is in my
mind analogous to the policy result (*all) coming from the record the domain
is redirected to. So I would suggest ignoring such modifiers coming from an
include: mechanaism (the result of include and only be match/not match or an
error condition), but specify that modifiers following a redirect modifier
should be processed. This needs to be specified in the document.

> > - 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.
>
> They SHOULD ignore unknown modifiers, but I hear what you're saying.
> FWIW, the RFC 4408 test suite <http://www.openspf.org/Test_Suite> has a
> test case named "modifier-charset-good" that effectively tests for
> whether unknown modifiers are tolerated and ignored:
>
> http://www.openspf.org/svn/project/test-suite/rfc4408-tests-2009.10.yml

Additionally, there have been enough false starts towards new modifiers over
the last few years where some small number of people involved in SPF
development published modifiers that are unknown to RFC 4408 that I think if
there were significant implmentations in the wild that had a problem with this
we'd have heard about it by now.

Scott K

-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110125215122:2689BEEE-28F7-11E0-9E9A-AFE6F64C79A1
Powered by Listbox: http://www.listbox.com

Re: Re: New SPF modifiers [ In reply to ]

philip at gladstonefamily

Jan 27, 2011, 3:55 PM

Post #5 of 6 (2592 views)

Permalink

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
>
>
>

-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110127185533:EBE794D4-2A70-11E0-865A-F2D46389EF3D
Powered by Listbox: http://www.listbox.com

Re: Re: New SPF modifiers [ In reply to ]

derek.diget+spf-discuss at wmich

Jan 28, 2011, 8:46 AM

Post #6 of 6 (2588 views)

Permalink

On Jan 27, 2011 at 18:55 -0500, Philip Gladstone wrote:
=>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.

Yup, see section 9.1 of RFC 4408.

=>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 used a slight variation of the example in RFC 4408 section 9.1 which
has

exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d}

But mine is

exists:_l.%{l}._o.%{o}._h.%{h}._i.%{i}._spf.%{d}.

I like to be able to read from right to left as the SMTP transaction
took place. _i) IP address connected, _h) it HELO'd as, _o) used domain
name and _l) local-part address

One short coming to this is that you see the DNS query coming from the
DNS server that is being used by the receiving MTA and not the receiving
MTA's IP address. This is not really a big deal as I would think that
you are really interested in the sending IP address (%{i}) which is
logged.

=>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.

So far using the RFC 4408 section 9.1 example, I have been able to get
the feedback as a sender/postmaster that I need. I admit I have not
read the complete draft, but I am not sure what these additional
modifiers would gain over using the exists: modifier with macros.

--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************

-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110128114644:2F89EB96-2AFE-11E0-BA1F-C7E96A13C6EF
Powered by Listbox: http://www.listbox.com

Mailing List Archive

Attached Files:

Attached Files: