jjFOX04
asked on
Irregular email relay issue
Hi All,
We are a single domain network with multiple email domains associated to it. One of our email domains is having an issue where incoming emails are getting a bounceback "550 5.7.1 unable to relay for email@domain.com" where email@domain.com could be one of three distribution groups with between 4 and 7 users within. These seem to be the only 3 email addresses that are affected.
However, in addition, it doesn't happen for every email going to these addresses, it is roughly happening to a quarter-a third of all emails going to those addresses.
We use a Mimecast email service, where i can see all of the bouncebacks that have been sent, and the IP address for this service has been added to our Exchange relay list. The relay properties of our SMTP protocol on our Exchange server are set to "only allow the list below" (with the mimecast IP address in the list, plus a couple of our web servers). We also have "allow all computers which successfully authenticate to relay, regardless of the list above" ticked.
Any help greatly appreciated!
Kind Regards,
Dave
We are a single domain network with multiple email domains associated to it. One of our email domains is having an issue where incoming emails are getting a bounceback "550 5.7.1 unable to relay for email@domain.com" where email@domain.com could be one of three distribution groups with between 4 and 7 users within. These seem to be the only 3 email addresses that are affected.
However, in addition, it doesn't happen for every email going to these addresses, it is roughly happening to a quarter-a third of all emails going to those addresses.
We use a Mimecast email service, where i can see all of the bouncebacks that have been sent, and the IP address for this service has been added to our Exchange relay list. The relay properties of our SMTP protocol on our Exchange server are set to "only allow the list below" (with the mimecast IP address in the list, plus a couple of our web servers). We also have "allow all computers which successfully authenticate to relay, regardless of the list above" ticked.
Any help greatly appreciated!
Kind Regards,
Dave
Dave Alford
Can you see the message headers of a bounced message - it should contain information showing why it's bounced and what actually bounced it?
ASKER
unfortunately i cannot see the actual bounced email, I can only see the email that came into Mimecast in the first place. I've only got an option to view the "bounce report" in Mimecast to see the bounce code 550 5.7.1. Unable to Relay for....
I was hoping to check our SMTP logs on the exchange server, but they have been switched off, so unsure whether the email actually made it from Mimecast to our exchange server before being bounced.
I was hoping to check our SMTP logs on the exchange server, but they have been switched off, so unsure whether the email actually made it from Mimecast to our exchange server before being bounced.
Have you asked Mimecast to check? It could just be they're using someing like a dynamic IP address blocklist .....
ASKER
I have, still waiting for a reply from them - there response time has never been particularly quick for us, which is why i came on here.
It's looking increasingly like a Mimecast issue, but wanted to check in case there was something obvious that I'd missed.
Happy to close this question though if you're confident it's something Mimecast would need to solve, rather than on our Exchange server?
It's looking increasingly like a Mimecast issue, but wanted to check in case there was something obvious that I'd missed.
Happy to close this question though if you're confident it's something Mimecast would need to solve, rather than on our Exchange server?
unfortunatly, without the bounced message header it's difficult to tell.
What you could try doing is connecting to the receiving SMTP server at Mimecast via telnet on port 25 FROM a dynamic ADSL connection - if you get a denied message then they probably block dynamic/ADSL IP addresses. If you have access to a DSL connection with a 'proper' static IP you could then try the same thing and, if it then works, you could be pretty confident they're using blocklists (and, just about everyone does nowadays)
What you could try doing is connecting to the receiving SMTP server at Mimecast via telnet on port 25 FROM a dynamic ADSL connection - if you get a denied message then they probably block dynamic/ADSL IP addresses. If you have access to a DSL connection with a 'proper' static IP you could then try the same thing and, if it then works, you could be pretty confident they're using blocklists (and, just about everyone does nowadays)
ASKER
@davealford
Sorry for not getting back to you sooner. I have connected to the server at Mimecast via telnet without a problem at all, so the problem is still illusive!
I have had a reply back from Mimecast as well, saying:
As per the previous email that I sent you emails that 'Hard bounced' are bounced by the recipient server. It is a server condition causing the non acceptance of the email.
In the case of the email screenshot attached, Mimecast attempted to deliver the email to your server - **IP Address** but the server refused to accept the message and issued the '550 5.7.1 Unable to relay for email@domain.com' error.
Yes, some emails will go through but this is a known issue that we come across almost everyday where some emails for some reason will not go through until the issue has been corrected on the server side.
Please see the delivery log of one email confirming the issue on the exchange. As you will see we are correctly able to establish a connection to your server but its only when we issue the RCPT To command that we get an error:
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
Does this help at all with diagnosing the issue on our server at all?
Sorry for not getting back to you sooner. I have connected to the server at Mimecast via telnet without a problem at all, so the problem is still illusive!
I have had a reply back from Mimecast as well, saying:
As per the previous email that I sent you emails that 'Hard bounced' are bounced by the recipient server. It is a server condition causing the non acceptance of the email.
In the case of the email screenshot attached, Mimecast attempted to deliver the email to your server - **IP Address** but the server refused to accept the message and issued the '550 5.7.1 Unable to relay for email@domain.com' error.
Yes, some emails will go through but this is a known issue that we come across almost everyday where some emails for some reason will not go through until the issue has been corrected on the server side.
Please see the delivery log of one email confirming the issue on the exchange. As you will see we are correctly able to establish a connection to your server but its only when we issue the RCPT To command that we get an error:
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
INFO |0907-083406|Thread-169260
Does this help at all with diagnosing the issue on our server at all?
Are you running any inbound filters on Exchange ie. DNS blocklists, SPF checks etc?
In the log file provided, the domain findaproperty.com has a SPF of "v=spf1 ip4:217.205.148.44 ip4:213.52.169.192/26 include:spf.messagelabs.co
So, as your mail server is 'seeing' the mail as comming FROM 91.220.42.11 (mimecast), if SPFchecks are enforced, it will reject the message.....
In the log file provided, the domain findaproperty.com has a SPF of "v=spf1 ip4:217.205.148.44 ip4:213.52.169.192/26 include:spf.messagelabs.co
So, as your mail server is 'seeing' the mail as comming FROM 91.220.42.11 (mimecast), if SPFchecks are enforced, it will reject the message.....
ASKER
Hi,
No blocklists/filters are enable don our Exchange - we always configure mimecast to filter anything where necessary. Nothing is set in Mimecast to filter in this situation though... Would i be right in presuming if Mimecast was filtering/blocking anything, it would block all emails from that address, rather than random ones?
No blocklists/filters are enable don our Exchange - we always configure mimecast to filter anything where necessary. Nothing is set in Mimecast to filter in this situation though... Would i be right in presuming if Mimecast was filtering/blocking anything, it would block all emails from that address, rather than random ones?
It doen't appear to be mimecast. It is your Exchange that's issueing the 550 message. What do you see in your SMTP logs for the denied messages - you may need to enable logging on the SMTP service?
ASKER
Thankfully i switched SMTP logging on yesterday. There's been a 550 unable to relay again this morning - for which the SMTP logs have the following:
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 HELO - +mimecast service 250 0 41 27 0 SMTP - - - -
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 MAIL - +FROM:<support@findaproper
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 RCPT - +TO:<email@domain.com> 550 0 55 33 0 SMTP - - - -
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 QUIT - mimecast service 240 16 63 4 0 SMTP - - - -
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 HELO - +mimecast service 250 0 41 27 0 SMTP - - - -
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 MAIL - +FROM:<support@findaproper
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 RCPT - +TO:<email@domain.com> 550 0 55 33 0 SMTP - - - -
2011-09-08 08:38:05 91.220.42.11 mimecast service SMTPSVC1 MAIL-SERVER 192.168.1.* 0 QUIT - mimecast service 240 16 63 4 0 SMTP - - - -
ASKER
Hi all,
does anyone have any idea's for this issue at all? It is still happening, and so far everything I have tried has had no effect at all.
Any help greatly appreciated,
Regards
Dave
does anyone have any idea's for this issue at all? It is still happening, and so far everything I have tried has had no effect at all.
Any help greatly appreciated,
Regards
Dave
do you have any limits on the mailbox attachments, mailbox size etc?
are you 100% you have no filtering (blacklists spf etc) in place?
What's the diskspace like? - Exchange 2007 and 2010 check for diskspace and start bouncing mail if below threshold.
are you 100% you have no filtering (blacklists spf etc) in place?
What's the diskspace like? - Exchange 2007 and 2010 check for diskspace and start bouncing mail if below threshold.
ASKER
Hi Dave,
We've got attachment limits at 30Mb on exchange, but the emails that are bouncing will never be more than 1Mb (they are plain-text emails requesting information mostly). Definitely no blacklists or filtering in place.
As for diskspace - we're running Exchange 2003 so not sure if this applies, but we're at 60Gb on the exchange database (in total - EDB and STM files combined) on a harddisk that has 125Gb used of 270Gb available.
We've got attachment limits at 30Mb on exchange, but the emails that are bouncing will never be more than 1Mb (they are plain-text emails requesting information mostly). Definitely no blacklists or filtering in place.
As for diskspace - we're running Exchange 2003 so not sure if this applies, but we're at 60Gb on the exchange database (in total - EDB and STM files combined) on a harddisk that has 125Gb used of 270Gb available.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
explanation of what we did has resulted in it solving the problem