On Sun, 2005-06-26 at 13:06 +0200, Jean-Pierre Schwickerath wrote:

...

Ignore it and if a hotmail customer complains to you, tell them their hotmail SPAM filter is busted and you can not do anything against it. The hotmail users should start yelling at Microsoft and not at anybody else.

<shifting the message around a bit>

With AOL and now Microsoft (counting only the really big ones)

adopting

SPF I see a real chance for this technology to be successfully used.

There is a 'small' problem with this. AOL uses SPFv1, while Microsoft is pushing "SPFv2", which is not really SPFv2, but their own version of the thing which clashes with the real SPFv1 (openspf.org one) also called classic and that is the one people have been deploying the last 2 years, not the one with the PRA checks.

The problem here is that Mickeysofts version of SPF breaks all SPFv1 installations....

The IESG has apparently given both drafts (SPFv1 + Sender-ID/SPFv2) the chance to go to experimental RFC.

I wouldn't see it so bad. First, they'll start in november which leaves some time to the rest of the world to adapt to the situation. Second, I think it's a good point to promote SPF ( I know we already hat the discussion about whether SPF is good or bad ). Third, it seems as if the message will only be tagged as spam and not deleted or rejected. It's like giving spamassassin a high score for SPF.

loadplugin Mail::SpamAssassin::Plugin::SPF

Default on debian: /usr/share/spamassassin/25_spf.cf | handsnipper 8<------------------------- # SPF support. "pass" is nice, "fail" is bad, "softfail" is bad, but # not as bad as "fail". ;) These are more trustworthy results than # the SPF_HELO rules.

header SPF_PASS eval:check_for_spf_pass() header SPF_FAIL eval:check_for_spf_fail() header SPF_SOFTFAIL eval:check_for_spf_softfail()

describe SPF_PASS SPF: sender matches SPF record describe SPF_FAIL SPF: sender does not match SPF record (fail) describe SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) describe SPF_HELO_PASS SPF: HELO matches SPF record describe SPF_HELO_FAIL SPF: HELO does not match SPF record (fail) describe SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record (softfail) ------------------------>8

/usr/share/spamassassin/50_scores.cf | handsnipper 8<------------------------------------------ # SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's # likely that more spammers would quickly move to setting valid SPF records # otherwise. The penalties for an *incorrect* record, however, are large. ;) ifplugin Mail::SpamAssassin::Plugin::SPF score SPF_PASS -0.001 score SPF_FAIL 0 0.001 0 0.875 score SPF_SOFTFAIL 0.500 0.842 0.500 0.500 score SPF_HELO_PASS -0.001 score SPF_HELO_FAIL 0 0.405 0 0.001 score SPF_HELO_SOFTFAIL 0 1.002 0 3.140 endif # Mail::SpamAssassin::Plugin::SPF ------------------------------------------->8

Don't forget to install the Mail:SPF perl stuff and friends.

That said, I *want* to install SPFv1 records, but I am seeing it break in several of the sources where I get my mail from. For instance for the above I had to set trusted_forwarders to my upstream+secondary MX's as those boxes are not in the SPF rule of their respective domains and thus it breaks add to that quite a number of other issues, thus I hold it back for a while, in the mean time, I'll just PGP sign my stuff :)

Greets, Jeroen

On Sun, 2005-06-26 at 15:52 +0200, Beat Rubischon wrote:

Hello!

Am 26.06.05 schrieb Jeroen Massar:

...

There is a 'small' problem with this. AOL uses SPFv1, while Microsoft is pushing "SPFv2", which is not really SPFv2, but their own version of the thing which clashes with the real SPFv1 (openspf.org one) also called classic and that is the one people have been deploying the last 2 years, not the one with the PRA checks.

I'm still looking for a deeper explanation. The one I found at Microsoft [1] exactly explains SPF as I know and the wizard [2] creates the same records as the wizard on spf.pobox.com.

spf.pobox.com is *VERY* out of date and actually has not much to do with the classic SPFv1. The promote SenderID there and that is something that the SPF folks don't want to see, they are currently trying to decide on a site name and will the finally fix up the site, currently check:

http://www.mail-spf.org/

Which has quite some up-to-date info.

[1] http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx [2] http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx

Do you have more information?

The spf-discuss list, but that one is a bit long and I guess some others might want to have an explanation too, (even those 5 folks who are on vacation and sending vacation notices when they receive mail on a bloody technical mailinglist....)

Read: http://www.openspf.org/OpenSPF_community_position_v101.html

Some nice URL's to read: http://www.apache.org/foundation/docs/sender-id-position.htm AOL backs away from Microsoft antispam plan http://www.computerworld.com/softwaretopics/software/groupware/story/0,10801...

Greets, Jeroen

Hi

I'm still looking for a deeper explanation. The one I found at Microsoft [1] exactly explains SPF as I know and the wizard [2] creates the same records as the wizard on spf.pobox.com.

[1] http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx [2] http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx

Do you have more information?

This documents were very short and summarized Sender-ID very well:

"Sender ID Framework Executive Overview"

http://www.microsoft.com/downloads/details.aspx?FamilyId=F23A8DDD-F4DD-4419-...

"Sender ID Framework Deployment Overview"

http://www.microsoft.com/downloads/details.aspx?familyid=8958AB23-F350-40FE-...

The Sender ID Framework (SIDF) is the name of the product, not the technology. SIDF uses SPF records and solves some of the problems with forwarding mails and stuff by introducing new mail headers and a new command in the SMTP transaction, which allows you to do all the funky SPF detection stuff even before DATA. Read more on this here:

"Sender Policy Framework: Authorizing Use of Domains in Mail From"

http://www.microsoft.com/downloads/details.aspx?familyid=d8a174b1-697c-4aea-...

They have also introduced something called the PRA (Purported Responsible Address) or PRD (Purported Responsible Domain) which basically means "where did the mail come from?" or more technically: does the "From" header (and a couple of other mail headers, see spec) match the server the mail came from? And here is the part which is incompatible with "Classic SPF". The records are the same, but while "Classic SPF" ONLY used them to check the envelope from ("Return-Path"), Sender ID uses the SAME records to check for "From". So the records are identical, but the interpretation is different and that can cause major headaches because in some cases it could work, in others not, depending on whether the receiving server interprets them as SPF or as Sender ID.

Here's a translation of purported, btw:

deutsch: http://dict.leo.org/?search=purported français: http://dict.leo.org/?lp=frde&search=behaupten

Coincidentially, I checked aol.com's SPF record today and I found this. I don't have the full "bigger picture" yet, but I believe these are Classic SPF records AND a Sender ID record - split up in two TXT records:

$ dig +short txt aol.com

"spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

Note that you don't have to pay anything to use Sender-ID. Microsoft allows anyone to use Sender-ID for free (how generous!), in some cases you need to obtain a licence, tough. While this is free as in beer, it is not free as in speech and therefore it is incompatible with most open source licences:

Q5: Who needs to execute a license with Microsoft? A: It's important to note that the license is only relevant to those organisations (ISP, large enterprise) who will be CHECKING e-mails using the PRA check alternative of the Sender ID Framrwork need to secure a license. Those simply publishing their Sender ID records do not need this license.

Q7: Does Microsoft's patent licences require me to pay any fees or other royalties? A: No. There are no royalties or other fees associated with Micro- soft's patent license. [..]

from "Sender ID Framework and Intellectual Property Overview and FAQ"

http://www.microsoft.com/downloads/details.aspx?familyid=4b1c931a-57cf-40a4-...

You won't need to obtain any licences if you are only publishing SPF records and want to be compatible with Hotmail. You'll only have to if you use Sender ID technology to check Emails. And even then, it's going to be free.

Daniel

Hi

http://www.microsoft.com/downloads/details.aspx?FamilyId=8FE5AAF3-6E5B-478C-...

Reminds me: microsoft.com is definately not "Cool URI" compliant :)

http://www.w3.org/Provider/Style/URI.html

Daniel

Hello!

Am 28.06.05 schrieb Daniel Lorch:

...

Do you have more information?

This documents were very short and summarized Sender-ID very well:

...

Thanks for the links.

And here is the part which is incompatible with "Classic SPF". The records are the same, but while "Classic SPF" ONLY used them to check the envelope from ("Return-Path"), Sender ID uses the SAME records to check for "From".

I see. Classic mailsetups as I use for my private emails will work. My SPF-record should be working for both aproaches.

Complex mailsetups like the one from my employer "ethz.ch" will never ever be compatible with one or both solutions. A wildcard entry will be the solution if Hotmail will continue to follow Sender-Id...

Beat

There is a 'small' problem with this. AOL uses SPFv1, while Microsoft is pushing "SPFv2", which is not really SPFv2, but their own version of the thing which clashes with the real SPFv1 (openspf.org one) also called classic and that is the one people have been deploying the last 2 years, not the one with the PRA checks.

The problem here is that Mickeysofts version of SPF breaks all SPFv1 installations....

The IESG has apparently given both drafts (SPFv1 + Sender-ID/SPFv2) the chance to go to experimental RFC.

OK, maybe I talked to fast, or wrote without thinking too much. I completely oversaw the license issue and the fact that their sender ID stuff is breaking the currently used SPFv1.

I'll have to look deeper into the issue. Meanwhile I signed the openspf position.

Regards,

Jean-Pierre