Julian Mehnle wrote:
I only use MX->CNAME (or MX->CNAME->CNAME) because I believe
it is technically valid.
Somebody with the IP 198.104.146.18 disagreed with your belief.
While all other RFCI submissions are checked manually by the
admins, the "bogusmx" reports are verified automatically by a
script. The unlisting is also automatical when you fix the MX.
AFAIK the complete RFCI "bogusmx" zone is retested daily.
Perhaps RFCI should specify exactly what constitutes RFC
ignorance. Is it ignoring a "MUST"? Or just ignoring a
"SHOULD"? Or even just a "should"?
Essentially it's what the admins think - sometimes after heated
discussions on the "RFCI discuss" list - as documented in the
corresponding listing policies, e.g. for "bogusmx":
<http://rfc-ignorant.org/policy-bogusmx.php>
They also should refer to the exact RFC clauses in question.
| Section 10.3 of RFC 2181 points out that pointing an MX RR at
| a hostname which is actually a CNAME RR is invalid, and such
| hosts are also listed.
That would make their blacklists appear more serious.
Sometimes looking at the Web page helps. Not always, e.g. for
"SPF" this strategy didn't work too well for the last months,
(IIRC 11 months), but for RFCI it's an idea.
You could also ask the RFCI admins WTF is going on, they have a
trouble ticket system and answer queries within a day. I did
this quite often. In one case I was seriously unsatisfied and
started to whine on the public list about double-standards etc.
Some weeks later the last point of this issue (an HTML error on
the RFCI Web page) was fixed. It's in essence the same idea as
SURBL, SPF, SORBS, abuse.net, and similar projects.
The way it is now, I don't think they can be taken seriously,
at least not as far as the bogusmx list is concerned.
Apparently the Chair of the SPF Council disagrees with your
belief. Dito Wiliam, me, and many other supporters of RFCI.
OTOH I know that John Levine might generally agree with you,
he preferes a more subjective style of black listing. I can't
tell you what he thinks about "bogusmx" in particular, ask him.
Hell, I can't tell you what I think about this, if all MTAs in
the world have no problems with CNAME it could be another bug
in the proposed standard RfC 2821. I'm more interested in the
bogus "bounces-to" claims of RfC 2821, not in CNAME oddities.
Or in its "MUST accept but SHOULD ignore source routes" parts.
Or in its "at least one dot" syntax. Julian, get real, there
are often disputes about the fine points of RfCs.
It's normal. We'll have a lot of fun with "reordering header
fields" in the SPF "last call". If Bruce needs it he debugs
the _source code_ of "B news 2.11" (I've no idea what it is,
but it's related to RfC 1036 and at least 13 years old... ;-)
it is within their full right to publish bogus blacklists.
No. You confuse this with BLARS or SORBS 127.0.0.6. The RFCI
friends are adamant about "the same rules for everybody". But
that does not always answer "which rules".
BTW, RFCI itself was also once listed for a day, because it
didn't accept mail to <postmaster>.
At least they're being consequential.
Yes. That doesn't mean that I _always_ agree with their rules.
Some RFCI listings are now years old, I'd prefer an expiration
(no issue for the automatical "bogusmx" zone). And the rules
for listing complete TLDs or SLDs as "whois ignorants" are not
exactly obvious in a case like DENIC (= TITANIC in my parallel
universe). I could in theory justify the de.whois.RFCI entry.
I could also question it, and I've done so on the "RFCI list",
but it's a minor point, in practice I prefer that the TITANIC
fixes its whois server.
And I prefer that Wayne puts the PermError codes back in. Now
let's see what happens... ;-)
Bye, Frank