Re: Beating the spam filter ...
- From: "Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx>
- Date: Thu, 03 Aug 2006 00:36:20 -0500
On 08/02/06 23:17, Bill Cole wrote:
Not rare perhaps, but accepted only by people on the heavy side of Sturgeon's Law.
Perhaps.
RFC's are not lawa, but they do define ways to be interoperable. I invite you to read:
http://www.rfc-editor.org/rfc/rfc974.txt Page 6
"... Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. ..."
IMHO, this indicates that you should not use CNAMEs in MX records for efficiency reasons.
http://www.rfc-editor.org/rfc/rfc1034.txt section 3.6.2
What specifically are you referencing? Are you referencing the fact that CNAMEs that point to a name in another domain should point to a canonical name? Or are you referencing the fact that a CNAME should be the only RR for the given name of the CNAME RR?
http://www.ietf.org/rfc/rfc1912.txt section 2.4
"... [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files. ..."
This section seems to reference RFC 974 for the reason given above.
http://www.rfc-editor.org/rfc/rfc2181.txt section 10.3
"... The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR. ..."
This is the only case that I see in your referenced RFCs that use the phrase "MUST NOT", which is a commonly accepted phrase to emphatically say no, "Thou Shall Not!". Any argument that I might pose will diminish against the "MUST NOT" phrase.
However, the very next paragraph states:
"... Searching for either NS or MX records causes "additional section processing" in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made. ..."
Which leads me back to my belief that this "MUST NOT" statement is motivated by the perceived need for efficiency. A need that I still hold in question.
All very good points.
Now I pose my scenario and question for equally as thought provoking input:
Consider a small company that hosts email and the likes for many clients. Presume if you will that the zone file for each of the company's clients uses the name of the hosting company's SMTP server as it's own SMTP server. I.e. client-domain-1.tld IN MX mx.hosting-company.tld.
Now consider if you will the desire of the hosting company to have a level of abstraction for the host name of mx.hosting-company.tld such that they can freely move the SMTP service from host to host, or add additional hosts to a pool with out the need to update all the client DNS zones. Thus the hosting-company uses a CNAME for mx.hosting-company.tld to reference the back end SMTP servers that they want their clients to use at the time.
CNAMEs, which "SHALL NOT" be used are an obvious solution for any thing other than mail, and will work quite well for mail save for the "SHALL NOT" (for the questionable reason).
To accomplish such with out using CNAMEs, mx.hosting-company.tld would have to use A record(s) that resolve to the IP address(es) of the current mail server. Thus it would be extremely easy to end up with a situation where you have an A record that resolves to an IP that does not reverse resolve to the original name. Sure, you could set up all the DNS zones to point to the canonical name of the mail server from the outset, but what do you do when you change the mail server? Update all the DNS zones? This is practical if you only have a few (read < 50) zones to update. Where does this become not practical?
Now you may say, what is wrong with having multiple A records resolve to one (or more) IPs that do not reverse resolve back to the original name? IMHO this is MORE WRONG than using a CNAME in an MX record. It is my firm opinion that a (normal) host has EXACTLY 1 (ONE) FQDN. Said host's name SHOULD be the only thing that resolves to the IP(s), which reverse resolve to the original name.
So, I leave you with my response to your points, which were good. However, I remind you of your own words, "... RFCs are not law, but they do define ways to be inter operable. ...", while adding one word, "more". Thus, your statement becomes "... RFC's are not lawa, but they do define ways to be _more_ inter operable. ...". I have always viewed RFCs as being VERY good guidelines suggestions that are usually very accurate for most. However, seeing as how they are guidelines / suggestions, they leave things open to interpretation and adaptation for each situation.
Comments? Suggestions? Complaints? Flaws in my (ill)logic? All the above, please.
Grant. . . .
.
- Follow-Ups:
- Re: Beating the spam filter ...
- From: Bill Cole
- Re: Beating the spam filter ...
- References:
- Re: Beating the spam filter ...
- From: Taylor, Grant
- Re: Beating the spam filter ...
- From: Bill Cole
- Re: Beating the spam filter ...
- Prev by Date: Re: access.db question
- Next by Date: Re: Upgrading Sendmail
- Previous by thread: Re: Beating the spam filter ...
- Next by thread: Re: Beating the spam filter ...
- Index(es):
Relevant Pages
|
