• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 10879
  • Last Modified:

Sending email from Barracuda - error: 550 5.7.1 Unable to relay for [external email] - Exchange setup issue!?!

I have obtained a Barracuda 300 SPam firewall and having problems setting it up. Barracuda support tell me it is an exchange issue.

the barracuda is suppsed to be setup to receive SMTP mail and then forward it to your exchange server (albeit filtered) has an option to "Test SMTP Connection". However on doing so I get the error message (summarised):
550 5.7.1 Unable to relay for externalemailaddress@example.com

(full error message at bottom of post)

The problem occurs when I press the "Test SMTP Connection" button from the IP configuration page and use an external email address.

Note that when I use an email address that is of an account on the local exchange (e.g. example@COMPANYNAME.co.uk) the email does deliver OK and the test succeeds, but not with any external email address.

Barracuda claim this could be becauseof "Recipient filtering" in the exchange but I looked into this and none of this is set

I am not sure why I'm getting this error and not being an exchange expert wonder if anyone here can help. Below is more information about my current network setup.

The network consisits of two Windows 2003 Servers behind a firewall. One of these servers acts as both the exchange and the DNS servers. This server is on local IP address

I placed the Barracuda on

Currenlty incoming traffic on port 25 (SMTP) is directed to (the exchange server) and everything works as it should with the email.

When I go live with the barracuda I will adjust this above firewall rule to point port 25 traffic to the address (and then the barracuda will filter it and forward it to the exchange server).

I have not made the above firewall rule change yet (and therefore not gone live) becuase I want to make sure everything is OK before I do that.

I have set in the barracuda the mailserver IP as and on port 25 (The default). So once live it will forward on the email to the exchange server.

Therefore I would expect the test to work. But Barracuda support say there is a configuration issue on the Exchange. Note before and now normal email works as well as we know.
Essentially it was suggested that something in exchange is set to block emails from the barracuda making the test fail, but I cannot see what and do not know where to look.

Does anyone know what could be causing this issue?

Full test message error log (domain names editied out)

Test results:
Error performing SMTP test:
Connected to session output follows:
220 mail01.COMPANYNAME.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Sun, 12 Nov 2006 18:47:58 +0000
helo barracuda.COMPANYNAME.co.uk
250 mail01.COMPANYNAME.local Hello []
mail from:<smtptest@barracudanetworks.com>
250 2.1.0 smtptest@barracudanetworks.com....Sender OK
rcpt to:<externalemailaddress@example.com>
550 5.7.1 Unable to relay for externalemailaddress@example.com
  • 4
  • 3
2 Solutions
Hi afflik1923,

> Barracuda claim this could be becauseof "Recipient filtering" in the exchange but I looked into this and none of this is set

That is the stupidest thing I have ever heard, but sounds like standard first level support rhetoric (run through the obvious stuff and when you get stuck, blame the closest app/server/service/person) - Exchange doesn't answer with "unable to relay" with recipient filtering on.  However, they are close, it is the exchange server.

Looking at your output, I can see two obvious problems.  First, your server is answering with it's internal name "mail01.domain.local" it SHOULD be answering with it's external name "mail.xyzcorp.com".  Open ESM > drill down to the default smtp server of your server > properties > delivery > advanced > change the fqdn to the external name.  This will not be the problem here, but will be A problem.

The test you are doing is faulty.  Your exchange server is doing exactly what it should be doing, it receives mail for some external domain, and it refuses to deliver it.  If it did actually send it, then you would be an open relay (and spamming the world).

If for whatever reason you wanted EXTERNAL mail to be sent FROM the barracuda TO the internet (which I can't imagine you actually wanting to do) you would need to allow the IP address of the barracuda device to relay in the exchange server smtp properties.

As I said though, this shouldn't be necessary, and isn't a good idea.

Hope that helps,

afflik1923Author Commented:
Hi Red,

This does sound helpful and great to hear from someone who knows (or at least sounds like :) ) what they are talking about.

I will meet this with an immedite reply as I was working on this all day (despite scheudling two hours to install the barracuda).

Regarding your second set of points around "The test you are doing is faulty. ".

Depite thinking this, do you mean the Barracuda box is wrong to have this test. Barracuda seemed adament (although it was Sunday support) that this test should work and I do not want to put it live until I'm certain all is good.

Rememebr the baracuda is on the local network of the exchange. It is not like an external box elsewhere trying to use it to send outgoing email.
In general there should be some way of getting the test to work and the quick start gude (I am also reading ht efull guide) makes it all sound so simple (without mentioning any changes required in exchange).

I will investigate the other Full qualified domain issue. I have never felt comfortable with it doing that actually but as it did not seem to cause any other issues I did not want to change anything unnecessarily (As I'm new to exchange and do not want to break current setup)

That test will NEVER work on a properly configured Exchange server.  Period.

If that test MUST work for whatever reason, you will have to enable that device to relay through the exchange server (by IP address) - I really, really, think this is a bad idea though, and it should be totally unnecessary.

If that test passed, then what would be stopping me from telnetting to your server like so;

ehlo mail.fake.com (not your domain)
mail from:fake@domain.com (not your domain)
rcpt to:target@address.com (not your domain)
subject:want to buy viagra?

With relaying enabled to the world (open relay) your exchange server would be more than happy to forward that mail on - which will not only generate you a heap of traffic, it will also cause you to get blacklisted by the relay databases (databases that keep tabs on servers that are insecure).  Once you are on one of these databases, you would not be able to email anyone that uses them for security (and MANY places do)

As for the FQDN, you are actually giving away more information by not changing it - information about your private domain.  The public domain is already out there, there is nothing to worry about in telling people what it is.  As for the current setup and breaking it - the worst you could do by making that change is improve things.  If you changed it to incorrectserver.incorrectdomain.spam it would be equivelant to what you have in there now (the internet hates .local domains, which is one reason why I never use them)

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

afflik1923Author Commented:
OK I will speak to Barracuda some more about this when there better support comes back Monday.

do also remember, it does also work when I use a local email address. therefore example@COMPANYNAME.co.uk

Then the email sends and the test passes. I assume therefore that this still makes sense that it does send a local email addrss?
Local addresses should be the only ones that do work - sorry, I should have made that clear.

Exchange knows that it is responsible for certain domains, and will simply refuse to relay mail for other domains, unless it has been configured specifically for it, which is also not really advisable

Again, Red is 100% correct with his explanation.

To further clarify your doubt, I guess your setup is like below

LAN <-> exchange server <-> barracuda <-> firewall <-> internet

"The problem occurs when I press the "Test SMTP Connection" button from the IP configuration page and use an external email address."  
when you say external/internal email address you are writing this in which field. i suppose it is the destination (i.e To) address.

see the link below for the series of commands to test your smtp connection http://www.petri.co.il/smtp_pop3_and_telnet.htm

The series of commands specifies the "mail from" and "rcpt to" addresses. if the recepeint adress is local, the SMTP test will be successful. If the recpeint address is external then you have to configure your exchange server so that it allows Barracuda to relay external mails. Remember, your exchange server is still responsible for sending the external mails, Barracuda is used only for recieving external mails.

To me, if your SMTP test is successful using your local email address, you r Done !

Cheers !!

afflik1923Author Commented:
OK guys,

Thanks you for your help on this matter. Appears you were right. I wish Barracuda's weekend support had been more knowedgeable. I wasted a good 8 hours looking into a failed test problem that cannot pass.

It's very silly indeed. However I did get some good education about the features in exchange.

So Red thanks for your input on this and thanks to ikm for further calirifying the facts.

Red, the domain.local problem you mentioned will still be apparent. This of course is something I should also look into fixing, but at the time being I want things to settle down with the Barracuda so we can effectily measure its performance before introducing any other changes. As far as we know the .local extension does not seem to be causing any actual problems and would have been set like that for a long time.

For the record the Barracuda does seem to be helping wiht the elimination of SPAM.

Thanks again

It would have been great for Barracuda to give you correct help when you called them.

All (properly configured) email servers would produce the results that you did when entering and external domain, and it is just woeful that the person you spoke to had no idea about how email servers work!

As for the .local, if you are worried about changing it, and it isn't causing any issues as yet, then you can leave it.  Of course, making this change is really a non-event, it can only improve things.  Just bear it in mind in the future if people have problems sending/receiving with you.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now