ietf-mxcomp
[Top] [All Lists]

Re: MTAmark (was: Reality check please)

2004-06-11 05:43:44


I'll refer you to my previous message sent to MARID which basicly 
describes exactly this (as far as checking not directly at INADDR
but the name specified in PTR): 
  http://www.imc.org/ietf-mxcomp/mail-archive/msg01503.html
Additionally also see the following as far as my comments on MTAMark and 
ability to adapt that a lot quicker then SPF (I've always been advocate 
of MTAMark although I though I was only one here supporting it...):
  http://www.imc.org/ietf-mxcomp/mail-archive/msg00983.html
  http://www1.ietf.org/mail-archive/web/asrg/current/msg10088.html

Now as far as wildcards, I originally thought it might be possible too
as far as doing lookup on ip first for PTR dns name and then in case
of larger povider, it could be something like pool-1-2-3-4.client.domain.com
and that record there could be entered into client.domain.com as wildcard
to apply to entire ip pool. Unfortunetly this would not work, because
if TXT or MARID or zone other record exists in client.domain.com it
would only show up for lookups on pool-1-2-3-4.client.domain.com if such
name did not exist at all in DNS. But pool-1-2-3-4.client.domain.com 
would normally have an I record pointing back to ip 1.2.3.4 and since
it does have this A record, lookup for TXT and MARID would fail unless
there exists specific TXT record for pool-1-2-3-4.client.domain.com.

But there was however workound that was discussed a while ago, it involves
that in case of failure to find MARID record to check server name listed 
in the SOA of dns as a kind of "default" wildcard. Such wildcard workaround
would work because in case of failure to find pool-1-2-3-4.client.domain.com
the SOA could contain just client.domain.com and the result is that thus 
one record could exist for entire ip pool.

On Fri, 11 Jun 2004, Hector Santos wrote:

Before releasing our product update with SPF/DMP/MCEP support,  for
documentation and support assistance, one of the things we looked for in our
customer based was how they were would implement the new special DNS
records.

Of course, those in control of their own DNS server had no real issue with
it.  Many of the hosted systems responded with having Web-based DNS
management capabilities.  However, some indicated lacking a TXT record entry
using these Web-based tools.  Some were using IP hosting systems, like Road
Runner,  DynaIP (??) and I got feedback from one of these that it would be a
technical challenge for to implement an SPF like setup for their customers.
But they were looking into how it can be done.

What came across my head was the wildcard or rather subdomain lookup
concept.   These systems have a common primary host domain:

        charlie.rr.com
        bill.rr.com
        tom.rr.com
        whatever.rr.com

So their IP allocation is pretty much fixed in some way.  However, I don't
claim to be an DNS expect or how their business works in this area, so I
can't say for sure if this is workable for them.  It would imply, I believe,
that rr.com is a reputable system, rather than the subdomain.   Note, that
these type of businesses have evolve to offering new services where a
customer have his/her own domain for the sub domain.

Nevertheless, one common thing I see around here is this "BIG" vs. "SMALL"
thing, and I guess, the small end of the spectrum doesn't count as much for
MARID.  I may be off based, but if this is true, this would be another
mistake in the making as the early wide spread adoption will come from the
larger pool of smaller systems.  I believe SPF has shown this very clearly.
However, I will note that we jumped on board only when we saw AOL.COM, a
major source of spam, began to support it.

Have a good weekend.