-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Jan 2009 22:33:24 -0800, Al Stu wrote:
Analyze this.
Query MX dns.com
Response MX nullmx.domainmanager.com
Query A nullmx.domainmanager.com
Response CNAME mta.dewile.net, A 64.40.103.249
So the fact that other random folks
David Sparks wrote:
There are plenty of ways to get a mail loop that don't involve DNS
mis-configuration. As such pretty much every major MTA detects and stops mail
loops.
Not if you (accidentally) fat-finger the MTA configuration. It is
completely possible to still mis-configure a MTA to
On 30.01.09 22:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
called experts, only to be vindicated once the masses and so called experts
get their head out where the sun
What?!
And all this time I just assumed it was the Martian Sand variety that
was being spoken of on all the save the whales bumper stickers.
Maybe Al will end up winning the Darwin Award for another one of his
avante garde ideas. He'll decide that the conventional wisdom that
exhausting his
The authoritative name servers for nullmx.domainmanager.com are
ns1.domainmanager.com and ns2.domainmanager.com. They are domain
parking name servers. They return 64.40.103.249 (or at least something
close to that) to the query for any A record. The real address of
mta.dewile.net is
You just don't get it. You are off wandering around in the weeds.
Read the tail end of Chapter 5 in the book DNS and BIND describing the
MX selection algorithm in layman's terms to (perhaps) understand why
having MX records referencing CNAMEs is bad.
It may work right now for you, but
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
called experts, only to be vindicated once the masses and so called experts
get their head out where the sun is shining and exposed to the light
On Sat, 2009-01-31 at 16:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
You don't get to speak for anyone else but yourself, just because you
believe in your own trolling,
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for
putting forth that which goes against the conventional wisdom of the
masses and so called experts, only to be vindicated once the masses
and so called experts get their head out where the sun is shining and
exposed
On 27.01.09 10:18, Al Stu wrote:
I not only say it, I have demonstrated it.
But you have demonstrated something different than we're discussing all the
time.
BIND is the DNS system we are discussing.
Have not looked to see if that specifically is spec'ed in an RFC.
Yes other DNS
On Jan 26, 2009, at 11:27 PM, David Ford wrote:
hand because each line isn't strictly well-formed per RFC. If every
vendor was as utterly asinine about absolutist conformance, sure, we'd
have a lot less mess out there, but we'd have a lot less forward
movement as well as a lot more fractioning
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1 mx1.xyz.com.
1) Select Target Host:
The MX query for xyz.com delivers mx1.xyz.com which is a CNAME.
2) Get Target Host Address:
The
On 27.01.09 08:46, Al Stu wrote:
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1 mx1.xyz.com.
1) Select Target Host:
The MX query for xyz.com delivers mx1.xyz.com which is a
When Section 5.1 of RFC 5321 says If a CNAME record is found, the
resulting name is processed as if it were the initial name, it is
referring to the situation where a query is sent for the MX record for
xyz.com, and instead of an MX record being returned for xyz.com, a CNAME
record is returned for
In message d53c69e1f478453a8371b49b4f04c...@ahsnbw1, Al Stu writes:
So then you disagree that the following example returns a valid address
record for srv1?
The MX query won't return the A record for srv1. The
additional section processing rules say to add A /
In article glma06$8d...@sf1.isc.org,
Mark Andrews mark_andr...@isc.org wrote:
Liberal in what you accepts means don't die on arbitary
input. You should still reject rubbish.
But MX pointing to CNAME is not rubbish. It's a violation of the
letter of the spec, but it's very clear
In article glmqqb$jv...@sf1.isc.org,
mlel...@serpens.de (Michael van Elst) wrote:
Barry Margolin bar...@alum.mit.edu writes:
customer.com. IN MX 10 mx.yourdomain.com.
mx.yourdomain.com. IN CNAME mx.outsourcer.com.
mx.outsourcer.com. IN A ...
That's just the same as
| customer.com. IN
In article glnemv$10n...@sf1.isc.org,
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
On 27.01.09 08:46, Al Stu wrote:
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1
On 27.01.09 08:46, Al Stu wrote:
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1 mx1.xyz.com.
1) Select Target Host:
The MX query for xyz.com delivers
I have not copied the entire thread.
You've added an additional step in your second paragraph that is
prohibited by the section you quoted in the first. The section from
the RFC describes a situation where A is queried for and an MX record
pointing to B is returned. When B is queried for,
On 26.01.09 09:19, bsfin...@anl.gov wrote:
If I have in DNS
cn IN CNAME realname
and I query for cn, the DNS resolver will return realname.
BIND also returns the A record for realname. Is this a requirement?
If not, then
mx IN 10 MX cn
will result in:
1) the MX
Thus, if an alias is used as the value of an NS or MX record, no address
will be returned with the NS or MX value.
Above statement, belief, perception etc. has already been proven to be a
fallacy (see the network trace attached to one of the previous messages).
Both the CNAME and A record is
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:
Al Stu wrote:
So within the zone SMTP requirements are in fact met when the
MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
In all the time its taken him to type his rants and
In all the time its taken him to type his rants and raves and have his little
dummy spit, he could have gone and changed the MX to be a real name, ... -
Noel Butler
Wow, such narrow mindedness.
I like most I suspect stopped reading his rants days ago. - Noel Butler
And yet here you are
In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes:
Thus, if an alias is used as the value of an NS or MX record, no address
will be returned with the NS or MX value.
Above statement, belief, perception etc. has already been proven to be a
fallacy (see the network trace
How about these two?
nullmx.domainmanager.com
Non-authoritative answer:
Name:mta.dewile.net
Address: 69.59.189.80
Aliases: nullmx.domainmanager.com
smtp.secureserver.net
Non-authoritative answer:
Name:smtp.where.secureserver.net
Address: 208.109.80.149
Aliases:
In message 0aa37ce829ba458b9ba2d199a6d96...@ahsnbw1, Al Stu writes:
How about these two?
nullmx.domainmanager.com
Non-authoritative answer:
Name:mta.dewile.net
Address: 69.59.189.80
Aliases: nullmx.domainmanager.com
smtp.secureserver.net
Non-authoritative answer:
Name:
On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote:
Which just means you have not ever experienced the problems
causes. MTA are not required to look up the addresses of
all the mail exchangers in the MX RRset to process the MX
RRset. MTA usually learn their name
If you refuse a CNAME then it is your SMTP server that is broken. The SMTP
RFC's clearly state that SMTP servers are to accept and lookup a CNAME.
- Original Message -
From: Scott Haneda talkli...@newgeo.com
To: Mark Andrews mark_andr...@isc.org
Cc: Al Stu al_...@verizon.net;
On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
If you refuse a CNAME then it is your SMTP server that is broken.
The SMTP RFC's clearly state that SMTP servers are to accept and
lookup a CNAME.
[RFC974] explicitly states that MX records shall not point to an alias
defined by a CNAME. That
RFC 974:
There is one other special case. If the response contains an answer which
is a CNAME RR, it indicates that REMOTE is actually an alias for some other
domain name. The query should be repeated with the canonical domain name.
- Original Message -
From: Scott Haneda
In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes:
RFC 974:
There is one other special case. If the response contains an answer which
is a CNAME RR, it indicates that REMOTE is actually an alias for some other
domain name. The query should be repeated with the canonical
Yes, the response to an MX query, that is the subject here. And a CNAME is
in fact permitted and specified by the RFC's to be accepted as the response
to an MX lookup.
If the response does not contain an error response, and does not contain
aliases
See there, alias is permitted. You
In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes:
Yes, the response to an MX query, that is the subject here. And a CNAME is
in fact permitted and specified by the RFC's to be accepted as the response
to an MX lookup.
No one is saying a CNAME is not permitted
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
I have never got why this is such a hard thing for email admins to get
right, but it certainly causes me headaches. I personally wish
CNAME's would just go away, keep them around, but just stop talking
In article glm61r$5l...@sf1.isc.org, Al Stu al_...@verizon.net
wrote:
Yes, the response to an MX query, that is the subject here. And a CNAME is
in fact permitted and specified by the RFC's to be accepted as the response
to an MX lookup.
No, we're talking about the response to the A
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
100% right. I refuse MX's that are cnamed, and I get emails from
customers asking what is up. What is strange, and I can not figure
it
out, is that the admins
On Jan 26, 2009, at 10:11 PM, Barry Margolin wrote:
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
I have never got why this is such a hard thing for email admins to
get
right, but it certainly causes me headaches. I personally wish
CNAME's would just go
The paragraph you cite regarding LOCAL has a alias and the alias is listed
in the MX records for REMOTE... is a peripery issue which is handled by not
doing that.
No one is saying a CNAME is not permitted in response to a MX query.
Well good then, we agree. The MX record data value can be a
In message bc7c01a4-1803-4906-bd90-93037b4ae...@newgeo.com, Scott Haneda writ
es:
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
100% right. I refuse MX's that are cnamed, and I get emails from
At 22:11 24-01-2009, Al Stu wrote:
Some people seem to think RFC 974 creates a standard which prohibits
the use of CNAME/alias in MX records. But very much to the contrary
RFC 974 demonstrates that CNAME/alias is permitted in MX records.
RFC 974 is obsoleted by RFC 2821; the latter is
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5
that CNAME MX RR are permitted and are to be handled by SMTP MTA's.
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
domain names are used in SMTP. In other words, names that can be
At 00:44 25-01-2009, Al Stu wrote:
When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name.That domain name, when queried, MUST
return at least one address record (e.g., A or RR) that
On 25-Jan-2009, at 03:44 , Al Stu wrote:
When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name.That domain name, when queried, MUST
return at least one address record (e.g., A or
On Jan 25 2009, Al Stu wrote:
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5
that CNAME MX RR are permitted and are to be handled by SMTP MTA's.
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
domain names are used in SMTP. In
No I do not believe an extra step was added. Take the following example for
instance.
STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX
lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is
returned. This is the first sentence:
When a
Yes, blah was supposed to be srv1.
I do receive both the CNAME and A records for the A mx.xyz.com query. See
attached capture file.
In the capture file three global search and replacements were performed to
match the previous example.
1) domain name was replaced with xyz
2) server name
On 25-Jan-2009, at 13:15 , Al Stu wrote:
Yes, blah was supposed to be srv1.
I do receive both the CNAME and A records for the A mx.xyz.com
query. See attached capture file.
In the capture file three global search and replacements were
performed to match the previous example.
1)
No it is only two steps, see the attachment (sent in previous message).
Both the CNAME and A record are returned for the mx.xyz.com DNS A request.
And this does met the RFC requirements.
- Original Message -
From: Matthew Pounsett m...@conundrum.com
To: Al Stu al_...@verizon.net
Cc:
Al Stu wrote:
ISC’s message that a CNAME/alias in an MX record is illegal is incorrect
and just an attempt by ISC to get people to go along with what is only a
perceived rather than actual standard/requirement, and should be removed
so as not to further the fallacy of this perceived
Perhaps one day MX records can be deprecated entirely in favor of SRV.
Jabber got it right, and it would solve the e-mail server autodiscovery
problem for clients in a generic non-proprietary manner.
For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients.
On Jan 25 2009, Chris Hills wrote:
Perhaps one day MX records can be deprecated entirely in favor of SRV.
Jabber got it right, and it would solve the e-mail server autodiscovery
problem for clients in a generic non-proprietary manner.
For example:- _smtp-server._tcp for servers,
MX records are supposed to be pointed to the name the mail
exhanger knows itself as. This will correspond to a A
record. If I could work out a way to determine which A
records don't correspond to the name by which the mail
exchanger knows itself as I'd
In article gli8nu$ja...@sf1.isc.org,
Matthew Pounsett m...@conundrum.com wrote:
In the example above, when I query for IN A mx.xyz.com? I do not get
an address record back (A, )..instead I get a CNAME record.
Requirements NOT met.
Then there's something wrong with your resolver,
Al:
If you read RFC 2181 section 10.3, RFC 1034 section 3.6, RFC 1912 (page 6),
the average person would understand that it's strongly discouraged. Perhaps
illegal is too strong a word, but the weight of the RFCs and best
practices appears to disagree with your assessment that there is no
Al Stu wrote:
BIND 9.6 ‘named’ throws the following message during startup claiming
that it is illegal to use a CNAME/alias in the MX record.
I beg to differ. There is no such standard nor requirement prohibiting
the use of CNAME/alias in an MX record.
Some people seem to think RFC 974 creates a
56 matches
Mail list logo
