hello all - this should be simple, but has me stumped (which seems like its pretty easy to do)
i wish to set up a virtual-server that merely forwards email go a gmail account.
when i check the "Accept mail for domain?" checkbox, and then i go into the "Server Configuration -> DNS records" i get a big red warning:
Warning - errors were found in this domain's DNS records : This domain has email enabled, but none of the MX records point to it. Either the MX records should be corrected, or the email feature disabled if mail is hosted externally.
however, when i leave the "Accept mail for domain?" unchecked, i get this virtual-server failure message:
Error
Failed to create virtual server : A default mail forwarding address can only be entered if mail is enabled
so, could i please be provided with simple instructions on how to create a new virtual-server that just forwards email?
thank you all - i very much appreciate the help !
Howdy,
Well, both errors are correct.
If you want your server to handle email for a Virtual Server (even if it's to forward it elsewhere), you'd need to have both Mail enabled, as well as for the MX records to point to your server.
If you want all email to go to another server -- then you'd leave the mail feature disabled, and point the MX records to your mail server.
If you're using just a single Gmail account, something like "foo@gmail.com" and not a Google Apps account, then what I'd recommend is to leave the MX records pointed to your server, enable the Mail for Domain feature, and then setup your forwarding to push your email to foo@gmail.com.
-Eric
hello Eric -
sadly, google recently eliminated the free google-apps email (unless somebody knows a good alternative)
here is what i did (please see attached):
i created a virtual-server with the mail checked (see attached virtualmin-setup-1) but then i get that error message (please see attached virtualmin-setup-2)
i KNOW I am missing something very simple and yet very obvious....
and thank you for helping me!
Howdy,
Is your server by chance behind a NAT router... meaning that your server would have an IP like 192.168.x.x as it's main IP?
Also, if you go into Server Configuration -> Re-Check Config, does it notice any problems there?
-Eric
found re-check under "system settings" ;-)
i seemed to get a clean bill of health, but i still get the dns error (please see dns-error.png)
ideas?
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 .. Your system has 947.31 MB of memory, which is at or above the Virtualmin recommended minimum of 256 MB. BIND DNS server is installed, and the system is configured to use it.
Mail server Postfix is installed and configured.
Your Postfix version does not support per-domain outgoing IP addresses.
Apache is installed.
Webalizer is installed.
Apache is configured to host SSL websites.
MySQL is installed and running.
ProFTPd is installed.
Logrotate is installed.
SpamAssassin and Procmail are installed and configured for use.
ClamAV is installed and assumed to be running.
Plugin DAV Login is installed OK.
Plugin AWstats reporting is installed OK.
Plugin Mailman is installed OK.
Plugin Protected web directories is installed OK.
Using network interface venet0:0 for virtual IPs.
IPv6 addresses are available, using interface venet0:0.
Default IP address for virtual servers is 69.10.48.25.
Default IP address is set to 69.10.48.25, which matches the detected external address.
Quotas are not enabled on the filesystem / which contains home directories under /home and email files under /home. Quota editing has been disabled.
All commands needed to create and restore backups are installed.
The selected package management and update systems are installed OK.
.. your system is ready for use by Virtualmin.
Are you sure the attached screenshots reflect your latest test? The re-check-configuration screenshot shows an error with your AWstats installation, which the text in your post doesn't.
In any case, I cannot find a problem in the dns-error screenshot you attached, so I wonder why Virtualmin would report the error. It's possible, like Eric said, that it thinks the IP address doesn't match the one which is assigned to the "aaaaa.com" virtual server. You might want to double-check that.
You can see your IP addresses by running the command "/sbin/ifconfig". Virtualmin would be using those to determine what IP's are on your system.
-Eric
It looks like one of your updates did indeed have the ifconfig output in it, and that does look correct. I also overlooked the default IP address mentioned in the output above :-)
I may just need some more coffee.
But in any case, could you attach a screenshot of the screen in System Settings -> Virtualmin Config -> Network Settings?
I'm curious how that looks.
-Eric
hey boys and girls - i am not saying you guys were right or i that was wrong (lets let the facts speak for themselves)
i did put on the wrong screen-shot earlier (sorry) so no need for more coffee. if that coffee came from starbucks, supposedly it said "come together" on the cup, as we sail over the fiscal cliff.
but as you can see from the screenshots below, i merely had to change a newly created virtual-server from mail.ilovevirtualserver.com. to something with my own ip number (04-bind-fixed.png) and the error message went away. ;-)
if this is the solution, i am happy as a "republican with a spending cut". but i cant help but wonder if this is a symptom of a much deeper problem.
ifconfig shows 69.10.48.25
any ideas?
Your "fixed" MX record is incorrect... MX records must point to hostnames, not IP addresses. Can you post the contents of the zone (click "Edit manually") please?
hi Locutus -
i think i might know what my problem has been all along (besides being overly handsome) - that being we cant just make up a virtual-server name as an example!
in other words, the domain has to actually exist.
if you get a moment, could you pls. do me a favor? try making up a fake virtual-server name, and see if you get the same error i do.
if you follow my example at "server-create.png" you might see the same error message i did at dns-records.png - but compared to "fixed.png" all the records match. the only difference is that the domain name referenced in fixed.png is real, and the other is obviously faked.
Unfortunately I cannot reproduce your issue. I can create a dummy server "ilovevirtualmin.com" just fine and am not getting the red error message.
I also wouldn't know why that domain name should be the issue. Virtualmin doesn't distinguish (or even know about) "fake names" and "real names". It just creates what you tell it to.
When you go to "Limits and Validation / Validate Virtual Servers" and run that, do you get any errors?
Also, can you please as I requested post the contents of the allegedly erroneous zone file?
Also also, can you please post the FULL error message you see on the DNS records page? I'm just taking a look at the Virtualmin source code, and trying to figure out how this check works. The error message should be something like "This domain has email enabled, but none of the MX records $1 point to it. Either the MX records should be corrected, or the email feature disabled if mail is hosted externally." with $1 being replaced with the list of MX records it found.
Locutus - you have earned yourself a free dinner!
I also wouldn't know why that domain name should be the issue. Virtualmin doesn't distinguish (or even know about) "fake names" and "real names". It just creates what you tell it to.
i wondered about that too, but i thought i was making progress!
When you go to "Limits and Validation / Validate Virtual Servers" and run that, do you get any errors?
same error, but you can see it at validate-virtual-servers.png
Also, can you please as I requested post the contents of the allegedly erroneous zone file?
its below and in a screen shot edit-dns-records.png
$ttl 38400 @ IN SOA ns1.edwardsmarkf.com. root.ns1.edwardsmarkf.com. ( 1356647430 10800 3600 604800 38400 ) @ IN NS ns1.edwardsmarkf.com. ilovevirtualmin.com. IN A 69.10.48.25 www.ilovevirtualmin.com. IN A 69.10.48.25 ftp.ilovevirtualmin.com. IN A 69.10.48.25 m.ilovevirtualmin.com. IN A 69.10.48.25 localhost.ilovevirtualmin.com. IN A 127.0.0.1 webmail.ilovevirtualmin.com. IN A 69.10.48.25 admin.ilovevirtualmin.com. IN A 69.10.48.25 mail.ilovevirtualmin.com. IN A 69.10.48.25 ilovevirtualmin.com. IN MX 5 mail.ilovevirtualmin.com. ilovevirtualmin.com. IN TXT "v=spf1 a mx a:ilovevirtualmin.com ip4:69.10.48.25 ?all"i hope you dont get tired of me expressing my gratitude to you!
I can tell you my Paypal address, for that free lunch thing! ;)
Okay, I did some more testing and source code digging, and it seems that in your case, when the error message doesn't list any MX records, that is because the check function did not detect any MX records that point to the right domain.
Another error case would be that the MX record points to the correct hostname, but that doesn't point to the right IP. In that case the MX record would get listed in the error message though.
Here's the Perl code snippet that tests each DNS record if they are a valid MX record pointing to your domain.
local @mxs = grep { $_->{'name'} eq $d->{'dom'}.'.' && $_->{'type'} eq 'MX' } @$recs;The code then proceeds to check each found record in "@mxs" if they point to the correct IP of your system. But that part of the code isn't reached, since it would have output a list of each MX record name being checked in the error message. Since that list is empty for you. the check above didn't find any records.
I'm not really proficient in Perl, but as I read it, what that check does is: Is goes through all entries in the zone file and extracts those whose name equals the domain plus a "dot", and whose type equals "MX". I'm guessing that the $d record holds the contents of the domain configuration file.
Can you please go through your directory "/etc/webmin/virtual-server/domains", search the numbered files there for the one that corresponds to your "ilovevirtualmin" domain, and paste its contents here? (Attention, it contains the domain's password! X that out.)
That's the last thing I can check before we have to alert Jamie so that he can take a look at the code himself. He of course knows best how this stuff works and why the MX grepping might not match correctly. Since it did work when you earlier changed the hostname to an IP address in the MX record, it's possible that it is some bug in the grepping procedure.
Locutus - like it or not, you are my new best friend!
here is the file you requested:
Okay, nothing out of the ordinary in the domain config file.
Can I maybe do some tests on your domain directly? Via Teamviewer e.g.? Or can you give me a login to Virtualmin and SSH?
Aside from that we'd need to let Jamie take a look at this; I have at this point no explanation why the MX check fails.
I can tell you my Paypal address, for that free lunch thing! ;)
He definitely said dinner... that implies steak and a good beverage :-)
If you aren't seeing an immediate cause for Virtualmin's warning, I can get Jamie involved, he may have some ideas as to why that could occur.
-Eric
Either works for me..... mark at edwardsmark dot com
Oh right, dinner. Fine with me! :) Yeah better get Jamie. I suppose he'll figure this out faster.
i can give you guys the password if you want over email:
mark at edwardsmark dot com
I shot Jamie an email describing the problem, let's see what he has to say... I'll let you know once I hear back.
-Eric
Jamie said that Virtualmin determines where the MX record points not by looking at the zone file, but by performing a DNS lookup.
So, if there were a DNS problem, that could cause the issue you're seeing.
If you log in on the command line of your server, what is the output of this command:
host mail.ilovevirtualmin.comThat should provide the IP address of your server.
-Eric
I don't think that's the reason. In this case the list of discovered MX records, which is shown in the error message, would not have been empty, as it is the case here.
Out of curiosity, what is the output of the command "cat /etc/resolv.conf"?
I do appreciate Locutus's point on all this, though I'm curious where that rabbit hole leads since the host command didn't return a response :-)
-Eric
Hmm! Interesting rabbit hole indeed. :)
While I still fail to see how that DNS resolution problem is connected to MX record matching error, it is sure possible, even likely, that there's a connection I can't know. :)
In any case, it is certainly an error if the Virtualmin server cannot resolve the domains that are hosted on itself. First thing you need to do is remove the "nameserver 66.45.228.250" line from your resolv.conf, or at the very least move it AFTER the "127.0.0.1" one, so that the local BIND is used FIRST.
Fixing that MIGHT also fix the original MX record problem.
While I still fail to see how that DNS resolution problem is connected to MX record matching error, it is sure possible, even likely, that there's a connection I can't know
Well, remember that Jamie mentioned Virtualmin doesn't look at the zone file, but instead uses DNS lookups, to determine what matches.
So if DNS lookups aren't working for some reason, any attempt Virtualmin makes to match the records would fail.
-Eric
but instead uses DNS lookups, to determine what matches.
one would think that a "fake" domain name would have the same result on any installation. but i have no doubt there is something off with my installation. remember, i have sat down several times with the dns-bind book to read it but never got very far.
I'd try the advice Locutus mentioned above and see if that helps your situation.
-Eric