Barracuda’s Reputation server considered harmful

Barracuda has a new product that is clearly selling well: I am unable to send email to an increasing number of people.

I am one of those people who doesn’t instinctively trust all my data to Google; I run my own email rig.  That rig is a machine parked in a good colocation facility, which accepts email submitted via SMTP-AUTH and routes it out for me. There’s an SPF record and everything.

Barracuda’s product implements the clever trick of looking at the Received: header to see where my mail server got the email from. They can see the email is originating from a home DSL IP before going to my colo, which surely means I’m a member of a botnet. They have also banned most of the Rogers/Fido wireless network, so email off my iPhone is rejected even though it follows a similar route.

The difference between my email and spam email is that it goes through a system which has a good reputation, which has an SPF record to authenticate its right to send email on behalf of people in my domain name.  This is clear from the Received headers, and and the fact Barracuda is getting a connection from that machine.

This bug can be worked around by using gmail or presumably any other vaguely reputable email hosting service. Even though gmail discloses my home IP address in headers as well, Barracuda have seen fit to give webmail services an exception.

Fix your stupid software, Barracuda. You’re ruining email.

Headers below. Scenario: 76.119.229.140 spooled email onto jane.tinyplanet.ca via SMTP, which has spooled up the email for delivery to someone @demandmedia.com, which is using Barracuda Reputation.  jane is permitted, via my SPF, to route mail out for @tinyplanet.ca.

host mail.demandmedia.com [207.8.85.132]: 554 Service unavailable; Client host [jane.tinyplanet.ca] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=75.119.229.140

------ This is a copy of the message, including all the headers. ------
Received: from 75-119-229-140.dsl.teksavvy.com ([75.119.229.140] helo=[10.0.1.3]) by mail.tinyplanet.ca with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1QZieP-0000y6-CK for xxx@demandmedia.com; Thu, 23 Jun 2011 08:04:49 -0400
From: Stephen van Egmond <xxx@tinyplanet.ca>
Date: Thu, 23 Jun 2011 08:05:07 -0400
To: xxx@demandmedia.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,BAYES_00,
TVD_RCVD_IP autolearn=ham version=3.3.1

Published by

svanegmond

My home page will tell you far more about me than this little square ever could. I tweet as @svanegmond.

3 thoughts on “Barracuda’s Reputation server considered harmful”

  1. It appears that “mail.demandmedia.com” is using as feature of the Barracuda Spam & Virus Firewall known as deep header scanning without also using a concomitant feature called Trusted Forwarder. This is what is causing the Barracuda Spam & Virus Firewall at demandmedia.com to look at your IP address for reputation check.

    Deep header scanning feature should be turned on in conjunction with Trusted Forwarder. Using it stand alone causes the problems you are seeing.

    BTW here is a link for more details on how Gmail (since you mentioned Gmail in your post) handles this – http://mail.google.com/support/bin/answer.py?hl=en&answer=26903

    We noticed that you have requested de-listing from Barracuda Reputation List and that request was processed correctly. However, as noted above, the long term fix is to contact demandmedia have them enable Trusted Forwarder.

    We’d be happy assist further in this case through Barracuda networks support at http://www.barracuda.com/support

  2. Barracuda Networks:

    Thanks for letting me know about your software’s features. I didn’t know modern software companies offered features that are useless unless used in combination. Please consider just making one feature imply the other.

  3. @Barracuda Networks

    My problem is that it is our mail being blocked due to our clients using Barracuda software which clearly allows a set up which it shouldn’t. It is virtually impossible to get to talk to someone on the other end who has any clue about their spam system and to get them to make a change is impossible, so it becomes my problem to try to ensure that our mail reaches the intended recipient. Your software makes this job impossible. I don’t see why I have to fight software when we are not sending spam and actually are authenticating against a valid smtp server. I would like to echo the words of Stephen, who asks that you consider making one feature imply the other!!!

Comments are closed.