Re: DNS matters & Wildcards

At 07:56 AM 5/8/2005 -0700, william(at)elan.net wrote:
> On Sat, 7 May 2005, David MacQuigg wrote:
> > You mentioned the problem of overloading DNS.  Is there a way we can 
> > remove that load entirely, with less cost than developing a whole new 
> > system?  Such a solution could put a nice upper limit on cost if our 
> > worst nightmare scenario actually happens.
> It would be nice to ask dns protocol designers to think of this question 
> and see if they can come up with an answer. But unfortunately as you said, 
> they are not being very active in wanting to work with us.
How about having a separate set of DNS servers, dedicated to email 
authentication, accessible via a query to _AUTH.<domain>.mail?  These 
servers would be widely distributed, resistant to denial-of-service 
attacks, and not loading any DNS servers performing other vital functions 
on the Internet.  How many servers would be needed?
I'm trying to ask questions, as you suggest, and not just forge ahead with 
my opinions.

> Latest statistics & polls show that SPAM problem has been contained and
> amounts seen by users this year are smaller then previous one. It may not
> stay this way, but it does seem that filtering methods may have bought us 
> another year or two.
Is this because of better filtering?  Seems like that would not reduce the 
amount being sent.  My theory is that the zombies are finally being shut 
down.  In fact, if M$ were to release a free patch, I'll bet they would go 
away!  ( They will probably time that move so it looks like the credit for 
ending spam goes to SenderID :>)
Does anyone know where I can find figures on the zombie population?


> > I believe the best solution to this problem (rapid deployment vs 
> > technical perfection) is a simple neutral standard that does not favor 
> > one or another authentication method but will allow the whole email 
> > industry to move forward.
> Its possibly that you misunderstand the meaning of standard and how 
> standardization on internet works. Plus what we are often talking are 
> different authentication methods that involve different identities and 
> mix-ups are dangerous (although they can also be beneficial if one is 
> careful, I'm writing paper on this topic, you'll hear more on it later).
Is there some way to remove the mix-ups over which identity to use on an 
incoming email?

> > Reputation services, spam-filter companies, forwarding services, ISPs, 
> > all should be working now on their part of the problem.
> > We just need  to let them know what an authentication header will look 
> > like.  No, it won't be Received-SPF:  Think of another, more neutral word.
> See 
> http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-02.txt
> Its one of the least controversial aspects of email authentication and
> one we're most likely to agree one on as you can see from that even now
> of email authentication proposals - SID, DK, META all use this header (and 
> possibly one or two other proposals) and SPF is only one that does not!
> Previous attempts by me and Julian to advance this in SPF Community have 
> failed. And I did ask already that it be mentioned in SPF draft (or at the 
> very least change current "SHOULD" for SPF-Received header into more general
> "SHOULD" for recording results in email header but "MAY" use SPF-Received 
> for that).
I think Kucherawy has made it much more complex than it has to be, but if 
it becomes an accepted standard, I can live with the complexity.  I also 
don't like the confusion with the order of headers.  It seems to me that 
headers should be prepended in exactly the order that the events 
occur.  Authentication first, then Received header.  Draw a line through 
each authentication header, and you have everything neatly separated into 
different administrative domains.

> > > I also have some hope that you might see spf forwarding and couple other
> > > major problems resolved by with new proposals by end of the year for 
> > > sure, in fact it might even happen a lot sooner.
> > The problem with forwarders goes away when forwarders do their own 
> > authentication.  That will be a requirement for compliance with the 
> > standard. Think big.  Think outside the box.
> That is how Meng views it, but it is wrong and actually not how standards
> work. You can't impose a standard on existing protocol that breaks existing
> infrastructure and expect everyone to follow, you can only do it as update
> of existing standard given everyone proper time to transition (which would
> take years).
I don't think we need to break anything.  I also think the transition will 
occur quickly once forwarders know what to do, can do it at no cost, and it 
will cost them money if they don't.  Compliance with the standard is 
voluntary, but if you don't, the reputation services won't rate your 
domain, and "unknown" will be as good as "dead".
--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *