SMTP relay not allowing anything in

554 554 5.7.1 : Relay access denied (state 14).

ASG does not produce such messages. Are you sure all the incoming mail arrives on the ASG?

What is the real domain used? Please do not obsfucate.

Mark, I'm confused: does email get rejected with a "554 5.7.1" message, or does it come "straight though"?

Cheers - Bob

There may be some capability that I ignore, but I don't believe the Astaro will work correctly if the IP is configured as '62.49.116.50/29'.  Others will please correct me if I'm wrong, but I believe you have to configure the interface as 62.49.116.50, then add 62.49.116.51-57 (each individually!) as 'Additional Addresses' on the External inteface.

If you want to treat the 62.49.116.50/29 block as a single entity for packet filter rules or someother, you can create a 'Network Group' in 'Definitions >> Networks'.

Markcasey, you sound knowledgeable, but I wonder if you aren't thinking in a Cisco command-line paradigm.

Cheers - Bob

It seemed to work fine, although when I connected in on telnet to port 25 from the lan to the firewall it got dropped out with "554 SMTP synchronization error" immediately. (I forgot to try and connect in remotely on telnet from my home machine)

So I'm provisionally saying emails now work. (I only had it connected up for a short period before I had to quickly reconnect the current firewall, but some emails seemed to have come through ok)

I've now got a fairly comprehensive configuration going, need to work on L2TP VPN for the iPhones next...

Hmm, I just had a more comprehensive test.

Some emails worked, others however hit the relaying denied wall and weren't mentioned in the logs anywhere. Which is highly worrying.

A company that tried sending emails to us were bounced back to themselves with a relay error message. (I've asked that these be forwarded to me)

The firewall is currently on 7.302, does 7.303 fix this issue? I noticed in another post it makes a mention of the SMTP relay and 7.303?

EDIT:

Same error as before:

"554 5.7.1 : Relay access denied" (obviously changed the email address to avoid spam harvesters)

Guys, i've just been examining the SMTP proxy log file and it gave this after just about everything:

2008:10:16-08:52:42 (none) exim[6245]: [1\32] 2008-10-16 08:52:42 1KqNex-0001cj-2h H=service8.mimecast.com [123.123.123.123]:59341 F= temporarily rejected after DATA: Temporary local problem, please try again!

Of special mention: temporarily rejected after DATA: Temporary local problem, please try again!. It's rejecting the mail as soon as it goes to DATA.

I've compressed a few samples from the actual log itself from a user who complained about the 554 errors.

See here.

Are there any ideas from the Astaro folks why this might be happening?

Reading up this appears that it might be an issue with exim and clamav?

Was this fixed in 7.303? (I'll be testing the firewall with 7.303 tomorrow morning)

I'll also make sure to disable the anti-spam/virus features anyway since we use a package on the email server itself for that kind of thing. Hopefully it'll work fine then.

@markcasey: as long as you have non-working MX records specified in DNS, mail to your domain may sporadically fail no matter what you do on the ASG, because it arrives on machines that will REJECT all messages to jadeprint.com. 

whizbang ~ # host -t mx jadeprint.com
jadeprint.com mail is handled by 100 relay-1.mail.demon.net.
jadeprint.com mail is handled by 100 relay-2.mail.demon.net.
jadeprint.com mail is handled by 10 mailgate.jadeprint.com.

If you do not know how to do this, please ask your ISP or domain service provider to REMOVE the relay-1.mail.demon.net and relay-2.mail.demon.net from your DNS configuration.

NB: The "temporary" rejects in the ASG logs are related to greylisting (which is a feature). You can turn it off.

Mark, our policy for our clients is that they should use layers of anti-virus at the perimeter, at the server and on each workstation.  We prefer to have at least two different suppliers for those three layers.

One of our clients receives about 50,000 emails a day.  95-97% of these are spam rejected before they enter their network.  Early in the SMTP transaction, before the email is accepted, 40% of the items are rejected by RBL and 40% by RDNS/HELO.  That means that 80% of spam is rejected with very little load on the Astaro.

An additional 10% of the total is blackholed at SMTP time because the Content Filter has recognized it as 'Confirmed Spam'.  You probably already have things configured for your server-based anti-spam product, so it's probably easier for you to just leave the 'Spam action' set to 'Off' in the 'Spam filter' section of the 'Anti-Spam' tab.

Cheers - Bob

Mark, our policy for our clients is that they should use layers of anti-virus at the perimeter, at the server and on each workstation.  We prefer to have at least two different suppliers for those three layers.

One of our clients receives about 50,000 emails a day.  95-97% of these are spam rejected before they enter their network.  Early in the SMTP transaction, before the email is accepted, 40% of the items are rejected by RBL and 40% by RDNS/HELO.  That means that 80% of spam is rejected with very little load on the Astaro.

An additional 10% of the total is blackholed at SMTP time because the Content Filter has recognized it as 'Confirmed Spam'.  You probably already have things configured for your server-based anti-spam product, so it's probably easier for you to just leave the 'Spam action' set to 'Off' in the 'Spam filter' section of the 'Anti-Spam' tab.

Cheers - Bob

Disabling the anti-spam/virus on the firewall did the trick. The user didn't get the 554 error.

Also, we use three anti-virus engines here. Two on the server side scanning engine and the third on the workstation clients, if any viruses get past the first two then the third picks it up.

And frankly I've got it set-up to quarantine any emails with certain attachments anyway, for example exe, passworded zip files etc.

We also use RBL's, Bayesian filtering etc too. (GFI MailEssentials)

All I need to do now is get the firewall correctly allowing traffic to the web server and remote terminal services access to the servers for myself. Which is something for tomorrow morning.

The "554 5.7.1" rejects occurred at SMTP time, probably because the sender doesn't have their own DNS records configured correctly.  The Astaro was right to catch this.  I'm going to guess that you had already excepted email from TL Risk Solutions from RDNS checks in MailEssentials.

However, it does make good sense that the quickest way to get started is turning off everything on the 'Anti-Spam' tab.  You could leave the Anti-Virus on.  You might also want to take advantage of advanced features like encryption.

Cheers - Bob

The "554 5.7.1" rejects occurred at SMTP time, probably because the sender doesn't have their own DNS records configured correctly.  The Astaro was right to catch this.  I'm going to guess that you had already excepted email from TL Risk Solutions from RDNS checks in MailEssentials.

However, it does make good sense that the quickest way to get started is turning off everything on the 'Anti-Spam' tab.  You could leave the Anti-Virus on.  You might also want to take advantage of advanced features like encryption.

Cheers - Bob

I've got MailEssentials configured to automatically whitelist any addresses that have been sent to. So, for example if I were to send an email to joe.bloggs@anyplace.com then he'd automatically be excepted from spam filtering. (but not virus checking)

Well, as to the anti-virus.. frankly that costs extra and I'm on a tight budget. I recently managed to convince my boss for us to go over to a leased line which is costing plenty of money. Personally I would love it if we went with two 220's in HA with all the bells and whistles, a 10 meg leased line and a partridge in a pear tree. But that would cost a lot more than I've been able to beg and plead money wise.

We're not that large a company.

The "554 5.7.1" rejects occurred at SMTP time, probably because the sender doesn't have their own DNS records configured correctly.  The Astaro was right to catch this.  I'm going to guess that you had already excepted email from TL Risk Solutions from RDNS checks in MailEssentials.

However, it does make good sense that the quickest way to get started is turning off everything on the 'Anti-Spam' tab.  You could leave the Anti-Virus on.  You might also want to take advantage of advanced features like encryption.

Cheers - Bob

I've got MailEssentials configured to automatically whitelist any addresses that have been sent to. So, for example if I were to send an email to joe.bloggs@anyplace.com then he'd automatically be excepted from spam filtering. (but not virus checking)

Well, as to the anti-virus.. frankly that costs extra and I'm on a tight budget. I recently managed to convince my boss for us to go over to a leased line which is costing plenty of money. Personally I would love it if we went with two 220's in HA with all the bells and whistles, a 10 meg leased line and a partridge in a pear tree. But that would cost a lot more than I've been able to beg and plead money wise.

We're not that large a company.