welshiv
asked on
Relaying denied errors on Exchange 2003
We have a standalone Exchange 2003 server that has recently began giving Relaying Denied errors. They are all either 5.5.0 or 5.7.1 errors. We also use a Barracuda 300 appliance for spam filtering by the way.Nothing has been changed in the configuration, so I am at a loss. Here are some examples of the errors:
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<ourmailserver.com #5.7.1 smtp;550 5.7.1 <user@theirdomain.com>... Relaying denied>
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
<ourmailserver.com #5.5.0 smtp;553 <user@theirdomain.com>: Client host rejected: No more junk mail thanks!>
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<ourmailserver.com #5.7.1 smtp;550 5.7.1 Unable to relay for user@theirdomain.com>
Relay Settings:
Only the list below = 192.168.x.x (our subnet) [255.255.255.0]
Allow all computers which successfully authenticate to relay... is checked
I have also checked our domain and public IP of our MX record on dnsstuff.com and DNSreports.com. Both came up clean. We are not on any blacklists and our PTR record for reverse DNS seems to be working as well.
Any help would be appreciated - thanks.
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<ourmailserver.com #5.7.1 smtp;550 5.7.1 <user@theirdomain.com>... Relaying denied>
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
<ourmailserver.com #5.5.0 smtp;553 <user@theirdomain.com>: Client host rejected: No more junk mail thanks!>
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<ourmailserver.com #5.7.1 smtp;550 5.7.1 Unable to relay for user@theirdomain.com>
Relay Settings:
Only the list below = 192.168.x.x (our subnet) [255.255.255.0]
Allow all computers which successfully authenticate to relay... is checked
I have also checked our domain and public IP of our MX record on dnsstuff.com and DNSreports.com. Both came up clean. We are not on any blacklists and our PTR record for reverse DNS seems to be working as well.
Any help would be appreciated - thanks.
ASKER
Turned on MSExchange Transport Logging and seeing quite a bit of these:
EVENT ID: 7004
This is an SMTP protocol error log for virtual server ID 1, connection #280. The remote host "208.x.x.x", responded to the SMTP command "rcpt" with "554 <user@theirdomain.com>: Relay access denied ". The full command sent was "RCPT TO:<user@theirdomain.com> ". This will probably cause the connection to fail.
EVENT ID: 4006
Message delivery to the host '65.x.x.x' failed while delivering to the remote domain 'theirdomain.com' for the following reason: The remote server did not respond to a connection attempt.
Some of the 4006 ones are for domains like verizon.net that should not be down. When I run an NSLOOKUP from the mail server, it does reply with the correct information.
EVENT ID: 7004
This is an SMTP protocol error log for virtual server ID 1, connection #280. The remote host "208.x.x.x", responded to the SMTP command "rcpt" with "554 <user@theirdomain.com>: Relay access denied ". The full command sent was "RCPT TO:<user@theirdomain.com> ". This will probably cause the connection to fail.
EVENT ID: 4006
Message delivery to the host '65.x.x.x' failed while delivering to the remote domain 'theirdomain.com' for the following reason: The remote server did not respond to a connection attempt.
Some of the 4006 ones are for domains like verizon.net that should not be down. When I run an NSLOOKUP from the mail server, it does reply with the correct information.
The relaying setting you have could have made your server an open relay. You do not need to have any relaying setting enabled if you are using exclusive MAPI clients (Outlook etc). Therefore I would suggest that you change that option to begin with.
You cannot do anything about the message ID. If someone gets in a position where they can use that information, you have bigger things to worry about.
Some of the problems could be routing issues. An NSLOOKUP doesn't really prove anything, you need to lookup the MX records and then attempt to connect using telnet from the server.
Do you send email through the appliance or directly?
Simon.
You cannot do anything about the message ID. If someone gets in a position where they can use that information, you have bigger things to worry about.
Some of the problems could be routing issues. An NSLOOKUP doesn't really prove anything, you need to lookup the MX records and then attempt to connect using telnet from the server.
Do you send email through the appliance or directly?
Simon.
ASKER
Not exclusive Outlook MAPI - we do have macs using Entourage, users using OWA and IMAP to PDA's. Which relay setting is causing your concern?
I believed we were sending the emails through the appliance, as evidenced by past header info, but now it seems it's coming from the server directly, although I don't know why.
I believed we were sending the emails through the appliance, as evidenced by past header info, but now it seems it's coming from the server directly, although I don't know why.
ASKER
And those relay settings have been in place for years and have passed open relay testing.
If the server is not directly exposed to the internet then you could be ok. I did say "could" not that it had. It very much depends on how the firewall presents the incoming traffic. I have seen it before.
You should verify whether the Exchange server is sending via the appliance or not. There are basically three ways...
1. A smart host on the SMTP virtual server (bad idea)
2. A rule on the firewall that captures SMTP traffic and directs it to the appliance.
3. An SMTP connector.
The SMTP connector is the best method and is what I would encourage.
Simon.
You should verify whether the Exchange server is sending via the appliance or not. There are basically three ways...
1. A smart host on the SMTP virtual server (bad idea)
2. A rule on the firewall that captures SMTP traffic and directs it to the appliance.
3. An SMTP connector.
The SMTP connector is the best method and is what I would encourage.
Simon.
ASKER
Right now it looks like it's sending directly from the server, although it should be going through the appliance. I will set up an SMTP connector and try that again. Question:
1. My exchange server is mail.mydomain.com with a public IP of 200.x.x.1
2. Recently one of the admins set up a new A record for the barracuda with the same public IP of 200.x.x.1 thinking it would help in preventing mail rejections when receiving servers performed reverse DNS lookups and got a different response, as it was coming from the appliance and not the mail server itself
It seems that the time this record was created was aboutt he time we started having these issues - could this be the cause? having both the applaince and the mailserver having different names but both ahving the same public IP address?
1. My exchange server is mail.mydomain.com with a public IP of 200.x.x.1
2. Recently one of the admins set up a new A record for the barracuda with the same public IP of 200.x.x.1 thinking it would help in preventing mail rejections when receiving servers performed reverse DNS lookups and got a different response, as it was coming from the appliance and not the mail server itself
It seems that the time this record was created was aboutt he time we started having these issues - could this be the cause? having both the applaince and the mailserver having different names but both ahving the same public IP address?
ASKER
actually just checked again and I'm confused - the barracuda has always been set to Inbound mode. However, if I look at an email from before the date the DNS change above was performed, I see the following in the header:
Received: from antispam.mydomian.com (exchange.mydomain.com [200.x.x.1])
and
X-Barracuda-Virus-Scanned:
emails now show:
Received: from exchange.mydomain.com (exchange.mydomain.com [200.x.x.1])
and no mention of the Barracuda
but the antispam one that I'm pulling the header from might have been sent from a computer outside the domain via IMAP, so that might have something to do with it being "marked" by the barracuda
Received: from antispam.mydomian.com (exchange.mydomain.com [200.x.x.1])
and
X-Barracuda-Virus-Scanned:
emails now show:
Received: from exchange.mydomain.com (exchange.mydomain.com [200.x.x.1])
and no mention of the Barracuda
but the antispam one that I'm pulling the header from might have been sent from a computer outside the domain via IMAP, so that might have something to do with it being "marked" by the barracuda
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
On testing I'm noticing that in the header information of emails sent by us, on the receiving end, they are seeing that the mail is from: ourmailserver.com but in the Message ID: field they are seeing the local computer name of our mail server - how do I prevent that?
Message-ID: <FAE5E824C1C28C4FAE0188593