Required www
-
@Z1_Jacob said:
According to whois, the domain was registered in 1986.
DARPANet predated even DNS going back to the late 1960's which is the time frame I am referring to. I had access (under close supervision) from 1969 - 1973. There were only 6 or 7 east-coast universities that were primary join points (accessible by defense contractors primarily).
ps:I really wish my historical documents were not all in storage units nearly 100 miles away - such is the result of moving from the burb's into the big city.
-
In order for e-mail to get delivered, a domain must have an MX record. There's a strange problem that affects mostly Hotmail and Gmail, but occasionally Exchange as well, where the sending mail system can't find the MX record for a recipient's domain. I don't know if it's just a DNS timeout, but the sending mail system assumes that the failure is due to no MX record existing. (I can't imagine what sort of stupidity would cause so many DNS systems to report NXDOMAIN for valid, extant MX records.)
The mail system, believing there to be no MX record at all, under this flawed information validly falls back on the @ A RR instead.
If the @ A RR points to the web server, this would work. However, the @ A RR needs to point to the web server so that people get to omit the "www" in the address and still bring up the website. This results in the web server randomly receiving mails it doesn't recognise, frequently for days at a time when Hotmail or Gmail has gone down the tubes. The web server rejects the message, and Hotmail and Gmail both fail to report the identity of the rejecting server, so mails start getting randomly rejected from an unidentified server (the only reason this is clear is because you'll often get a UNIX-like response from what should be an Exchange server, so whatever isn't taking the mail, isn't the server that it should have gone to.)
This is with both GoDaddy's and eNom's nameservers for the affected domains, so DNS failure seems highly unlikely.
This is all in the name of making it possible to omit "www". It would be nice to not feel like I'm the only person who's ever discovered this problem, but most problems in IT seem to only exist in my imagination.
-
@Daniel Beardsmore said:
In order for e-mail to get delivered, a domain must have an MX record. There's a strange problem that affects mostly Hotmail and Gmail, but occasionally Exchange as well, where the sending mail system can't find the MX record for a recipient's domain. I don't know if it's just a DNS timeout, but the sending mail system assumes that the failure is due to no MX record existing. (I can't imagine what sort of stupidity would cause so many DNS systems to report NXDOMAIN for valid, extant MX records.)
There are two reasons why many valid email domains return an NXDOMAIN when looking up their MX record. Firstly, MX records are not required for email delivery - an A record works just fine. It's what I use for my home domain, and it's what they use on my fan site. Secondly, most DNS queries and responses are sent via UDP, which is not a reliable transport. This *should* generate a SERVFAIL response, but there's at least one buggy DNS server version that will correctly pass the SERVFAIL on to the requesting client, but then it caches an NXDOMAIN response for the negative TTL duration. I've had to code around that more than a few places.
@Daniel Beardsmore said:
The mail system, believing there to be no MX record at all, under this flawed information validly falls back on the @ A RR instead.
Apparently, you understand that an MX record isn't required. Why did you start off with saying it was?
@Daniel Beardsmore said:
If the @ A RR points to the web server, this would work.
That's awesome - the A record also needs to point to the web server for the web to work.
@Daniel Beardsmore said:
However, the @ A RR needs to point to the web server so that people get to omit the "www" in the address and still bring up the website. This results in the web server randomly receiving mails it doesn't recognise, frequently for days at a time when Hotmail or Gmail has gone down the tubes.
Wait. I'm confused. Or you are.
I think, what you need here, is an email configuration on the web server that will relay messages to the email servers. Or, better yet, you can run a stub proxy in front of the MTA software on the web server, that recognizes email intended for the email server, and opens a second socket to the email server to send the message the right place. That way, it all works seemlessly, and there's never any extra received headers or anything. I've used this a few places, and it always works quite well.
That having been said, I've also been places that handle that issue by having the web servers not accept email connections from outside their network. That configuration only works well if the problem causing the foreign email servers to try to talk to the webservers is intermittent. If the condition lasts for days at a time, then email bounces because it wasn't accepted in a week or whatever.
-
I think, what you need here, is an email configuration
Or just apply Occams' Razor, and require the "www" for accessing the Web site(s), and ignore e-mails that are sent (incorrectly) to "www....."
-
@TheCPUWizard said:
I think, what you need here, is an email configuration
Or just apply Occams' Razor, and require the "www" for accessing the Web site(s), and ignore e-mails that are sent (incorrectly) to "www....."
I don't know about e-mail being sent to the www host due to a www in the address, although it follows that it will happen. What does happen is that a lot of mail is sent to the @ A host due to the amount of people who can't design, program or maintain working DNS servers. DNS servers that cache SERVFAIL and NXDOMAIN are also extremely irritating, especially the former. How can you cache SERVFAIL for hours? But people do.
And yes, Who_the_Fuck, you are correct – MX records aren't required. However, if one exists, SMTP servers must use them. What I don't understand is the alarming frequency at which the MX record is not available, but the @ A record is. Surely if DNS is playing up, both records would be equally unavailable?
The web server does indeed have a text file listing all the domains it needs to relay for to work around this. The worst case was a web server that wasn't under our control, so instead of convincing the web host to relay mail, I figured out how to configure IIS on the Exchange server to redirect web requests to the www host instead. IIS isn't fun to work with …
Yes, it would be easier if I didn't feel a need to ensure that omitting "www." was always supported.
