Need Mail and DNS help

I was previously hosting a domain and its mail on my server but recently moved my mail service to Google (Google apps hosting my domain mail). For the outside world, this is working fine. But locally on the box, I cannot send mail to that domain.

When I initiate mail to that domain for one particular address locally, it doesn't fail, it does get delivered locally to a user box that exists on the server - although the mail feature is disabled for that domain.

I also tried to send mail to a user that does not exist on my server, but does exist on the Google mail server and that mail seems to disappear. I don't see a rejection, and it does not make it to the box at Google.

Thanks in advance!

Status: 
Closed (fixed)

Comments

Howdy -- if an email like that is being delivered locally when email is hosted elsewhere, there's a few things to check --

  1. Double, even triple check -- in Edit Virtual Server -> Enabled Features, verify that "mail for domain" is disabled

  2. Where is the DNS for this domain hosted... is it hosted on your Virtualmin server, or at a third party? If DNS is hosted elsewhere, you'd need to disable the DNS feature for that domain as well.

  3. If both the mail and DNS features are setup correctly, and email for that particular domain is still being delivered locally, it may mean there's a stray entry for it in /etc/postfix/virtual. If you look in that file, do you see any references to the domain or account in question?

OK, I hadn't disabled DNS for the domain. But I'm not 100% yet.

After disabling DNS for the domain (and adding Google's DNS to my server's network settings - previously just had 127.0.0.1) I am now able to send email to that domain hosted at Google from my server.

BUT

I have a main account set up at Google with some aliases and every one of my alias email addresses works. The main account does not.

The only difference that I can put together right now is that the main account address did exist on this server previously. The alias addresses that are working have never been set up on this server.

Could there be some kind of cache that is breaking the email delivery now for just this one address?

The messages I try to send now to that one address don't show up anywhere. Nothing is being delivered to the local user directory anymore, and no rejections are being put in any box that I can find.

It sounds like we tweaked the obvious tweaks. So, the next step would be to dig a little deeper, and use the logs to track down where those emails are going.

What I'd recommend doing are sending an email to the account that doesn't work from your server, and then look at /var/log/mail.log. In the mail log, you should see some lines telling you what happened to the email you sent. Do you see any errors or problems in there?

If nothing stands out, feel free to paste the lines in here, we can help diagnose what's going on.

I think I found the error that will clear this up for us.

Apr 5 10:05:13 dviweb postfix/smtp[25327]: 09EE330A0EA0: to=<s.wilson.dvigroup@dviweb>, orig_to=s.wilson@dvigroup.net, relay=none, delay=0.1, delays=0.09/0/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=dviweb type=A: Host not found)

Uh oh... looks like other mail is bouncing now. This email address is valid on this box and has been getting mail until now.

dviweb is the name of this server.

Apr 5 10:09:45 dviweb postfix/smtp[25558]: B243A30A0D8F: to=<terry.tdmiller@dviweb>, orig_to=terry@tdmiller.net, relay=none, delay=0.46, delays=0.46/0/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=dviweb type=A: Host not found)

So are those both examples of email that should be forwarded externally?

If you go into System Settings and run "Re-Check Configuration", does it list any problems? I was wondering if it might list an issue with your hostname not matching the mydestination line of /etc/postfix/main.cf.

You're on to something.

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active ..

BIND DNS server is installed, and the system is configured to use it. However, the default master DNS server dviweb is not a fully qualified domain name.

Your Postfix configuration is missing the system's mail hostname dviweb from the mydestination line, which will cause mail to bounce.

.. your system is not ready for use by Virtualmin.

(btw, I re-enabled DNS for DVIGROUP.NET and ran a restore from yesterday for the DVIGROUP.NET domain - only the BIND feature) Just trying to restore the DNS settings we blew away.

And nothing seems to have changed. I still have the same error in the log.

And no, the examples above were one external and one local to this box. The TDMILLER.NET domain is hosted on this server and mail is hosted on this server. Only the DVIGROUP.NET domain is sent out to Google.

Here are the lines from the postfix config: (copy/pasted - that gap between the commas is in the config file)

myhostname = dviweb.dvigroup.net mydestination = dviweb.dvigroup.net, localhost.dvigroup.net, , localhost

I'm feeling like all this is coming back to my initial setup and my confusion over what to name the box. Everyone told me that using my first domain in my hostname is what I should do, but if I'm not going to host DNS for that domain then does that throw a wrench in the plan?

The hostname command replies with "dviweb" but I could have swore that when I covered this during install that I chose "dviweb.dvigroup.net" as the host name specifically to meet the FQDN rule.

I'm not sure how that all ties in here, but just throwing that out there.

I'm not sure where to go from here... Do I need to fix my FQDN on the server? It sounds like that's broken.

But also, the mail isn't looking for the FQDN, but just "dviweb" and that's the machine name, so am I just missing something in DNS for "dviweb"?

I restored the DVIGROUP.NET DNS zone from my backup as of yesterday - but since that didn't fix it, then I'm not sure where that DNS entry would have been.

OK, so I did these things:

  1. I (re)set my hostname: hostname dviweb.dvigroup.net (and edited /etc/hostname to match)

  2. I added my hostname to my /etc/hosts file 127.0.0.1 dviweb.dvigroup.net

  3. I added "dviweb" to the mydestinations line in the postfix main.conf

I'm not sure when all this changed, or if it was all broken and just waiting to fail... but I'm doing tests now to see what is working and what isn't.

OK, everything seems to be working back the way we started. I'm not sure how the hostname got messed up, but that seems to have fixed things.

HOWEVER

We're back to square one on the original issue. The server is delivering mail locally that I need to go to Google's hosted mail.

Here is the log entry from an attempt:

Apr 5 12:30:00 dviweb postfix/pickup[32698]: 1CC8730A13E7: uid=33 from= Apr 5 12:30:00 dviweb postfix/cleanup[3731]: 1CC8730A13E7: message-id=20110405173000.1CC8730A13E7@dviweb.dvigroup.net Apr 5 12:30:00 dviweb postfix/qmgr[32699]: 1CC8730A13E7: from=<www-data@dviweb>, size=366, nrcpt=1 (queue active) Apr 5 12:30:02 dviweb postfix/local[3737]: 1CC8730A13E7: to=<s.wilson.dvigroup@dviweb>, orig_to=s.wilson@dvigroup.net, relay=local, delay=2.7, delays=0.13/0/0/2.5, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME) Apr 5 12:30:02 dviweb postfix/qmgr[32699]: 1CC8730A13E7: removed

It looks like something is still telling the server that dvigroup.net mail is hosted locally so it's re-writing the destination address and delivering locally.

However, here is another address at that same domain that gets sent out correctly:

Apr 5 12:38:17 dviweb postfix/pickup[32698]: 1D07F30A13E7: uid=33 from= Apr 5 12:38:17 dviweb postfix/cleanup[4584]: 1D07F30A13E7: message-id=20110405173817.1D07F30A13E7@dviweb.dvigroup.net Apr 5 12:38:17 dviweb postfix/qmgr[32699]: 1D07F30A13E7: from=<www-data@dviweb>, size=361, nrcpt=1 (queue active) Apr 5 12:38:17 dviweb postfix/smtp[4587]: 1D07F30A13E7: to=edu@dvigroup.net, relay=ASPMX.L.GOOGLE.COM[74.125.159.27]:25, delay=0.67, delays=0.12/0/0.19/0.36, dsn=2.0.0, status=sent (250 2.0.0 OK 1302025097 q34si15767418ybk.93) Apr 5 12:38:17 dviweb postfix/qmgr[32699]: 1D07F30A13E7: removed

I'm glad you fixed up the issue with bouncing emails!

Now, as far as this other part goes -- did you get a chance to look in /etc/postfix/virtual to see if that one email account shows up in there anywhere? If somehow, a stray line was left in there regarding that one account/address, it's possible that could be causing some trouble.

That was it. Now that I'm in here actually I see a lot of cleanup that can be done. I've never hosted mail for some of these domains so I'm turning off the mail service and I can clean up all these extra mappings and DNS entries.

On the subject of DNS though... I'm using GoDaddy for my DNS, so is there any purpose for having BIND even installed on my machine? Will Virtualmin run without BIND?

On the subject of DNS though... I'm using GoDaddy for my DNS, so is there any purpose for having BIND even installed on my machine? Will Virtualmin run without BIND?

I would suggest keeping BIND running to act as a DNS cache, even if you aren't using it for hosting domains. Though, at that point, you can go into Server Settings -> Features and Plugins, and disable the BIND DNS feature. Then, BIND will still be handling your DNS lookups, but not actually storing DNS zone data for your domains.

OK, maybe I'll do that then. One by one remove the mail and DNS features from the domains I have now and clean up the virtual aliases. Then as long as that goes well then disable those features at the system level.

Only a couple domains on my box are hosting mail and those are going to be tranfered over to a Google Apps account soon. I just want to make my data footprint smaller - not for the hard drive concerns, but the backup files and moving them offsite concerns. Moving a 5G backup file every day is horrid. But without mail my backup of 12 domains is only 200M.

Thanks for your help. Consider this thread closed.