zorba111
asked on
Undeliveralbe emails: "You do not have permission to send to this recipient. For assistance, contact your system administrator"
Sometimes, when sending email to certain external email addresses, we have received the following undeliverable message (with actual data deleted and replaced with placeholders in <>'s):
Subject: Undeliverable: <sent message subject>
Your message did not reach some or all of the intended recipients.
Subject: <sent message subject>
Sent: 29/11/2007 14:50
The following recipient(s) could not be reached:
<person>@<company>.com on 29/11/2007 14:50
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<office.ourdomain.co.uk #5.7.1 smtp;550 5.7.1 <person>@<company.com>... Relaying denied. Proper authentication required.>
We are using Office2003 and Exchange on SBS2003.
We first noticed this problem today.
Yesterday I fixed the reverse DNS, and that solved a problem about Yahoo treating our mail as spam.
Also yesterday I created an SPF record.
Also yesterday I reset the "Masquerade Domain" and "FQDN" in Exchange, to fix a Warning on DNSStuff, causesed by the SMTP Greeting not match domain name of the mailserver.
Not sure if any of this has caused the problem.
What I can say is that later we sent email to the same address and it was received fine.
Any ideas ?
Subject: Undeliverable: <sent message subject>
Your message did not reach some or all of the intended recipients.
Subject: <sent message subject>
Sent: 29/11/2007 14:50
The following recipient(s) could not be reached:
<person>@<company>.com on 29/11/2007 14:50
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<office.ourdomain.co.uk #5.7.1 smtp;550 5.7.1 <person>@<company.com>... Relaying denied. Proper authentication required.>
We are using Office2003 and Exchange on SBS2003.
We first noticed this problem today.
Yesterday I fixed the reverse DNS, and that solved a problem about Yahoo treating our mail as spam.
Also yesterday I created an SPF record.
Also yesterday I reset the "Masquerade Domain" and "FQDN" in Exchange, to fix a Warning on DNSStuff, causesed by the SMTP Greeting not match domain name of the mailserver.
Not sure if any of this has caused the problem.
What I can say is that later we sent email to the same address and it was received fine.
Any ideas ?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
2PiFL: Wow, that is a lot of scenarios all to be included under one error code!
Sembee:
a) I'm happy to take the masquerade domain setting out (replacing with "" I presume ?), but would love to know the reasoning behind this before I could accept this as a solution.
b) I didn't know what a smart host was when I first read your post. From what I can tell, its a second email server that my Exchange would connect to, in order to get all its email out. My understanding is that this is NOT the case, and our Exchange will connect directly to other mailsevers.
Sembee:
a) I'm happy to take the masquerade domain setting out (replacing with "" I presume ?), but would love to know the reasoning behind this before I could accept this as a solution.
b) I didn't know what a smart host was when I first read your post. From what I can tell, its a second email server that my Exchange would connect to, in order to get all its email out. My understanding is that this is NOT the case, and our Exchange will connect directly to other mailsevers.
Microsoft are almost unique in using the term "smart host". Everyone else uses relay server or something else. It is basically another SMTP server, often at an ISP or another service provider that Exchange sends its email out through.
The masquerade domain setting is not really the fix, it is just something I wouldn't set and I would not expect setting it to resolve the issue. However it being set can produce some odd results in the SMTP headers, so I would suggest removing it.
The FQDN field though should stay completed and should match the DNS entry for the server on the internet.
Simon.
The masquerade domain setting is not really the fix, it is just something I wouldn't set and I would not expect setting it to resolve the issue. However it being set can produce some odd results in the SMTP headers, so I would suggest removing it.
The FQDN field though should stay completed and should match the DNS entry for the server on the internet.
Simon.
ASKER
Thanks Sembee,
I will take out the masquerade domain setting when I get into the office tomorrow.
When we first set up Exchange, it collected from and delivered mail to a mailserver provided by our web hosting providers. I guess this is what is meant by a "smart host" or a "mail relay".
Then we set up Exchange to run as its own mailserver, however some of the vestiges / configuration relating to the days when it used the hosting providers mail relay are probably still set up (a POP3 Connector for one), and I'm wondering if any of these may cause / contribute to the problem ?
I would restress at this point that this is an INTERMITTENT problem, and we were able to send messages to this problem email address later in the same day (but I still want to get to the bottom of it, even though it appears to be "fixed", as I would have no confidence in it not returning, if we did nothing).
I will take out the masquerade domain setting when I get into the office tomorrow.
When we first set up Exchange, it collected from and delivered mail to a mailserver provided by our web hosting providers. I guess this is what is meant by a "smart host" or a "mail relay".
Then we set up Exchange to run as its own mailserver, however some of the vestiges / configuration relating to the days when it used the hosting providers mail relay are probably still set up (a POP3 Connector for one), and I'm wondering if any of these may cause / contribute to the problem ?
I would restress at this point that this is an INTERMITTENT problem, and we were able to send messages to this problem email address later in the same day (but I still want to get to the bottom of it, even though it appears to be "fixed", as I would have no confidence in it not returning, if we did nothing).
POP3 connector has nothing to do with outbound email, that is inbound only.
If you are sending email out through an ISPs server then that may well be the issue. Many ISPs use clusters of servers and if one of those servers is playing up then there is little you can do about it.
It isn't an Exchange error, and as it has your server in the NDR it is occurring on the first hop out of the site - which tends to suggest the ISP at fault.
Simon.
If you are sending email out through an ISPs server then that may well be the issue. Many ISPs use clusters of servers and if one of those servers is playing up then there is little you can do about it.
It isn't an Exchange error, and as it has your server in the NDR it is occurring on the first hop out of the site - which tends to suggest the ISP at fault.
Simon.
ASKER
>> If you are sending email out through an ISPs server then that may well be the issue.
When sending email our mailserver is now making a direct SMTP connection with whatever mailserver serves the domain in our recipient email address, and is not using any mail relays any more.
>> Many ISPs use clusters of servers and if one of those servers is playing up then there is little you can do about it.
However, we do get our internet access through an ISP, and traceroute / tracert show that there are currently 12 hops required to reach the mailserver we had the problem reaching. Could it be that one or more of the hops was down, and the messages needed to take a longer route (which may have exceeded the max set on Exchange of 30 hops) ?
BTW is max 30 hops enough, or should we increase this setting on Exchange ?
>> It isn't an Exchange error, and as it has your server in the NDR it is occurring on the first hop out of >> the site - which tends to suggest the ISP at fault.
Ah, so the NDR tells you the last domain/IP address you got to before the message "disappeared" ? I
n this case, if our ISP wasn't providing internet access at that time (due to service outages etc.), could that have caused this error message ?
When sending email our mailserver is now making a direct SMTP connection with whatever mailserver serves the domain in our recipient email address, and is not using any mail relays any more.
>> Many ISPs use clusters of servers and if one of those servers is playing up then there is little you can do about it.
However, we do get our internet access through an ISP, and traceroute / tracert show that there are currently 12 hops required to reach the mailserver we had the problem reaching. Could it be that one or more of the hops was down, and the messages needed to take a longer route (which may have exceeded the max set on Exchange of 30 hops) ?
BTW is max 30 hops enough, or should we increase this setting on Exchange ?
>> It isn't an Exchange error, and as it has your server in the NDR it is occurring on the first hop out of >> the site - which tends to suggest the ISP at fault.
Ah, so the NDR tells you the last domain/IP address you got to before the message "disappeared" ? I
n this case, if our ISP wasn't providing internet access at that time (due to service outages etc.), could that have caused this error message ?
If you are sending the email out to the internet using DNS and connecting directly to the remote server, then it will be the remote server that is generating the error. Increasing the hop could should not be required - if something is taking more than 30 hops then there is something badly wrong with routing. Even if I tracert to New Zealand, it is only 16 hops.
If one of the hops was down then the message would sit in the queue.
The NDR tells you which server generated the message. That means in most cases that it was the next hop that rejected the message.
Therefore if your ISP was down then that would not generate that type of message - Exchange would simply fail to deliver the message and you would get a different type of NDR.
This is not a connectivity NDR. Your server was able to connect to the remote server. The remote server rejected the message. Trying to find out what server rejected the message though is not so easy, you would have to look through SMTP logs for IP addresses.
Simon.
If one of the hops was down then the message would sit in the queue.
The NDR tells you which server generated the message. That means in most cases that it was the next hop that rejected the message.
Therefore if your ISP was down then that would not generate that type of message - Exchange would simply fail to deliver the message and you would get a different type of NDR.
This is not a connectivity NDR. Your server was able to connect to the remote server. The remote server rejected the message. Trying to find out what server rejected the message though is not so easy, you would have to look through SMTP logs for IP addresses.
Simon.
ASKER
Ok, I guess its just one of those things then -
Is it the case that all of these 12 hops from our mailserver to the destination server are all SMTP servers in their own right ?
If that's the case, then one of these could easily have been misconfigured / suffered a glitch, that rejected the mail ?
Or are these hops just from IP routers to IP routers, with no higher level processing (e.g. SMTP) taking place ?
Sorry for my ignorance - I'm not an IT techhie by trade, but a recruitment business owner, who used to be a programmer!
Is it the case that all of these 12 hops from our mailserver to the destination server are all SMTP servers in their own right ?
If that's the case, then one of these could easily have been misconfigured / suffered a glitch, that rejected the mail ?
Or are these hops just from IP routers to IP routers, with no higher level processing (e.g. SMTP) taking place ?
Sorry for my ignorance - I'm not an IT techhie by trade, but a recruitment business owner, who used to be a programmer!
The hops will be routers, not SMTP servers. For most sites, there will be between two and four email servers involved.
If you are sending directly then it will be yours and theirs. You could have a server at the ISP involved at either or both ends. By that I am referring to public facing email servers. What happens once the message goes inside is a different matter.
Simon.
If you are sending directly then it will be yours and theirs. You could have a server at the ISP involved at either or both ends. By that I am referring to public facing email servers. What happens once the message goes inside is a different matter.
Simon.
ASKER
Tracert output:
Tracing route to broadsoft.com [130.94.149.229]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms 192.168.1.2
2 225 ms 228 ms 246 ms adsl-bba3.th.eclipse.net.u
3 272 ms 263 ms 262 ms 82.153.2.57
4 83 ms 98 ms 100 ms 251.ge-1-2-3.mpr1.lhr3.uk.
5 176 ms 165 ms 180 ms r20.londen03.uk.bb.verio.n
6 209 ms 228 ms 247 ms xe-0-1-0.r22.londen03.uk.b
7 304 ms 276 ms 195 ms p64-2-1-0.r21.nycmny01.us.
8 122 ms 123 ms 121 ms as-0.r21.asbnva01.us.bb.gi
9 122 ms 124 ms 122 ms xe-1-2.r03.stngva01.us.bb.
10 127 ms 122 ms 123 ms ge-0-0-0.r01.stngva01.us.w
11 123 ms 122 ms 122 ms g-0-2.a0810.stngva01.us.wh
12 122 ms 122 ms 121 ms bdsoft10.vwh.net [130.94.149.229]
Trace complete.
>>>>>>>>>>>>>>>>>>>>>>>>>>
I'm sure theres only one SMTP server our end, and it looks like theres only one their end.
After all they are a big techhie company, with about 10x mailservers (according to the DNSReport on DNSStuff.com), so you'd expect them to be hosting their own servers.
That leaves 2x possibles.
you said earlier that you see this type of error in outgoing mail servers - if there are only 2x, ours is the only outgoing one.
But I'm confused by what you said in a later posting - it looks like this was caused by the 2nd mailserver in the chain -> because our domain was in the RDR error ! ...which points the finger at the broadsoft.com mailserver here...
Also, they didn't get a very healthy report on DNSReport, less heatlhy than ours.
Are we able to point the finger at the destination server yet ?
Tracing route to broadsoft.com [130.94.149.229]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms 192.168.1.2
2 225 ms 228 ms 246 ms adsl-bba3.th.eclipse.net.u
3 272 ms 263 ms 262 ms 82.153.2.57
4 83 ms 98 ms 100 ms 251.ge-1-2-3.mpr1.lhr3.uk.
5 176 ms 165 ms 180 ms r20.londen03.uk.bb.verio.n
6 209 ms 228 ms 247 ms xe-0-1-0.r22.londen03.uk.b
7 304 ms 276 ms 195 ms p64-2-1-0.r21.nycmny01.us.
8 122 ms 123 ms 121 ms as-0.r21.asbnva01.us.bb.gi
9 122 ms 124 ms 122 ms xe-1-2.r03.stngva01.us.bb.
10 127 ms 122 ms 123 ms ge-0-0-0.r01.stngva01.us.w
11 123 ms 122 ms 122 ms g-0-2.a0810.stngva01.us.wh
12 122 ms 122 ms 121 ms bdsoft10.vwh.net [130.94.149.229]
Trace complete.
>>>>>>>>>>>>>>>>>>>>>>>>>>
I'm sure theres only one SMTP server our end, and it looks like theres only one their end.
After all they are a big techhie company, with about 10x mailservers (according to the DNSReport on DNSStuff.com), so you'd expect them to be hosting their own servers.
That leaves 2x possibles.
you said earlier that you see this type of error in outgoing mail servers - if there are only 2x, ours is the only outgoing one.
But I'm confused by what you said in a later posting - it looks like this was caused by the 2nd mailserver in the chain -> because our domain was in the RDR error ! ...which points the finger at the broadsoft.com mailserver here...
Also, they didn't get a very healthy report on DNSReport, less heatlhy than ours.
Are we able to point the finger at the destination server yet ?
If there are multiple servers in the MX records then there is a good chance that one of those is mis-configured. You need to work out which one it is. SMTP logs tied to the time on the NDR may throw some light on it - looking for the IP address to see if it is the same one each time.
However, looking at the MX records for that site, the reason they have so many servers is because they aren't using their own servers. They are subscribers of mxlogic, a major antispam provider.
When you did the reverse DNS records, did you do that locally or did you call your ISP?
Simon.
However, looking at the MX records for that site, the reason they have so many servers is because they aren't using their own servers. They are subscribers of mxlogic, a major antispam provider.
When you did the reverse DNS records, did you do that locally or did you call your ISP?
Simon.
ASKER
I raised a ticket online with our ISP and they created the reverse DNS record for our mailserver (office.altmore.co.uk)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks guys, Sembee/Simon especially.
I came on a real journey of learning along the way, and am a lot more reassured I know what's going on, and that we are unlikely to be doing anything wrong our end, even though we didn't get to a conclusive fix.
This truly is a great site!
I came on a real journey of learning along the way, and am a lot more reassured I know what's going on, and that we are unlikely to be doing anything wrong our end, even though we didn't get to a conclusive fix.
This truly is a great site!
Do you send email directly or via another smart host? The error you have received is usually caused by email going through an outbound server rather than an inbound server.
Simon.