Fowarding account on a subdomain

Hi
I have set up a sub-domain (sub.ourdomain.net) and I am trialling Google Apps on it (with 1 account so far).

I have had a forwarding account set up on my Exchange mailbox (@domain.net) to this trial account (@sub.domain.net).

I can send from both accounts but the forwarding does not seem to be working at all.  More bizarrely, any external email (i.e. outside either domain) sent to my Exchange account results in some odd behaviour:

1) I receive the email at my Exchange account
2) It is not forwarded onto my subdomain account
3) The external sender also receives a message "550 5.7.1 unable to relay for user@sub.domain.net"

Is this related to the fact it is a subdomain account and Exchange is getting all upset?

Hear from you soon
stillspangleAsked:
Who is Participating?
 
Jian An LimConnect With a Mentor Solutions ArchitectCommented:
try this.
on your exchange server
can you try to run command

nslookup
set type=mx
sub.domain.net



can you tell me the result?
i wonder where is it pointing to.


i wonder when the exchange server pick it up as it own and decided not to forward it to outside but look inside..
0
 
stillspangleAuthor Commented:
or has InterScan MSS Notification got somethign to do with it?
0
 
Jian An LimSolutions ArchitectCommented:
my question will be the mx record

tell me what is your mx record for sub.domain.net

regardless of your current domain.net, it should send the email to sub.domain.net not domain.net


try to get it from http://www.mxtoolbox.com/ 

0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
stillspangleAuthor Commented:
Hi, limjianan

The MX records for the subdomain are:
Preference      Host Name      IP Address      TTL              
10      aspmx.l.google.com      209.85.217.44      21600            
20      alt2.aspmx.l.google.com      209.85.201.114      21600            
20      alt1.aspmx.l.google.com      74.125.45.27      21600            
30      aspmx5.googlemail.com      74.125.45.27      21600            
30      aspmx4.googlemail.com      66.249.93.27      21600            
30      aspmx3.googlemail.com      209.85.199.27      21600            
30      aspmx2.googlemail.com      209.85.135.27      21600

These are defined by Google.

The MX records for the principle domain are a couple pointing to Messagelabs

Hope to hear from you soon
0
 
Jian An LimSolutions ArchitectCommented:
okay.

but that's going to be odd.

The external sender also receives a message "550 5.7.1 unable to relay for user@sub.domain.net"

do you mean let's say a gmail account user cannot send email to user@sub.domain.net?

or external sender receive a message of above when he send to user@domain.net and get the above message?



by default, user should able to send and receive email if he go in to user@sub.domain.net




If this is the case, you need to work for your internal @sub.domain.net as the internal DNS might have some issues ..
0
 
stillspangleAuthor Commented:
Hi, limjianan
Thanks for your input so far.

It is the second part of your question that happens
(you said: or external sender receive a message of above when he send to user@domain.net and get the above message?).

What I mean is this:
  1. An external account (say, hotmail or gmail) emails me@domain.net
  2. Our Exchange Server is 'supposed' to forward this on to me@sub.domain.net (which it doesn't for any type of incoming message, internal or otherwise)
  3. The sender in 1 above gets that 'unable to relay' message (see attached snippet)
(I just tried this with a gmail account to domain.net)


If I send directly 'to' sub.domain.net there is no problem.  I can also send 'from' sub.domain.net.

Hope this helps
Thanks again

****** Message from InterScan Messaging Security Suite ******
 
 
Sent <<< RCPT TO:<me@sub.domain.net>
Received >>> 550 5.7.1 unable to relay for me@sub.domain.net
 
Unable to deliver message to <me@sub.domain.net>.
 
************************     End of message     **********************

Open in new window

0
 
Jian An LimSolutions ArchitectCommented:
also you can try to create routing connector
put in the smtp address into it
and tick allow messages to be relayed to these domains
0
 
stillspangleAuthor Commented:
Hi
Sorry I've not been in touch...staff disruption!
Will be in touch v. soon

:)
0
 
stillspangleAuthor Commented:
Hi
Me again...you've probably moved  on (quite rightly) but I'll update you anyway...


The NS lookup from our front end Exchange server showed 212.53.89.138 - this relates to the A record for sub.domain.net (set up in Netnames)

I'm having problems convincing my Network Manager that the problem isn't related to Google Apps but with the way our Exchange server is handling this subdomain email.

He is convinced the problem lies with Google (Apps).  I am not so sure but do not have the expertise to provde otherwise.


I hope you're still monitoring this question.  I have 'upped' the points, too
Thanks
stillspangle


0
 
Jian An LimSolutions ArchitectCommented:
the problem lies in exchange server for sure.

if an external user can send the email to <username>@sub.domain.com , that means the internet handling it correctly.

you can also try to send email from <username>@domain.com to <username>@sub.domain.com and it should failed to ..

so it is lies in exchange server handling the the email.
by default, since it is a subdomain email, exchange will think the email should flow internally not externally.


0
 
stillspangleAuthor Commented:
Thanks.  I passed on your comments to my NM who appears to be a little more receptive (I referred to your status in this cateogry!)

He has asked me how to make Exchange treat the subdomain messages as ones that should be delivered outside our domain.

I'm not sure if that's straightforward to answer, but hope to hear from you soon.
stilspangle

0
 
Jian An LimSolutions ArchitectCommented:
i just check with google apps, it seems it has something like this

http://www.google.com/support/a/bin/answer.py?hl=hr&answer=96855

and you are right, exchange should able to response correctly,

however, the error message is generate from InterScan Messaging Security Suite

I am thinking is more to the InterScan Messaging Security Suite issue?


I am not sure until now... let me request for more help here.
0
 
stillspangleAuthor Commented:
Hi again
Thanks, I've seen that article before.  I'm not sure that's what I'm looking for as I am not interested in Dual Delivery.  I was expecting sub.domain.net to behave as if it were a completely independent domain (e.g anotherdomain.com) and simply using Google Apps as the front-end for emails.  Does that make sense?

We had an earlier trial, with selected users, using our principle domain.  In this, we employed Dual Delivery where we had to update our MX records so that every email passed through Google and it 'simply' passed on the emails not provisioned in Google Apps onto our Exchange server (i.e. trial accounts got delivered to Google, others got forwarded on).  However, we were getting 'too many messages trying to be sent' errors and Google acknowledged it had an issue with this set-up.  This is well-documented in the Google Apps Admin Forum.

To revive the potential of using Google Apps, I set-up this sub-domain to preserve the domain quality of the accounts.  i.e. user@sub.domain.net rather than user@anothersimilardomain.net


I still really appreciate the fact that you kept monitoring this question despite my long absence from contributing to it.
0
 
tntmaxConnect With a Mentor Commented:
So when you did an mx lookup from the parent domain server, it returned an A record of 212.xxxx instead of one of the gmail mx records. Did you manually setup this mx record in dns? Is the relay error coming from the exchange server or from gmail?
0
 
stillspangleAuthor Commented:
Hi, all
It appears that my NM has resolved this issue.  He told me that there were a number of A records (e.g. sub.domain.net, www.sub.domain.net) including mail.sub.domain.net that all pointed to the same IP (212.xxx).

Apparently, removing these was the answer.

If I assume he  is right, have either of you offered the advice for this solution?  I don't know enough to be sure that the advice you gave led to him solving this problem.

However, I am also much more than willing to offer these points (as a commensurate split) for your sheer endurance in helping me with this.

Hope to hear from someone soon so that I can end this question (for you, as much as me).
Kind regards
Stilspangle
0
 
tntmaxCommented:
I'd be fine with a points split. I was going to say the next step would be to delete them as they were there manually....
0
 
stillspangleAuthor Commented:
I have used EE for a number of years now (back in the days when there was a free sign-up!).  This continues to be an excellent resources.

Thank you experts and thank you Experts Exchange.
0
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.

All Courses

From novice to tech pro — start learning today.