SPF Feature Request

We're only rejecting on hard fail (-all). If you have observed otherwise, please post the domain name that this happened with.

Thanks!

v=spf1 ip4:198.22.123.0/24 mx ~all

indicates a “soft-fail” for email from

           RewardZoneCerts.BestBuy.com (206.132.3.45)

The transaction from the SMTP log demonstrates that this was a forwarded email and that the Astaro picked up the IP of the forwarder instead of the originator.  Still, BestBuy's spf is a soft-fail.

2008:09:03-16:30:36 (none) exim[4175]: 2008-09-03 16:30:36 SMTP connection from [69.89.22.20]:45941 (TCP/IP connection count = 1)
2008:09:03-16:30:37 (none) exim[19701]: 2008-09-03 16:30:37 H=outbound-mail-81.bluehost.com [69.89.22.20]:45941 Warning: mediasoftusa.com profile excludes greylisting: Skipping greylisting for this message
2008:09:03-16:30:37 (none) exim[19701]: 2008-09-03 16:30:37 [69.89.22.20] F= R= Verifying recipient address with callout
2008:09:03-16:30:37 (none) exim[19701]: 2008-09-03 16:30:37 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="69.89.22.20" from="BestBuyRewardZone%40RewardZoneCerts.BestBuy.com" to="balfson%40mediasoftusa.com" size="-1" reason="spf" extra="SPF check failed"
2008:09:03-16:30:37 (none) exim[19701]: 2008-09-03 16:30:37 H=outbound-mail-81.bluehost.com [69.89.22.20]:45941 F= rejected RCPT : 69.89.22.20 is not allowed to send mail from RewardZoneCerts.BestBuy.com
2008:09:03-16:30:37 (none) exim[19701]: 2008-09-03 16:30:37 SMTP connection from outbound-mail-81.bluehost.com [69.89.22.20]:45941 closed by DROP in ACL

v=spf1 ip4:198.22.123.0/24 mx ~all

indicates a “soft-fail” for email from

           RewardZoneCerts.BestBuy.com (206.132.3.45)

I get a different record:

whizbang ~ # host -t txt RewardZoneCerts.BestBuy.com
RewardZoneCerts.BestBuy.com descriptive text "v=spf1 include:bfi0.com include:bigfootinteractive.com -all"

This one has "-all". Maybe their nameservers are inconsistent.

Granted, Tom, but the Astaro failed the SPF based on the wrong address!

I just checked for both RewardZoneCerts.BestBuy.com and BestBuy.com, and I got the same one I did yesterday.

Granted, Tom, but the Astaro failed the SPF based on the wrong address!

I just checked for both RewardZoneCerts.BestBuy.com and BestBuy.com, and I got the same one I did yesterday.

It failed for the envelope sender address domain, which is "RewardZoneCerts.BestBuy.com", which in turn has a TXT record terminated with "-all".

Bestbuy.com does have a "~all"-terminated record, but the message didn't come from there ...

I can confirm that our Astaro units are working as Tom describes... sounds like something outside the box is going wrong (the nameservers may be getting tinkered with out there)...

I'm sorry that I'm not being clear about the Astaro error.

The above email was sent to a personal address, Bob@Alfson.org, which is hosted on Bluehost.com servers.  The address the Astaro chose to compare, 69.89.22.20, is the bluehost server that forwarded the message to BAlfson@MediaSoftUSA.com.

The Astaro failed to find 206.132.3.137 (explicitly allowed by the SPF you found), which appears in the header below which I extracted from the original email received by Bob@Alfson.org:

Return-path: 
Envelope-to: bob@alfson.org
Delivery-date: Thu, 04 Sep 2008 01:25:58 -0600
Received: from mediasof by box44.bluehost.com with local-bsmtp (Exim 4.69)
(envelope-from )
id 1Kb9Dy-0007t7-1B
for bob@alfson.org; Thu, 04 Sep 2008 01:25:58 -0600
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on box44.bluehost.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham version=3.2.4
Received: from arm137.bigfootinteractive.com ([206.132.3.137] helo=bigfootinteractive.com)
by box44.bluehost.com with smtp (Exim 4.69)
(envelope-from )
id 1Kb9Dx-0007sq-Kd
for bob@alfson.org; Thu, 04 Sep 2008 01:25:49 -0600
Reply-To: BestBuyRewardZone.W0TH05331327D80DC72E328A9756C1@RewardZoneCerts.BestBuy.com
Bounces_to: BestBuyRewardZone@RewardZoneCerts.BestBuy.com
Message-ID: 
X-BFI: W0TH05331327D80DC72E328A9756C1
Date: Thu, 04 Sep 2008 02:34:06 EDT
From: Best Buy Reward Zone 
Subject: Reward Zone program Premier Black
To: bob@alfson.org
MIME-Version: 1.0
Content-Type: multipart/alternative;
  boundary="ABCD-W0TH05331327D80DC72E328A9756C1-EFGH"
X-user: ::::206.132.3.137:box44.bluehost.com::::::
X-user-local: {940:box44.bluehost.com:mediasof:mediasoftusa.com} {sentby[:P]rogram running on server}

Here's the header from an email received by BAlfson@MediaSoftUSA.com that was sent from BAlfson@MediaSoftUSA.com to Bob@Alfson.org and automatically forwarded:

Microsoft Mail Internet Headers Version 2.0
Received: from mail.MediaSoftUSA.com ([10.1.1.34]) by mediasoftusa.com with Microsoft SMTPSVC(6.0.3790.3959);
 Fri, 5 Sep 2008 17:26:22 -0500
Received: from [69.89.21.2] (port=36380 helo=forwardproxy4.bluehost.com)
by mail.MediaSoftUSA.com with smtp (Exim 4.69)
(envelope-from )
id 1Kbjlc-0008Jb-0N
for balfson@mediasoftusa.com
CTCH-RefID str=0001.0A010205.48C1B234.00E2,ss=1,fgs=0; Fri, 05 Sep 2008 17:27:00 -0500
Received: (qmail 16583 invoked by uid 0); 5 Sep 2008 22:03:22 -0000
Received: from unknown (HELO box44.bluehost.com) (69.89.20.44)
  by forwardproxy4.bluehost.com with SMTP; 5 Sep 2008 22:03:22 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=mediasoftusa.com;
h=Received:X-Spam-Checker-Version:X-Spam-Level:X-Spam-Status:Received:Received:From:To:Subject[:D]ate:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Importance:Thread-Index:X-MimeOLE:X-OriginalArrivalTime:X-user:X-user-local;
b=jDtdqT5pCneAswC0kthFpnrMLECBwWBdN25Ov81cmZYQRmNxfHPg9b5gomoOn8upLAzWLiohRy0IE88+Q2KhJTmQlE4vXXOfO99vXt62RcbeSpJXt8u+j6N8jnvvxPUL;
Received: from mediasof by box44.bluehost.com with local-bsmtp (Exim 4.69)
(envelope-from )
id 1KbjlP-0007OR-K5
for Bob@alfson.org; Fri, 05 Sep 2008 16:26:52 -0600
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on box44.bluehost.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham version=3.2.4
Received: from mail.mediasoftusa.com ([68.15.104.33] helo=mediasoftusa.com)
by box44.bluehost.com with esmtp (Exim 4.69)
(envelope-from )
id 1KbjlP-0007OD-AX
for Bob@alfson.org; Fri, 05 Sep 2008 16:26:47 -0600
Received: from BobDeskTop ([10.1.1.64]) by mediasoftusa.com with Microsoft SMTPSVC(6.0.3790.3959);
 Fri, 5 Sep 2008 17:26:04 -0500
From: "Bob Alfson" 
To: 
Subject: testing the Bluehost forward for Astaro
Date: Fri, 5 Sep 2008 17:25:44 -0500
Message-ID: 
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Importance: Normal
Thread-Index: AckPplYe4fbSO7IPSuWHULx+Ennrzw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-OriginalArrivalTime: 05 Sep 2008 22:26:04.0713 (UTC) FILETIME=[626DF190:01C90FA6]
X-user: ::::68.15.104.33:box44.bluehost.com::::::
X-user-local: {940:box44.bluehost.com:mediasof:mediasoftusa.com} {sentby[:P]rogram running on server}
Content-type: multipart/mixed; boundary="----------=_1220653630-31970-0"
Return-Path: balfson@mediasoftusa.com

------------=_1220653630-31970-0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0026_01C90F7C.6DA570D0"

------=_NextPart_000_0026_01C90F7C.6DA570D0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

------=_NextPart_000_0026_01C90F7C.6DA570D0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_000_0026_01C90F7C.6DA570D0--
------------=_1220653630-31970-0
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)


------------=_1220653630-31970-0--

Message "Received:" headers are outside the scope of SPF. An implementation must not go fishing for IP addresses in those headers, because they can be easily forged.

Some implementations may evaluate the last received header (or the first such header added by a trusted host) as an exception, but that is already quite hackish.

So, you are saying this is not an Astaro error, but a limitation/feature of SPF. And, further, the implication would be that the burden for addressing this issue falls on the service that forwards the email.

However, according to openspf.org:

"Checking SPF On Forwarded Mail
"Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) is the forwarder's mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem."

In the example I supplied earlier in this thread, there is no way to tell the Astaro not to reject mail forwarded from a specific IP, domain like alfson.org or email like Bob@Alfson.org.  I would have to list each individual, original sender like RewardZoneCerts.BestBuy.com - that seems impractical.

So, while this might not, technically, be an Astaro error, it does render the Astaro implemtation of SPF unusable for many organizations.

So, you are saying this is not an Astaro error, but a limitation/feature of SPF. And, further, the implication would be that the burden for addressing this issue falls on the service that forwards the email.

However, according to openspf.org:

"Checking SPF On Forwarded Mail
"Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) is the forwarder's mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem."

SPF is broken by design, mostly because it leaves the forwarding problem unresolved (except by proposing stupid solutions like keeping a list of "authorized forwarders" - you won't know who of your users forwards his other email addresses). 

You can read http://david.woodhou.se/why-not-spf.html for a larger rant.

In the example I supplied earlier in this thread, there is no way to tell the Astaro not to reject mail forwarded from a specific IP, domain like alfson.org or email like Bob@Alfson.org.

You can use exceptions.

I would have to list each individual, original sender like RewardZoneCerts.BestBuy.com - that seems impractical.

You can whitelist "authorized forwarders" instead - that is exactly what the SPF designers want you to do! [:)]

So, while this might not, technically, be an Astaro error, it does render the Astaro implemtation of SPF unusable for many organizations.

SPF is unuseable in itself - our implementation is partly sane by ONLY rejecting on hard fail, assuming the senders know about SPF shortfalls and so agree to the consequences.

Tom's dead-on with his assessment here; SPF definitely has its flaws.

Tom's dead-on with his assessment here; SPF definitely has its flaws.

I certainly am less-knowledgeable than either of you guys, so I appreciate the interaction.

I'm sorry that I didn't understand where in the V7.3 SMTP Proxy one could whitelist "authorized forwarders" as opposed to original senders.  Now I understand that you meant something like the following:



So, it would appear that a best practice prior to activating spf would be to request that mail users of the Astaro-protected mail server inform the domain postmaster of any email addresses they have forwarded - correct?

Thanks - Bob

Thats right - but the rate of SPF rejects is hardly worth the hassle [:)]

Agreed.  That's one of the great things about 7.3 - the number of rejects for each test is explicit and easy to see.  The SPF check might reduce some of the load on the Astaro, but I'd guess that it's minimal since SPF-rejects account for much less than 1% of rejects.  It seems probable that anything that would fail an spf test also would fail some other tests.

I think I'll turn it off for three different installations and see if there's any reduction in the net number of rejects.  I assume this check happens after the RBL check but before all others - is that correct?

Thanks - Bob

No one noticed any more spam and none of the Astaros had any increase in CPU utilization.  My conclusion is that Astaro needs to offer SPF-checking for marketing reasons, but that SPF should not be used.

Cheers - Bob