spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Empty MX name

2005-12-29 09:27:19

On Thu, 29 Dec 2005, Dick St.Peters wrote:

Stuart D. Gathman writes:
mail.globalinkllc.com has no SPF record.  However, their weird MX could
happen to a domain that does.

$ host -t mx mail.globalinkllc.com
mail.globalinkllc.com is an alias for redirect.mail.premiumservices.yahoo.com.
redirect.mail.premiumservices.yahoo.com is an alias for 
ymb1.mail.vip.sc5.yahoo.com.
ymb1.mail.vip.sc5.yahoo.com mail is handled by 0 .

That wierd MX is broken anyway - MXs are not allowed to be aliases
(CNAMEs).  That goes all the way back to rfc974, which says on 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.

What RFC says is that you can not put a name that is a CNAME as target server in MX, i.e. if it is
  example.com. IN MX 10 mail.example.com.
  mail.example.com. IN CNAME myserv.example.com
that would be a violation of RFC and maybe considered invalid.

But what globalinkllc.com has is basically:
  server2.example.com. IN CNAME server1.example.com.
  server1.example.com. IN CNAME server0.example.com.
  server0.example.com. IN MX ...
In such a configuration server2.example.com would still be able to receive
email (if MX record is not "." obviously...) but it is all handled same
as if it were server0.example.com. However for purposes of email one
could in fact use different addresses "tim(_at_)server2(_dot_)example(_dot_)com" and "tim(_at_)server0(_dot_)example(_dot_)com" and they need not be forwarded to the same
person (sometimes people I consult expect for it to always be true just
because CNAME is setup...).

---

BTW - I see no clear answer in RFCs if "MX 0 ." is valid or not. Yahoo
obviously says it is but is is not at all clear to me that you can use
just "." as valid host name for target of MX.

  Implementors should understand that the query and interpretation of
  the query is only performed for REMOTE.  It is not repeated for the
  MX RRs listed for REMOTE.  You cannot try to support more extravagant
  mail routing by building a chain of MXs.  (E.g. UNIX.BBN.COM is an MX
  for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
  but this does not mean that UNIX.BBN.COM accepts any responsibility
  for mail for .IL).

The last sentence of the first paragraph is probably one of the most
contested sentences in any rfc.  This rfc dates to 1986, a time when
explaining to technically adept people the evil consequences of doing
something was sufficient "Don't do this".  The breakdown of that is
why today's rfcs are full of hollered uppercase MUSTs and SHOULDs.

There may be such a definitive statement in one of the many revisions
of rfc974, but I wanted to quote the above for the "chain of MXs"
part, which is what the mail.globalinkllc.com MX appears to be
attempting.

mail.globalincllc.com does not have an "MX" record of its own. What it
does have is a chain of "CNAME" ending up with "MX" and that is perfectly
valid and proper use when you do want to setup dns chain.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>