headers
spf-discuss | 2 Dec 2007 06:00
Favicon

SPF Mail Summary Report

                    iMail News Gateway Server v3.1                    
          (c) Copyright 1996-2005 Santronics Software, Inc.           

                        Mail Forum Statistics                         
                Date Range : 25 Nov 2007 - 30 Nov 2007
                Report Date: 02 Dec 2007

----------------------------------------------------------------------
Total Summary:
----------------------------------------------------------------------

Total Forums          : 2
Total Messages        : 38
Total Participants    : 21
Total Vendor Postings : 0
Total Mail/No Replies : 10  (26%)
          6+ Days Old : 4    4+ Days Old: 1
          2+ Days Old : 4    1 Day Old  : 1
Busiest Posting Hour  : 0am  (4 msgs)
Busiest Posting Day   : Wednesday  (10 msgs)

+-[ Hourly Posting Pattern ]----------------------+
| *                   * *     *       *           |
| *                   * *     *       *           |
| *                   * *     *       *           |
| *                   * *     *       *           |
| *                   * *     *       *           |
| *         *     *   * *     * *     *     *   * |
| *         *     *   * *     * *     *     *   * |
| *         *     *   * *     * *     *     *   * |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 3 Dec 2007 03:06
Picon
Picon

Re: spf2.0/mfrom

Julian Mehnle wrote:

> I am having serious trouble understanding what you are trying
> to say here.  Can you please reword your thoughts in a more 
> direct manner?

Wrt to a _given_ spf2.0/mfrom there are four cases:

1 - Only spf2.0/mfrom, no PRA, no v=spf1
2 - sf2.0/mfrom,pra (or v.v.), no v=spf1
3 - Any kind of spf2.0/mfrom, and v=spf1 matches it
4 - Any kind of spf2.0/mfrom, and v=spf1 different

Three additional cases without any spf2.0/mfrom:

5 - v=spf1, no PRA
6 - v=spf1 and spf2.0/pra
7 - Only PRA

Your statistics divides (1+2+3+4) / (1+2+3+4+5+6+7).

We're not interested in 7 (only PRA) for a comparison
of the spf2.0/mfrom and v=spf1 deployment.  

If we're looking for trouble, that's any mfrom without
a matching v=spf1, (1+2+4) / (1+2+3+4).

Unfortunately I had no time this week to work on the
op=pra draft, I intend to deprecate it together with
any spf2.0/mfrom leaving only v=spf1 and spf2.0/pra.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Mehnle | 3 Dec 2007 22:44
Gravatar

Possible other RFC 4408 erratum (2.5.7): PermError due to macro expansion?


Julian Mehnle wrote:
> > > As for real implementation behavior, Mail::SPF currently treats
> > > "a:foo..bar" as a simple mismatch.
> >
> > Wait a moment, I was talking about <target-name> foo..bar, are you
> > talking about a <directive> a:foo..bar ? Adjacent dots before the
> > macro expansion step directly written in a policy are a PermError,
> > aren't they ?
>
> I was talking about <target-name> = "foo..bar", but it's all the same,
> really.  "a:foo..bar" is not a syntax error.  In any case, according to
> RFC 4408, a PermError should not be thrown for that reason.

Uhmmmm, it just occurred to me that RFC 4408, 2.5.7[1] makes the following 
disturbing statement:

| Be aware that if the domain owner uses macros (Section 8), it is
| possible that this [PermError] result is due to the checked identities
| having an unexpected format.

This implies that "a:%{h}" with HELO = "1.2.3.4" COULD be considered to 
justify a PermError result.  However, I think we better make an erratum 
out of this, since there's probably not a single SPF implementation on 
earth that actually performs another syntax check after macro expansion.

Comments?

References:
 1. http://www.openspf.org/RFC_4408#op-result-permerror
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Gladstone | 5 Dec 2007 05:20

SPF Implementation issues

Can I get a test case added to the SPF test suite that deals with the
problematic situation in my SPF record.

In particular I have the following piece:

	-exists:%{i}.%{l1r-}.user.%{d}

In practice the %{l1r-} causes problems for some implementations -- I
can see from my DNS logs that they map a local part of 'philip' into
'hilip'. This is wrong.  [This piece of SPF is actually quite effective
at eliminating spammers who guess incorrect userids in my domain]

This bug exists at at least two distinct sites (both of which are mail
forwarding sites handling personal domains) so I suspect that there is a
common implementation with this as a defect.

Thanks

Philip

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959934&id_secret=72152438-fb3546
Powered by Listbox: http://www.listbox.com
Attachment (smime.p7s): application/x-pkcs7-signature, 3389 bytes
Permalink | Reply | 1 comment |
headers
Julian Mehnle | 6 Dec 2007 12:44
Gravatar

Re: SPF Implementation issues


Philip Gladstone wrote:
> Can I get a test case added to the SPF test suite that deals with the
> problematic situation in my SPF record.
>
> In particular I have the following piece:
>
> 	-exists:%{i}.%{l1r-}.user.%{d}
>
> In practice the %{l1r-} causes problems for some implementations -- I
> can see from my DNS logs that they map a local part of 'philip' into
> 'hilip'. This is wrong.  [This piece of SPF is actually quite effective
> at eliminating spammers who guess incorrect userids in my domain]
>
> This bug exists at at least two distinct sites (both of which are mail
> forwarding sites handling personal domains) so I suspect that there is
> a common implementation with this as a defect.

We can add a test case to the test suite easily, however trying to 
identify the MTA software running on those broken sites may of more 
immediate use.  Maybe we can guess the SPF implementations used by them 
and try to get them fixed directly?

What MTAs are they running?  Does their SMTP signature (e.g. the welcome 
message) give any hints?

Julian.
Permalink | Reply | 0 comments |
headers
Scott Kitterman | 6 Dec 2007 15:30

Re: Re: SPF Implementation issues

On Thursday 06 December 2007 06:44, Julian Mehnle wrote:
> Philip Gladstone wrote:
> > Can I get a test case added to the SPF test suite that deals with the
> > problematic situation in my SPF record.
> >
> > In particular I have the following piece:
> >
> > 	-exists:%{i}.%{l1r-}.user.%{d}
> >
> > In practice the %{l1r-} causes problems for some implementations -- I
> > can see from my DNS logs that they map a local part of 'philip' into
> > 'hilip'. This is wrong.  [This piece of SPF is actually quite effective
> > at eliminating spammers who guess incorrect userids in my domain]
> >
> > This bug exists at at least two distinct sites (both of which are mail
> > forwarding sites handling personal domains) so I suspect that there is
> > a common implementation with this as a defect.
>
> We can add a test case to the test suite easily, however trying to
> identify the MTA software running on those broken sites may of more
> immediate use.  Maybe we can guess the SPF implementations used by them
> and try to get them fixed directly?
>
> What MTAs are they running?  Does their SMTP signature (e.g. the welcome
> message) give any hints?
>
I do find that Philip's record is a good one for catching implementation 
errors.  When I first implemented my web validator in 2005, Philip pointed me 
at issues in his record (including IIRC this macro expansion) that resulted 
in me fixing a number of things in pyspf.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Mehnle | 6 Dec 2007 17:50
Gravatar

Upcoming new test-suite release -- please review! (was: SPF Implementation issues)


Julian Mehnle wrote:
> Philip Gladstone wrote:
> > Can I get a test case added to the SPF test suite that deals with the
> > problematic situation in my SPF record.
> >
> > In particular I have the following piece:
> >
> > 	-exists:%{i}.%{l1r-}.user.%{d}
> > 
> > [...]
>
> We can add a test case to the test suite easily [...]

I added it in revision 94 of the test-suite trunk:

  http://www.openspf.org/source/project/test-suite/rfc4408-tests.yml?view=log

If no one objects, I'll make a new test-suite release of those and
Stuart's changes in a week or so.
Permalink | Reply | 0 comments |
headers
Stuart D. Gathman | 6 Dec 2007 19:11

Re: Upcoming new test-suite release -- please review! (was: SPF Implementation issues)

On Thu, 6 Dec 2007, Julian Mehnle wrote:

> I added it in revision 94 of the test-suite trunk:
> 
>   http://www.openspf.org/source/project/test-suite/rfc4408-tests.yml?view=log
> 
> If no one objects, I'll make a new test-suite release of those and
> Stuart's changes in a week or so.

+  e14.example.com:
+    - SPF: v=spf1 a:example..com

There was already a test for this: invalid-domain-empty-label.  It currently
allows for either ignoring the empty label, or permerror.  If there is an
official errata requiring nomatch instead of permerror, then simply change
the result set of the existing test.  Or were you concerned about
2 adjacent dots vs 3?

+  e5a.example.com:
+    - SPF: v=spf1 a:museum

This seems to be not redundant.  However, it seems unintuitive to me that 
example..com must be ignored, but museum gets a permerr.

+  e11.example.com:
+    - SPF: v=spf1 exists:%{i}.%{l2r-}.user.%{d2}
+  1.2.3.4.gladstone.philip.user.example.com:
+    - A: 127.0.0.2

Good, but the actual failing example in the field used %{l1r-}.  Shouldn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart D. Gathman | 6 Dec 2007 19:42

Re: Upcoming new test-suite release -- please review! (was: SPF Implementation issues)

On Thu, 6 Dec 2007, Stuart D. Gathman wrote:

> +  e5a.example.com:
> +    - SPF: v=spf1 a:museum
> 
> This seems to be not redundant.  However, it seems unintuitive to me that 
> example..com must be ignored, but museum gets a permerr.

How about this case:

Result: pass ?

e5b.example.com:
  - SPF: v=spf1 a:museum.

--

-- 
	      Stuart D. Gathman <stuart <at> bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=73253028-744825
Powered by Listbox: http://www.listbox.com
Permalink | Reply | 0 comments |
headers
Stuart D. Gathman | 6 Dec 2007 20:00

Re: [spf-discuss] Re: Upcoming new test-suite release -- please review! (was: SPF Implementation issues)

On Thu, 6 Dec 2007, Stuart D. Gathman wrote:

> On Thu, 6 Dec 2007, Stuart D. Gathman wrote:
> 
> > +  e5a.example.com:
> > +    - SPF: v=spf1 a:museum
> > 
> > This seems to be not redundant.  However, it seems unintuitive to me that 
> > example..com must be ignored, but museum gets a permerr.
> 
> How about this case:
> 
> Result: pass ?
> 
> e5b.example.com:
>   - SPF: v=spf1 a:museum.

Forgot A record:

museum:
  - A:1.2.3.4

But without A record, should it get neutral instead of permerror?

--

-- 
	      Stuart D. Gathman <stuart <at> bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane