SPF and Spamfilter |
Post Reply 
|
| Author | |
yapadu 
Senior Member 
Joined: 12 May 2005 Status: Offline Points: 297 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: SPF and SpamfilterPosted: 23 June 2010 at 8:35am |
|
I'm sure I am not the only one using spamfilter with this problem so here it is.
My customer (example.com) is hosted by godaddy. Customer is sent an email from americangreetings.com, passes all tests by our spamfilter implementation. We deliver email to the godaddy servers hosting emaple.com's email. They refuse it: 5.7.1 SPF unauthorized mail is prohibited. -- - forwarding to:smtp.secureserver.net:25 - will try forwarding to mailstore1.secureserver.net:25 Some customers simply can not disable SPF checking. I have disabled spam protection on email hosted by godaddy, but messages are still refused. Of course the man in the middle of the transaction (spamfilter) gets the blame, and we end up loosing the customer. I have read about Sender Rewriting Scheme, which would fix the problem but spamfilter does not have it. As it stands right now, no one can use our service if they can't totally shut off SPF checking. If implemented the SRS scheme would only be done on domains that actually publish SPF records. Since spamfilter is checking SPF records, it would know if rewriting was required or not when resending the email. The option to turn it on/off per domain at the spamfilter level would be nice as well since not everyone needs it. Does anyone know of another solution, or how the big guys handle this situation? Edited by yapadu - 23 June 2010 at 9:24am |
|
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
 |
|
|
yapadu
Senior Member
Joined: 12 May 2005 Status: Offline Points: 297 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 June 2010 at 9:30am |
|
I checked what one of the big guys does about this. In the control panel of their
spam protection system they have a section called SPF, which reads: If your mail server or server-based anti-spam software uses SPF, you should also enable SPF support in the control panel by selecting "YES" on this page. If you fail to do so, you run the risk of having any incoming message being sent by an SPF-publishing domain rejected by your mail server (since all messages will show the IP address of our spam filtering service, rather than the originating IP address of the sender). So, a bit of testing reveals that in fact they are doing SRS if you inform them that you check SFP records. Here is a test conducted with SRS turned off: In this case the message fails the SPF check. Delivered-To: user@bboy.com Received: by 10.231.205.195 with SMTP id fr3cs139870ibb; Wed, 23 Jun 2010 06:17:11 -0700 (PDT) Return-Path: <ecards@americangreetings.com> Received: from tex1-mh314.smtproutes.com (tex1-mh314.smtproutes.com [208.43.37.103]) by mx.google.com with ESMTP id my13si11857080qcb.45.2010.06.23.06.17.09; Wed, 23 Jun 2010 06:17:09 -0700 (PDT) Received-SPF: fail (google.com: domain of ecards@americangreetings.com does not designate 208.43.37.103 as permitted sender) client-ip=208.43.37.103; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of ecards@americangreetings.com does not designate 208.43.37.103 as permitted sender) smtp.mail=ecards@americangreetings.com; dkim=pass header.i=ecards@americangreetings.com X-Katharion-ID: 1277299004.39219.tex1-mh314 (0.2) Return-Path: <ecards@americangreetings.com> Received: from dc3-ironport5.americangreetings.com ([66.119.43.123]) by tex1-mh314.smtproutes.com [(10.8.245.24)] with ESMTP via TCP; 23 Jun 2010 08:16:44 -0500 Date: Wed, 23 Jun 2010 09:16:00 -0400 Message-Id: <1277298960.7895745313.18562@ag-web3.ops.ag.com> From: "Ecard from AmericanGreetings.com" <ecards@americangreetings.com> Reply-To: <rg@undp.org> To: <user@bboy.com> Subject: Test Test has sent you an ecard from AmericanGreetings.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Now here is a message from the same sender (americangreetings.com) with SRS enabled, and it passes the SPF check. Delivered-To: user@bboy.com Received: by 10.231.205.195 with SMTP id fr3cs139665ibb; Wed, 23 Jun 2010 06:10:44 -0700 (PDT) Return-Path: <SRS0+1277298610.77364.tex1-mh316=3830ebfcb4881797e59a464f87993ee13f5846ab=americangreetings.com=ecards@tex1-mh316.smtproutes.com> Received: from tex1-mh316.smtproutes.com (tex1-mh316.smtproutes.com [208.43.37.105]) by mx.google.com with ESMTP id 34si4145330ywh.31.2010.06.23.06.10.42; Wed, 23 Jun 2010 06:10:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of SRS0+1277298610.77364.tex1-mh316=3830ebfcb4881797e59a464f87993ee13f5846ab=americangreetings.com=ecards@tex1-mh316.smtproutes.com designates 208.43.37.105 as permitted sender) client-ip=208.43.37.105; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of SRS0+1277298610.77364.tex1-mh316=3830ebfcb4881797e59a464f87993ee13f5846ab=americangreetings.com=ecards@tex1-mh316.smtproutes.com designates 208.43.37.105 as permitted sender) smtp.mail=SRS0+1277298610.77364.tex1-mh316=3830ebfcb4881797e59a464f87993ee13f5846ab=americangreetings.com=ecards@tex1-mh316.smtproutes.com; dkim=pass header.i=ecards@americangreetings.com X-Katharion-ID: 1277298610.77364.tex1-mh316 (0.2) Return-Path: <SRS0+1277298610.77364.tex1-mh316=3830ebfcb4881797e59a464f87993ee13f5846ab=americangreetings.com=ecards@tex1-mh316.smtproutes.com> Received: from dc3-ironport6.americangreetings.com ([66.119.43.125]) by tex1-mh316.smtproutes.com [(10.8.245.28)] with ESMTP via TCP; 23 Jun 2010 08:10:10 -0500 Date: Wed, 23 Jun 2010 09:09:36 -0400 Message-Id: <1277298576.0550135654.7336@ag-web2.ops.ag.com> From: "Ecard from AmericanGreetings.com" <ecards@americangreetings.com> Reply-To: <rg@undp.org> To: <user@bboy.com> Subject: Test Test has sent you an ecard from AmericanGreetings.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 I've got my credit card ready, when SRS is released I will purchase another enterprise license. Anyone else feel the need for this? If your an ISP where you host all the domains this is not a big issue, but if you are relaying email to other servers this is necessary! |
|
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
|
|
|
LogSat
Admin Group 
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 24 June 2010 at 9:40am |
|
If you are performing spam filtering services for a customer, the customer's actual mail server should not be performing any additional IP-based spam checks, as the IP will be SpamFilter's server, not the actual sender. The IP checks do include the SPF tests - these should not be performed by the mail server. SRS was intended to be used in cases where the emails are *forwarded* to a different email address, for example an email from ecards@amerciangreetings.com originally sent to mike@mydomain.com is then forwarded by the SMTP server to mike@gmail.com. In this case, the recipient's domain has been changed, and SRS is used to handle that rewrite. In the case you described, if I understand correctly, the email is from ecards@amerciangreetings.com to mike@mydomain.com. This email is then forwarded by SpamFilter, as-is, to the same address - mike@mydomain.com, onto a different SMTP server. Here the destination email address is not rewritten, the email is simply delivered in the original format to a different SMTP server. In your example above, smtproutes.com "fakes" an intermediate address on their own domain, and pretend that that was the original recipient so that they can then use SRS to bypass the SPF test. Also please note that there are a few issues with implementing SRS. For example, in case the email can't be delivered and NDR bounce notifications are sent, the "man in the middle" server will receive a bounce, since that's the "faked" email address where they will be sent to. This man in the middle server (the spam server) will then need to process these emails and make sure the bounce is then in turn emailed back to the original sender. Another even more serious issue is that the original "Mail From" address is modified by SRS by adding several characters in the local part of the email address (the one before the "@" sign). Per RFC 2821, there is a 64-character limit on this. Adding the SRS signature could very easily cause this limit to be exceeded, and there are antispam devices out there that will block emails that violate this. Cisco MailGuard is notorious for this.
|
|
|
|
Topic Options|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.148 seconds.