On 04/16/2015 09:54 AM, Carl Hartung wrote:
On Thu, 16 Apr 2015 09:27:52 -0400 Anton Aylward wrote:
Personally I don't think the "try MX first" is a good strategy.
Hi Anton ... am enjoying watching this thread. :-)
Just a quick couple of comments here (from my work) ... I recently published a website by simply changing the A record IP address and was bitten by the Implicit MX rule:
http://www.openspf.org/FAQ/Implicit_MX_rule
Not explicitly designating mail exchangers effectively locks the routing of mail to the A record IP address. If you have no mail services running there, the sender will retry until the defined permanent delivery failure state is reached and sending just fails. At least, this is my experience.
I don't find anything odd about that. In the early days of the 'net, say around 1990, there were many sites with just one machine, one A record. They had all the needed services running there. In fact one of the problems was that many vendors, not least of all the small systems vendors doing "UNIX for the PC" type thing shipped with ALL network services turned on, bot just SMTP and Gopher (http was just emerging) but TFTP, TELNET, FTP and other ones that represented security issues. Sites were raw on the backbone, not firewalls to internal subnet, no IPtables, no IP filtering. Zone transfer was unsecured. Most SMTP servers were open so relaying wasn't a problem. We've shut down many of those problems, but not completely. If you primary host, the one that the A record points to, did not then have SMTP running you couldn't receive mail. I would think that still holds today. If you MX record points to a proper mail-bub, that is your domain has 'dedicated' machines (or addresses or names) for services such as www.xxx, smtp.xxx mail.xxx and so on) and they are configured for processing those protocols that is one thing. But MX doesn't mean that. Back in the antediluvian days of DNS there were MD (mail destination) and MF (mail forwarder) records. M combines the two. Sort of. There is no guarantee that MX means MD. I can quite reasonably have a MX record for a site in Australia: different tectonic plate, different power grid. If California, where @antonaylward.com is hosted, goes brown, mail to me will still be accepted and will, hopefully, get through when power/connectivity comes back. If California slides off into the pacific for good then I, along with many others, can get a new service, somewhere better landlocked perhaps, have the master records at the root servers reset and the mail queued for me in Australia will then be forwarded. This is prety much how things were eventually conceived. The idea of a real single host on the net without a SMTP server seems ... Strange. But then Microsoft and the PC came along. Gates had a different idea. let me repeat: There is no guarantee that a MX host is a mail processor rahter than a mail forwarder. It might be a gateway. A hypothetical example" If I send mail to Joe.Blocks@hp.com that will end up at Joe.Blocks@rdlab14.faversham.uk.hpinternal.intranet And "hpinternal.intranet" is not addressable in any shape or from the Internet. Here we have a MX site for hp.com acting as a gateway to the private internal network. Part of the matter here is that you don't know from the outside what the MX host is. It might be a destination. It might now. Your problem, I think, was having a primary host that couldn't process your mail when you turned off the MX hosts. Oh, and there's no reason why a MX host couldn't have a sophisticated algorithm. My MX host in Australia in the hypothetical example above could, if a another destination wasn't restored within 15 days, forward my email via SMS ... Or something. Or to an alternative account. Or something. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org