Talk:MX record

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the MX record article.
Article policies

Contents

[edit] distance

Regarding the priority of selecting mail servers, I am unclear what "the shortest distance" refers to. But, according to http://www.han.com/dns.html, the mail server with the lowest priority number is selected first.

"Distance" is Dan Bernstein's word for what the IETF calls "Priority". I've updated the article to clarify. — mendel ☎ 00:49, Jun 16, 2005 (UTC)

[edit] location for MX records

Suggestion from little old me: maybe list the standard default locations for MX Records. I viewed this article in an attempt to figure out where Apache hides the MX records.

Apache doesn't store MX records (so it does not hide them either). Read the fine documentation of your nameserver. Erik Warmelink 20:49, 5 July 2007 (UTC)

[edit] external link to harvesting site

the external link: "MX Record Lookup" appears to be an email harvesting site. It insists on a full email addy (not just a domain) before providing an MX record lookup.

Which link are you referring to? I tested them all and I could not find one that insisted in getting a full email address.

[edit] maximum priority value

I don't know how accurate the info is, but I was trying to find the maximum priority value... the only reference I could find was http://www.petri.co.il/configure_mx_records_for_incoming_smtp_email_traffic.htm and this said it's 0 to 65535 (so I guess 2 bytes unsigned)... think it's worth adding to the page but would like a more solid reference (like an RFC document).

[edit] IN A versus IN CNAME

Hello, I'm wondering if there should be some explanation about the use of a hostname in the MX record that is defined as an IN A host or a IN CNAME host.

Picture the following scenario:

mx1 IN A 192.168.1.1
mail IN CNAME mx1
acme.com. IN MX 10 mail.acme.com.

the host mx1 would receive email for the acme.com domain, it would then look at the list of MX records to determine if it should forward it to another exchanger or try to deliver it locally. Since mx1.acme.com != mail.acme.com, it may try to contact mail.acme.com (itself) to forward the mail causing an SMTP 554 - local configuration error message.

Most new SMTP servers handle this situation gracefully, but I wonder if this information should be listed in the entry for MX record.

RFC 1912 strongly discourages an MX pointing to a CNAME by referencing RFC 1034 and RFC 974.
This is also staed in RFC 2181 Section 10.3
By corollary, NS and SOA records should not point to a CNAME (especially since as of version 9,
Bind will not query for the glue record from a root nameserver for the additional section by default).
-Cowbert 22:13, 8 September 2006 (UTC)

[edit] equal weight MX records

"If there is more than one entry with the same preference number, all of those must be tried before moving on to lower-priority entries."

Is there any references for this? A number of systems seem to try just one server at random of equal perference and then give up. The RFC 2821 is not explicit: If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.

On page 60 of RFC 2821 (my emphasis): the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order Erik Warmelink 20:49, 5 July 2007 (UTC)

[edit] spam?

Ehhh what's that 'noonward awsome' thing? Spam? (EDIT: OMG you people are FAST - kewlness)

[edit] DNS Query

The article says "the sending mail transfer agent makes a DNS query" - but to what does it make the query? --Mickraus 15:50, 31 January 2007 (UTC)

That would be a (far too) long story. Please see Domain name system. Erik Warmelink 20:49, 5 July 2007 (UTC)

[edit] weighting value

I do not agree with the second part of this statement:

The MX mechanism does not grant the ability to provide mail service on alternative ports, nor does it provide the ability to distribute mail delivery across a set of equal-priority mail servers by assigning a weighting value to each one.

Assigning equal weight values, would distribute mail delivery across a set of mail servers. Someone please edit or explain.

Weighting is not supported in MX records AFAIK, the only way weighting can be accomplished is through SRV records. :I think what you mean is assigning equal priorities to several MX records, which would allow for multiple servers to receive roughly the same amount of requests, albeit not very reliably, as queries will return a different server randomly.
At least this is my understanding, please correct if needed. :)
That is what I understand too. I removed the remark. Erik Warmelink 20:49, 5 July 2007 (UTC)

[edit] Why is the author assuming the reader already knows the subject???

Once again, a technical subject written by a technical person, strewn with the assumption that those of us who come to Wikipedia already know what we came here to learn about. How Aggravating!

Would technical people who contribute here please understand the audience they are writing for: We are the UNINFORMED. You are not in a water-cooler conversation with your cohorts. You are writing for those who seek to learn something. That is why we read these pages, TO BECOME INFORMED!

It does not help to begin reading, only to encounter undefined terms, as well as assumed schema and content that make the reader break-away to yet another topic to get a definition for a term used in the article about the subject they are trying to learn something about.

In this case, I want to learn about MX records. In the first sentence, I find the need to understand CNAME's. This goes on and on and on. Soon the reader is balancing a half dozen NEW concept in their mind, while trying to integrate it all down to the original topic queried. I have an IQ or well over 150; but this is just insanity to think that those wanting to learn something are going to learn anything from a string of verbiage that assumes prior knowledge in a subject. Are you mad?

I'm sure the author wants to be helpful; but writing for a Wikipedia entry is NOT the same as writing for a technical manual.

Please, consider your audience. Lay the premise and supporting information out early and STATE IT. Better yet, take a course in the language and grammatical composition. Grrrrrrrrrr!

Ricky_O July 8, 2007, 2:50pm GMT

Wikipedia is an encyclopaedia, not an instruction manual. Erik Warmelink 15:10, 13 July 2007 (UTC)
I feel your pain, Ricky_0. But you're dealing with complex technical topics. Fortunately, the terms you are not familiar with are linked to pages describing them. When you find yourself entering into a topic in the middle of the complexity, you might need to jump up a few levels until you're are the overview, then dig back down into it. Then the topic should make more sense inside a proper context. --Gmuir 14:33, 8 August 2007 (UTC)

This article is very short. where is information about how to recording MX ( I mean it should be a host name not IP or CName. ) where is diagram? I think it need alot of change. what do you think? are you agree whit me? —Preceding unsigned comment added by 80.242.12.166 (talk) 19:22, 19 November 2007 (UTC)

[edit] Reference to support a half-truth

"However, not all versions of all mail transfer agents pay attention to lower priority MX records — in other words, if the highest-priority MX server fails, the MTA doesn't address the backup server [2]."

This particular reference concerns older versions of PostFix which DO pay attention to lower priority MX records, but only do so if a higher priority server did not answer at all. I'm not sure how to phrase the text better without making it very complicated. 69.135.188.10 (talk) 16:08, 12 March 2008 (UTC)

[edit] Nolisting (proposed merge)

IMO creative games with MX priorities don't need a separate Nolisting article, the external link and a short section here would be good enough. At least it's educational wrt MX priorities. --217.184.142.38 (talk) 01:23, 29 May 2008 (UTC)

nolisting is a specialized technique for spam reduction. It is a stub, but it would make more sense to merge it with an article on anti-spam techniques. Smallpond (talk) 19:31, 4 June 2008 (UTC)

It's not really related to greylisting, and I'm not aware of any other anti-spam article in this direction. --217.184.142.51 (talk) 06:27, 5 June 2008 (UTC)

greylisting and nolisting are two of a number of techniques that test the e-mail sender to make sure they conform to RFCs. The assumption is that spamware is poorly written or that conforming to standards is not effective for them. (e.g. slowing down the sending of spam hurts more than people dropping the spam due to non-conformance.) There are a few other techniques that fall in this category as per Anti-spam techniques (e-mail)#Enforcing RFC standards. The "hello" checking there doesn't have an article, I guess a new, catch-all, article could be created that lists all the minor techniques in this class. Wrs1864 (talk) 10:32, 5 June 2008 (UTC)