Barracuda Networks Spam Firewall

"Jared B. Reimer" <jared@theriver.com> 5/17/04 2:48:16 PM >>>

We have done an eval of this same product (model 400). It is very

cool in

virtually every regard except one: performance. We were facing 1+

hour

mail delays (!) through the device when pumping less than 1,000,000
messages per day through it. Given that they claim it can handle ten

times that much, I am left wondering what happened. Very

disappointing in

that regard; the eval unit is being shipped back as a result. --

Jared

Did you not receive some basic support from them during your
evaluation? A perceived 90% drop in performance is pretty significant
and I'd imagine that they'd be interested in helping to determine the
cause.

John

Did you not receive some basic support from them during your
evaluation? A perceived 90% drop in performance is pretty significant
and I'd imagine that they'd be interested in helping to determine the
cause.

Sadly, they have not responded to my email on the topic, sent four days ago.

However, someone unrelated to the company emailed me off-list saying that basically this is a known flaw in the product with back-end systems like qmail that asynchronously bounce mail for invalid recipients. See below quote:

We had this problem when our inbound-smtp server ( the server the barracuda is dumping mail to) was accepting all RCPT TOs: As a result dictionary attacks were getting through and creating 'unique recipients' on the Barracuda. As soon as I fixed my mail server to reject with a 220 error on bogus RCPT TOs the problem cleared up.

This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't the only mailer that behaves this way. It looks like they may have tried to kludge their way around this with LDAP in the case of MS Exchange, which also does asynchronous bouncing of undeliverable mail IIRC.

-- Jared

The fault here is with qmail. The barracuda was doing exactly what it was
designed to do. qmail can be patched to be smarter (google for qmail
spamcontrol or magic smtpd). Accept all, then try to bounce, is a recipe
for disaster with today's dictionary attackers and virii that will send to
randomly created destinations from randomly created forged froms.

Quite frankly, I'm at a loss as to why anyone would wish to accept
and queue mail that they cannot deliver. Queuing everything just allocates
disk unnecessarily and results in a lot of delayed bounce backscatter,
almost always directed at a third party (in the common case of spoofed from:
headers).

  Accepting everything simply because you don't wish to give away
valid addresses doesn't work; the spam bots just jabber more loudly at you.
In the past year I've had two domains joe jobbed, generating thousands of
those helpful delayed bounce messages per hour for my role accounts.

  If, after RCPT TO, you do not have a valid destination, just
refuse it. My role accounts thank you.

  --msa

Well.. you're somewhat right - *IF* the mail gateway is able to make the
determination quickly and definitively, reacting as soon as you see the RCPT TO:
is a good idea. However, that can be a big 'if' in some configurations...

Traditionally, "accept and queue" was a reasonable way for a gateway
mail relay to function (and if you think about it, it's usually the ONLY way
for an off-site secondary MX to function). You'd accept and queue everything,
and then forward it to an internal machine that actually knew what mailboxes
were valid addresses. If you don't do that, then you have to make your
authentication system visible to machines on your DMZ, which has it's
own touchy implications....

For high-volume sites, there are also firewall state issues - if you're getting
100K messages/hour, and each one has to be open for 5 seconds because of
authentication issues on the RCPT TO:, you'll average 138 open connections.
If you accept, queue, and deal with it later, you can get it down to 1 second
and then you only average 27 open connections (numbers for illustration
purposes only).

Or push a list of valid addresses to the secondaries that they keep locally and use, update as needed. You don't need to 'authenticate' -- just know what is/isn't valid.

For a few hundred, or a few thousand accounts rsync/ssh/make could do the job. If you're AOL, I'm sure there is a solution too.

Remember to ask the auditors what they think of having such a list on
a box in the DMZ. :wink:

: >We had this problem when our inbound-smtp server ( the server the
: >barracuda is dumping mail to) was accepting all RCPT TOs

: This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't
: the only mailer that behaves this way.

And, regardless of what the Barracuda box did, you should fix your qmail
install. This behavior is no longer considered acceptable by the 'net at
large, because accept-then-bounce is the biggest cause of virus spew
bounceback spam.

(As a result, people have begun widely blocking MXs that accept-then-bounce.
You'd do yourself quite a favor to convert to reject-at-SMTP now, before you
get blocked too.)

: > Quite frankly, I'm at a loss as to why anyone would wish to accept
: > and queue mail that they cannot deliver.

: Well.. you're somewhat right - *IF* the mail gateway is able to make the
: determination quickly and definitively,

That "if" is rapidly becoming a *requirement*. I invite you to participate
in SPAM-L@PEACH.EASE.LSOFT.COM is you somehow feel differently.

: Traditionally, "accept and queue" was a reasonable way for a gateway
: mail relay to function (and if you think about it, it's usually the ONLY way
: for an off-site secondary MX to function).

Then make the offsite MX use a user list, or else don't use an offsite MX at
all. Sending mail exchangers will retry when the recipient servers are
down; that's mandated by SMTP. You don't need an offsite secondary MX that
has no access to a valid address list.

Sorry to burst your bubble, but as of this year, where the levels of virus
bounce spam as hreached obscene levels, this is no longer a valid excuse.

: For high-volume sites, there are also firewall state issues

Then upgrade your firewall. This is certainly not a valid excuse.

At present, thanks to a recent massive joe job against one of the
domains we host, I've got a list of ~16100 mailhosts that I no longer
accept null sender mail* from. Most of them are running qmail, based on
some unscientific analysis I did when compiling the list. All of them
accepted, then bounced, mail from spammers HELO'ing with that domain
"back" to the victim. Several hundred also sent us DSNs from virus
forgeries. All of them were unnecessary.

Sad, really, especially given that patches exist to fix this problem.

Steve
* or postmaster/Symantec_Antivirus/Webshield/VirusWall/JCT/etc.