Mailing List Archive: Received-SPF extensions

Received-SPF extensions

Feb 24, 2007, 7:59 AM

Post #1 of 9 (6167 views)

Currently, pymilter adds up to 3 SPF headers:
2007Feb24 10:49:22 [4149] Received-SPF: none (mail.bmsi.com: 212.76.37.164
is neither permitted nor denied by domain of apachegrips.com)
client_ip=212.76.37.164; envelope_from="Poratoiyg@apachegrips.com";
helo=nat-go2.aster.pl; receiver=mail.bmsi.com; identity=mailfrom
2007Feb24 10:49:22 [4149] X-Hello-SPF: pass
2007Feb24 10:49:22 [4149] X-Guessed-SPF: neutral

The X-Guessed-SPF header exists because such heuristic results should
always be distinguished from the official SPF result. The X-Hello-SPF
header exists because adding two Received-SPF headers is cumbersome and
redundant (been there, done that).

Now, I'm thinking that X-Hello and X-Guessed should be extended keywords
on the Received-SPF, so that the above would become:

2007Feb24 10:49:22 [4149] Received-SPF: none (mail.bmsi.com: 212.76.37.164
is neither permitted nor denied by domain of apachegrips.com)
client_ip=212.76.37.164; envelope_from="Poratoiyg@apachegrips.com";
helo=nat-go2.aster.pl; receiver=mail.bmsi.com; identity=mailfrom;
x-hello=pass; x-guessed=neutral

Comments? Anyone already using similar keywords that I should be consistent
with?

--
Stuart D. Gathman <stuart@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 at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

scott at kitterman

Feb 24, 2007, 8:33 AM

Post #2 of 9 (6050 views)

Permalink

On Saturday 24 February 2007 10:59, Stuart D. Gathman wrote:
> Currently, pymilter adds up to 3 SPF headers:
> 2007Feb24 10:49:22 [4149] Received-SPF: none (mail.bmsi.com: 212.76.37.164
> is neither permitted nor denied by domain of apachegrips.com)
> client_ip=212.76.37.164; envelope_from="Poratoiyg@apachegrips.com";
> helo=nat-go2.aster.pl; receiver=mail.bmsi.com; identity=mailfrom
> 2007Feb24 10:49:22 [4149] X-Hello-SPF: pass
> 2007Feb24 10:49:22 [4149] X-Guessed-SPF: neutral
>
> The X-Guessed-SPF header exists because such heuristic results should
> always be distinguished from the official SPF result. The X-Hello-SPF
> header exists because adding two Received-SPF headers is cumbersome and
> redundant (been there, done that).
>
> Now, I'm thinking that X-Hello and X-Guessed should be extended keywords
> on the Received-SPF, so that the above would become:
>
> 2007Feb24 10:49:22 [4149] Received-SPF: none (mail.bmsi.com: 212.76.37.164
> is neither permitted nor denied by domain of apachegrips.com)
> client_ip=212.76.37.164; envelope_from="Poratoiyg@apachegrips.com";
> helo=nat-go2.aster.pl; receiver=mail.bmsi.com; identity=mailfrom;
> x-hello=pass; x-guessed=neutral
>
> Comments? Anyone already using similar keywords that I should be
> consistent with?

From an RFC 4408 SPF perspective you do have two SPF results. One for Mail
From and one for HELO, so I would think that two headers would be
appropriate. Why are you against them?

The forthcoming SpamAssassin 3.2 has a change that will use Received-SPF if it
was added by a trusted relay. I'd suggest looking at what they did and
producing a result that they will use (that's the only automated consumer of
Receieved-SPF that I am aware of that's likely to be widely deployed in the
near term).

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5239

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

stuart at bmsi

Feb 24, 2007, 4:04 PM

Post #3 of 9 (6045 views)

Permalink

On Sat, 24 Feb 2007, Scott Kitterman wrote:

> From an RFC 4408 SPF perspective you do have two SPF results. One for Mail
> From and one for HELO, so I would think that two headers would be
> appropriate. Why are you against them?

That's what I thought at first. But most of the HELO Received-SPF header field
is redundant, and having both is confusing for those humans looking at
the mail header. I am not *against* having both, and maybe I'll have an
option to report HELO SPF results in a second Received-SPF header. But
I dislike the redundancy for aesthetic reasons.

Also, when reputation code is processing Received-SPF headers from a
trusted relay/forwarder to find who to blame for the email, one-stop
shopping is cleaner.

> was added by a trusted relay. I'd suggest looking at what they did and
> producing a result that they will use (that's the only automated consumer of
> Receieved-SPF that I am aware of that's likely to be widely deployed in the
> near term).

Thanks for the vote of confidence :-) I would *hope* that they consume
the standard keywords (and I won't bother catering to any renaming of the
standard ones). Spfmilter.py should probably produce the two headers,
rather than put helo result in an extended keyword.

But do they have the equivalent of a heuristic result? And is my name
ok? Or do you prefer another name?

--
Stuart D. Gathman <stuart@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 at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

julian at mehnle

Feb 24, 2007, 6:08 PM

Post #4 of 9 (6062 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Sat, 24 Feb 2007, Scott Kitterman wrote:
> > From an RFC 4408 SPF perspective you do have two SPF results. One for
> > Mail From and one for HELO, so I would think that two headers would be
> > appropriate. Why are you against them?
>
> That's what I thought at first. But most of the HELO Received-SPF
> header field is redundant, and having both is confusing for those humans
> looking at the mail header. I am not *against* having both, and maybe
> I'll have an option to report HELO SPF results in a second Received-SPF
> header. But I dislike the redundancy for aesthetic reasons.
>
> Also, when reputation code is processing Received-SPF headers from a
> trusted relay/forwarder to find who to blame for the email, one-stop
> shopping is cleaner.

The long term solution is a properly designed "Authentication-Results:"
header that covers multiple authentication methods and results in a single
instance. I still have contacting the "A-R:" people on my SPF TODO list
but haven't managed to do so yet. :-/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4O+HwL7PKlBZWjsRAuc4AKCjSIUDhAr/DbLxeDOUpuk4W7XaiQCdGuj4
7imXPp1E1/EmgbTE+AZpBkc=
=P8E/
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

nobody at xyzzy

Feb 25, 2007, 12:41 AM

Post #5 of 9 (6048 views)

Permalink

Stuart D. Gathman wrote:

> most of the HELO Received-SPF header field is redundant, and having both
> is confusing for those humans looking at the mail header. I am not
> *against* having both, and maybe I'll have an option to report HELO SPF
> results in a second Received-SPF header. But I dislike the redundancy
> for aesthetic reasons.

Maybe limit Received-SPF for HELO identities to "interesting" results (?)

> Also, when reputation code is processing Received-SPF headers from a
> trusted relay/forwarder to find who to blame for the email, one-stop
> shopping is cleaner.

If a trusted HELO PASS is the reason to skip further MAIL FROM checks
you have only one SPF result, that would be clean / clear.

> And is my name ok? Or do you prefer another name?

IMO anything X-guessed in a standard Received-SPF is dangerous. Nothing's
wrong with guessing, but please make sure that it can't be confused with a
standard SPF result. By humans or by SA bots... ;-)

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

nobody at xyzzy

Feb 25, 2007, 12:46 AM

Post #6 of 9 (6047 views)

Permalink

Julian Mehnle wrote:

> I still have contacting the "A-R:" people on my SPF TODO list but
> haven't managed to do so yet. :-/

"A-R" is an optional work item for the DKIM WG after they're ready
with SSP and an overview document, adjusted milestone November 2007.

JFTR, do you all know that DKIM base is now an approved PS waiting
for its number, and Domainkeys is an approved historic RFC waiting
for its number ?

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

julian at mehnle

Feb 25, 2007, 3:24 AM

Post #7 of 9 (6062 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > I still have contacting the "A-R:" people on my SPF TODO list but
> > haven't managed to do so yet. :-/
>
> "A-R" is an optional work item for the DKIM WG after they're ready
> with SSP and an overview document, adjusted milestone November 2007.
>
> JFTR, do you all know that DKIM base is now an approved PS waiting
> for its number, and Domainkeys is an approved historic RFC waiting
> for its number ?

Good to know.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4XHZwL7PKlBZWjsRAuyrAKCWklPKSMf1e0N71VpIxZRrTUp1mgCfd6hY
3V9p9C4taBrmt8b1tdXgzp4=
=VO63
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Re: Received-SPF extensions [ In reply to ]

stuart at bmsi

Feb 25, 2007, 8:13 PM

Post #8 of 9 (6045 views)

Permalink

On Sun, 25 Feb 2007, Frank Ellermann wrote:

> IMO anything X-guessed in a standard Received-SPF is dangerous. Nothing's
> wrong with guessing, but please make sure that it can't be confused with a
> standard SPF result. By humans or by SA bots... ;-)

The standard SPF result goes in the standard place. Humans and robots
will have no problem (robots because they won't even look at keywords they
don't recognize). Idiots, on the other hand ...

--
Stuart D. Gathman <stuart@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 at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Re: Received-SPF extensions [ In reply to ]

scott at kitterman

Feb 26, 2007, 8:01 AM

Post #9 of 9 (6042 views)

Permalink

On Saturday 24 February 2007 19:04, Stuart D. Gathman wrote:
> On Sat, 24 Feb 2007, Scott Kitterman wrote:

> > was added by a trusted relay. I'd suggest looking at what they did and
> > producing a result that they will use (that's the only automated consumer
> > of Receieved-SPF that I am aware of that's likely to be widely deployed
> > in the near term).
>
> Thanks for the vote of confidence :-) I would *hope* that they consume
> the standard keywords (and I won't bother catering to any renaming of the
> standard ones). Spfmilter.py should probably produce the two headers,
> rather than put helo result in an extended keyword.
>
> But do they have the equivalent of a heuristic result? And is my name
> ok? Or do you prefer another name?

This is their SVN commit where they added it:

http://tinyurl.com/yrg7rq

They have rules that give scores. They have separate rules for Mail From and
HELO results, so I believe that separate headers with both results would be
useful.

I've got no strong opinion on the names, except that I think you ought to
include the second header for HELO results rather than make up a new one.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735