(More) Mail Problems

[andyorourke]

I just ran DNS report at dnsstuff.com and found this message:

WARNING: One or more of your mailservers may be claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won't cause any harm, but may be a technical violation of RFC821 4.3 (and RFC2821 4.3.1).

xxxxxxxxxx.net claims to be host server1.yyyyyyyyyyyy.com.

Now xxxxxxxxxx.net is hosted on server1.yyyyyyyyyyyy.com but it does have its own IP address, does it not have its own mail server? if not is there a way to change the greeting for xxxxxxxxxxx.net?

I know it is only a 'technical' violation but in this day and age, considering I run large opt-in mailing lists I am trying to make my servers as compliant as possible

Any help or advice welcome

[chirpy]

They're wrong, it's not a violation, that's how an MTA is supposed to work - it responds with the hostname of the server. MTA's were not written with virtual hosting in mind, and there's little you can or need to do about it.

[procam]

They're wrong, it's not a violation, that's how an MTA is supposed to work - it responds with the hostname of the server. MTA's were not written with virtual hosting in mind, and there's little you can or need to do about it.

Booo kaka - Then its time we start re-writing code to suit the times!
If everyone starts jumping up and down about it change will take place!

As a company owner that hosts a ton of virtuals I for one do not want joe blow {or mary poppins} signing up for service and checking his/her dns report and seeing a little yellow warning on their domain tomorrow and picking up the phone to call me and hollar we dont know what we are doing here - and thats exactly what happens - some of the aoheller;s that host sites and other "concerned folks" can have and will ring to tell us theres a dns problem when in fact there is not......
I sent an email to the nice people at dnsstuff to see about possibly just fixing the tool to report it differently but changing the rfc code seems like maybe a better solution-
Ultimately sending the mail as the actual host/domain would be my personal favorite but I somehow dont see anyone recoding exim to manage that problem from that direction.

[dezignguy]

simply change the domain's MX entry to be the server's hostname. Easily solved.

[dnsstuff]

They're wrong, it's not a violation, that's how an MTA is supposed to work - it responds with the hostname of the server. MTA's were not written with virtual hosting in mind, and there's little you can or need to do about it.

The www.dnsreport.com site isn't wrong. It is 100% accurate.

Specifically, it generates a *warning* not an *error*. An error indicates that there is definitely a problem, whereas a warning indicates that something *may* be wrong, or the problem is *minor*.

In this case, there is nothing wrong. The mailserver is responding properly. The DNS report just checks to see if the hostname shown matches one that the DNS report knows is associated with that MX record (the domain being looked up, or the name in the MX record). If not, it generates that warning.

Just so long as the hostname it claims to be has an A record pointing back to the same server, you are RFC compliant.

The test was written specifically for people running a broken mailserver that always reported the hostname as X1, and a broken firewall (Cisco PIX) that says that it is something like "*****2****0***".
-Scott

[chirpy]

Sorry, that's silly. It's not 100% accurate at all. If it were it would know that the statement "it may be a violation" is a load of rubbish, since is not a violation and there is nothing wrong. At the very least it is extremely mis-leading, especially to less technically minded people. It should probably say something like "I cannot test this bit properly so I cannot say whether there is a problem or not. If there is then this is the reason XXX, if not, then you can check by doing YYY.".

[dgbaker]

I have to agree, the dnsreport info can be and is very misleading. Unfortunatly it may be like a lot of things where the people that wrote/designed it forgot to take into account the lowest common denominator (sp?) of the audience that may use it.

Most general users when viewing the result screen will be alarmed when they see even a "warning". As Jonathan said, elimitating or changing these to not be false warnings would help a great deal. Oddly enough even dnsreport.com shows that warning even for it's own domain.


BTW- I love the part about "The test was written specifically for people running a broken mailserver ". Geez I would have thought you would do it right and force the broken things to be corrected. Talk about doing things backwards and wrong. Also if that is the reason for the test, then only show it when that is true instead of giving false positives.

[procam]

At the very least it is extremely mis-leading, especially to less technically minded people. It should probably say something like "I cannot test this bit properly so I cannot say whether there is a problem or not. If there is then this is the reason XXX, if not, then you can check by doing YYY.".

And this was exactly my point ~ since dnsstuff has become such a popular tool {and thats a good thing}
Some of the people who should not necessarily have access to it do and they use it as a weapon - I understand both viewpoints but facts are facts - and those cannot be argued -

Yes the tool is right BUT....... the information its providing on this particular item is misleading to the novice setting up service with a new host - and causing unnecessary support tickets - If you havent got one yet rest assured you will!


I tend to agree with chirpy - Esplain it in more detail or 86 the test in the event of this warning and simply say I cannot complete this test - Please there has to be a better solution than just leaving it as is. That big yellow WARN - its like putting up the mark of the beast in front of a southern baptist chrurch to some clients.

I do appreciate everyones attention to this - I know I do not stand alone with complaints about this issue.

[dnsstuff]

It should probably say something like "I cannot test this bit properly so I cannot say whether there is a problem or not. If there is then this is the reason XXX, if not, then you can check by doing YYY.".

FYI, the text is going to be changed to make it more clear that there may not be an error, and it will explain how to tell if there is truly an error or not.
-Scott

[chirpy]

Good stuff

[dnsstuff]

That big yellow WARN - its like putting up the mark of the beast in front of a southern baptist chrurch to some clients.

I do appreciate everyones attention to this - I know I do not stand alone with complaints about this issue.

You've convinced me.

I've updated the code to check the A record(s), to make sure that there is an A record pointing back to the IP of the mailserver.

This will take effect when the site is next reloaded (probably tomorrow morning).
-Scott

[ddmobley]

Apparently this is still broken, at least to virtual sites that are not sharing the primary IP address of the server. I still see "This is also a technical violation..."

>> mail.cherokeepecan.com claims to be host host.brainstormlabserver.com [but
>> that host is at 216.130.244.178 (may be cached), not 216.130.244.180].

The primary IP address of the machine is .178, while the shared IP of the virtual sites is .180. What should be happening here? I don't think all of the virtual sites should have to use the same IP address as the main server just to clear this warning.

Any ideas here people?