Jump to content


Photo

Barracuda Hosted blocking incoming mail from Exchange 2013 - incorrect SPF

exchange spf

  • Please log in to reply
12 replies to this topic

#1 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 04 June 2015 - 09:35 PM

So, my Exchange 2013 server is sending mail happily to the whole world, except when a user is behind a Barracuda cloud email security service.  I have some details of a log entry sent to me by an administrator of one of the receiving systems protected by Barracuda hosted systems:

Received-SPF: fail (mx9.ess.sfj.cudaops.com: domain of <agency>.org does not designate ::1 as permitted sender)
Received: from <redacted>.local (10.5.10.11) by <redacted>.local (10.5.10.11) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 2 Jun 2015 15:59:30 -0400
Received: from <redacted>.local ([::1]) by <redacted>.local ([::1]) with mapi id 15.00.0847.030; Tue, 2 Jun 2015 15:59:30 -0400

So, if we look at the bottom, <redacted>.local originates email from [::1] - which is the localhost with IPv6.  Then it starts using IPv4 for the rest of the mail - moving through the private IPv4 for <redacted>.local and then out the public IP address.  The MTA in Exchange identifies the EHLO with mail.<agency>.org.  which is identified as the primary MX record for <agency>.org  My SPF record reads: 

v=spf1 mx a include:constantcontact.com -all

So, why for the love of all that is holy and good in this world, is the Barracuda system at all concerned with the IPv6 originating address in the header?  It just stops there.  In other email systems, they all start listing the FQDN and MX record, then match it up to the SPF, and pass it through.  Please, oh God please tell me why, the system is marking this as an SPF fail based on Private IP and not Public IP which it doesn't even get to?  Why fail immediately on the initial server in the header chain?  So many systems out there have multiple servers mail passes through before it even gets to the public gateway...

 

I got one administrator to create an SPF skip rule, but seriously I cannot be the only one with this issue.



#2 Michelle Exner

Michelle Exner

    BSF / BESS Moderator

  • Moderators
  • 387 posts

Posted 05 June 2015 - 09:44 AM

Whomever you are sending mail to that is using our Service has SPF checking enabled on their mail server.

Because their inbound mail is being sent to them from our IP addresses they need to turn OFF SPF checking on their mail server.

The reason is that the sending domains will never have our IP addresses in their SPF record.

SPF checking should be disabled on their local network/mail server and enabled on the Barracuda Email Security service.

Why their mail server is catching on the IPv6 address designation is unknown but as noted the problem is their doing SPF checking in the wrong place.


Michelle Exner
Product Lead Support Engineer
Barracuda Email Security
(408) 342-5300


#3 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 09:53 AM

So, that is the actual Barracuda system that is making this SPF fail.  The header you're reading is from my system.  The cudapos.com host that is processing this email and determining the SPF fail is Barracuda (http://myip.ms/view/hosts/383885/cudaops_com.html).  Any thoughts on why Barracuda is looking at the original IPv6 ::1 address and failing SPF based on the private IP structure instead of the public IP structure?  This is happening to all the non profits my statewide non-profit client is emailing to that are protected by Barracuda.  So I can tell you that its unlikely they all have this setting issue.  But there are at least 5 agencies so far protected by Barracuda that are failing on SPF and they shouldn't be.



#4 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 09:53 AM

I mean the header from the cudapos.com host, its reading hte private IP headers from my system, and failing on the IPv6 prviate IPs of my internal systems, and it shouldn't be.



#5 Michelle Exner

Michelle Exner

    BSF / BESS Moderator

  • Moderators
  • 387 posts

Posted 05 June 2015 - 10:27 AM

Chris,

I'm sorry but without being able to see the actual message details so we can investigate the problem there isn't a lot more I can tell you. If you are a Barracuda Email Security Service customer please call into support at 408.342.5300 and work with a technician on the problem.

If you are not then whomever you are trying to send mail to should call into support to get the delivery issue resolved.

What is interesting is that our service does not use IPv6 addressing at this time so how the IPv6 designation is being reported is most unusual.


Michelle Exner
Product Lead Support Engineer
Barracuda Email Security
(408) 342-5300


#6 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 10:40 AM

I did ask them to put in a support ticket - but I fear that since the Barracuda customer already put in a custom rule to skip SPF checking for this domain, they won't look too deeply.  If I can get a support case number, can I post it here and maybe you can look at little deeper?  

 

In the meantime, I'm searching for software to strip internal email headers, which you're not supposed to do for SMTP, to see if the first IP/hostname the system sees in the headers ends up being mail.<agency>.org and its Public IP.



#7 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 11:41 AM

I've stripped my internal message headers before it hits the public gateway.  Barracuda now receives my messages fine.  So - sure I worked around it but this is a pretty big problem I think you guys should look into.  Anyone using IPv6 on the private side is getting refused for SPF reasons - so take a look.  It might be because the header has multiple : in it, so the scanner at syntax is confused?  I'm not sure, but I'd definitely take a look at it and submit this as a possible problem for the developers.  Enough header info is in the original post here - if you need me to send test emails to a system somewhere, I'm happy to help.



#8 Michelle Exner

Michelle Exner

    BSF / BESS Moderator

  • Moderators
  • 387 posts

Posted 05 June 2015 - 11:51 AM

Again without seeing the actual incoming message we have no way of checking into this or troubleshooting it.

SPC checking is done on the incoming IP address not on what is listed in the headers UNLESS you are using a known relay service. If you are using a know relay service that is registered with our service we will skip over the actual sending IP address and use the next received line in the header.

So once again without the customer calling into support are reporting this as a problem there isn't a lot we can do. The actual message is needed to troubleshoot.

We have no other cases concerning this so it appears yours is the only instance of this happening at this time.


Michelle Exner
Product Lead Support Engineer
Barracuda Email Security
(408) 342-5300


#9 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 12:04 PM

Its a static IP on Comcast and they host their own email server.  No relay involved.  Look, I see what you're position is.  I'm telling you its a problem - I'm willing to help prove it.  4 independent domains are experiencing the same issue and I'll give them all to the support people.  But since I'm not a Barracuda customer myself, and I worked around it, I'm less inclined to help you guys out by "going the distance" on this one and getting IT admins from all four of the domains that are your customers involved in.  Let's walk through the usual scenario a support call would be if someone was having this issue.  Customer: "Hey, my system is marking this spam - how do I get it through?" Support: "Looks like its an SPF issue.  Create an exception rule for that domain to skip SPF checking.  <insert disclaimer for problems that might arise from that rule>"  Problem resolved - this kind of issue is just going to not be reviewed.  I bet if you have support search the Barracuda network systems, you will find a LOT of "Received-SPF: fail (barracuda.hostname: domain of recipient.com does not designate ::1 as permitted sender)" in there.  Just search for Received-SPF: fail with ::1 in it somewhere.  If my server is isolated (I'll give you the redacted info I put here), I'll buy you a beverage of your choice.  This is no joke.



#10 Michelle Exner

Michelle Exner

    BSF / BESS Moderator

  • Moderators
  • 387 posts

Posted 05 June 2015 - 12:31 PM

Chris,

I understand what you are saying but if the customer called in there would be no way to exempt ::1 from SPF checking so that would not work.

If you have a customer of ours who is experiencing or experienced this please have them call into support so we can investigate this issue.

Have them request me as the tech and I will look into this.

I have no way to search the billions of messages we get each day for this error so without the customer calling in and reporting it I have no way to track this down.

BTW.. Comcast is a trusted relay. Many of their IP's are skipped and the next IP is used. The same goes for Google Apps, Office 365 and so on.

Again to verify this problem and get it fixed the customer will need to contact us.


Michelle Exner
Product Lead Support Engineer
Barracuda Email Security
(408) 342-5300


#11 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 12:41 PM

They didn't request to exempt ::1, they simply created a rule for <agency>.org and skipped SPF checking for it.  I'm the one that is harping on this ::1 problem because he sent me the log above.

 

I believe the Comast email servers are trusted relays, this is not a  Comcast email server.  This is just a comcast cable internet provided static IP address and they run their own mail server.  If you're saying Barracuda skips the trusted relay, and lt's say the static IP is trusted, then goes to the next IP address - why didn't it fail on 10.5.10.11?  It must know that's a private IP address in one of the Private IP address spaces.  So then it goes on to look at the next one, that happens to be an IPv6 address for internal routing, and it fails then.  I know you don't support IPv6 - but IPv6 on my private LAN, specifically only even the local host entry, shouldn't cause any network to fail with IPv4 SPF in any part of the email chain, but it does.  

 

So mail goes from Outlook, to Exchange, to the Internet.  If you simply skip the only public IP that email actually has, how on earth is it going to compare the Private IPs to the SPF record and ever even get a good result?  Noone publishes SPF records with private IPs.

 

I'll get the case number from the administrator and contact you with it.  This one customer already built an exception rule for the domain.  I don't have IT contacts at the other three.



#12 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 05 June 2015 - 05:31 PM

I just wanted to update everyone that Michael at Barracuda looked deeper into the issue after I connected with him and the administrator at his client's email domain.  He found some strange SPF failures that he did report to engineering.  And also a referenced website in some of the emails from the domains was on their intent list, but after his personal review, he's requested to lift that intent block because the site appeared legitimate to him (it is :).  Thank you Michael for taking the time to look into this for us all.



#13 Chris Shipley

Chris Shipley
  • Members
  • 9 posts
  • LocationCambridge, MA

Posted 08 June 2015 - 01:43 PM

The SPF issues specifically were caused by misconfiguration on the Barracuda client's system, not a systemic issue of Barracuda all-round.