Re: Avoiding the DNS Hunt

At 04:42 PM 5/22/2005 +0200, Julian Mehnle wrote:
> David MacQuigg wrote:
> > At 12:19 PM 5/22/2005 +0200, Julian Mehnle wrote:
> > > > My point is that even if a receiver always checks SPF first, it
> > > > won't avoid a DNS hunt.  We can't assume that the owner/admin of a
> > > > domain/subdomain in the MAIL FROM identity has published an SPF
> > > > record just to tell us which other method he/she uses.
> > >
> > > You are valuing not having to do a single DNS lookup (in order to find
> > > out _if_ SPF can/should be used at all) over the receiver's freedom to
> > > choose what authentication mechanism he finds useful.  This evaluation
> > > of yours is absolutely unpractical.
> >
> > I think you may still have an "SPF only" perspective on this.  If the
> > receiver does SPF only, then your are right.  The question is simply -
> > Does this ID have an SPF record?  In general, most receivers will have
> > available whatever methods are popular.
>
> I think this is a misconception of yours.  Receivers will only try those
> authentication methods that they think are useful, for whatever definition
> of "useful".  Just look at how receivers are filtering spam: one receiver
> uses SpamAssassin to filter all spam client-side and curses IP-address-
> based blacklists, another does the reverse, rejecting mail server-side.
> It will work the same way when it comes to sender authentication systems
> such as SPF, DomainKeys, and CSV.  The market is the receivers, not the
> senders or the identity owners.  And although it may theoretically be
> possible to make the identity owners the market, it is definitely
> unpractical to ask the senders for what they want, because the senders are
> those who are generally untrustworthy and who we want to authenticate.
I have a different view, not a "misconception" of what the future will 
hold.  I don't think either of us can predict the future.  In my view it 
will be an extension of the current situation with receivers wanting to use 
anything that will work, and senders wanting to do the minimum necessary to 
avoid losing reputation.  I don't know what you mean by "the market is the 
receivers" or how the fact that senders are "generally untrustworthy" 
relates to our discussion.
I think in terms of barriers and motivators for different groups - senders, 
spammers, reputable identity owners, and receivers.  Right now the lack of 
a good authentication standard is a barrier for receivers.  When that 
barrier is down, widespread use of authentication by receivers will provide 
the motivator for senders to do just a little more.  I'll be happy if all 
they do is provide an ID.  Then we can check their record, and filter 
accordingly.  I can imagine many senders doing nothing more, but never 
losing reputation, because they never send spam.  Those senders will have a 
default record making them responsible for whatever comes out of their IP 
block.

> > So without an explicit ID declaration, it will have to hunt for
> > authentication records in many places, like _client._smtp.<ID>.
>
> We all understand this, and it really isn't as elegant as one might wish.
> But I don't see how we could allow the _senders_ to determine what
> authentication methods receivers should use.  What if the identity owner
> offers all of SPF, DK, and CSV, but the sender (let's assume a spammer)
> chooses to only say "ID: CSV" because CSV is the least expressive or the
> least strict of all?  What if the receiver doesn't support CSV?  Should he
> then treat it like "ID: none" (or no "ID" statement, for that matter)?
The spammer will not be able to use a reputable ID.  It will fail an 
authentication check provided by the ID owner.  The ID owner controls the 
records under his ID.  There will be a transition period where some 
careless ID owners get smeared, but soon those ID owners will limit their 
authorizations to just those IPs that don't get them in trouble.
> > The receiver never has complete freedom to choose the authentication
> > method.
>
> Of course not, but at the end of the day, _receivers_ will decide in which
> authentication methods they trust and which methods are too weak.  Then
> identity owners will have to follow.  Hopefully, senders will have nothing
> to say in it.
"senders" is undefined.  In this discussion I'm using it to mean legitimate 
senders, as opposed to spammers.  I include both originators and forwarders 
as senders.  Originators are responsible for content.  Forwarders are 
responsible only for authentication.  Both lose reputation by failing to 
meet their responsibilities.

> > The ID owner specifies the methods, and the receiver gets to chose from
> > what is offered.  My guess is that most receivers will have available any
> > authentication method that is being actively promoted and supported.
>
> That would only be true if all authentication methods were equivalent.  But
> they aren't, and there are huge disputes over which methods are best.
Correct.  I should modify that last statement to say - most receivers will 
have available any authentication method that they believe will be 
effective and is not too costly for them to install and operate.
> > > > "ID none" should be an immediate reject.  I wouldn't accept mail from
> > > > any sender that says - "I know you want my ID, but I'm not going to
> > > > give it to you."
> > >
> > > This makes your proposal 100% backwards incompatible to the current
> > > system.
> >
> > I don't understand what you mean by "backwards incompatible".  Older
> > systems will not use the ID command at all.  The SMTP client will not
> > send this command unless the SMTP server says in it's EHLO response that
> > it will be accepted.
>
> So what about legacy clients that don't support it?  Will those be
> rejected, too?  If no, what about clients (senders) that deliberately
> choose not to support it to avoid having to offer some authentication
> method they know they can't pass?
Receivers will decide what to do with senders that don't offer an ID.  At 
first, this will be the normal processing - starting with a DNS 
hunt.  Pressure will build on senders, however, as more receivers decide to 
skip the hunt, and put unidentified mail through their spam filter 
instead.  That will generate some bounces of legitimate mail, and that will 
motivate legitimate senders to offer an ID.
Again, I'm not saying my view of the future is the only one possible.  If 
I'm wrong, and we get to a world in which receivers call the shots and 
senders have to offer every method receivers may want, then the ID will 
still be helpful.  It provides a single location where all information, 
including reputations can be found.  No DNS hunt (searching for 
non-existent records), but still fewer DNS queries.
Email IDs can also be a powerful motivator in changing our email 
culture.  A reputable ID will become a "broadcast license" to be treated 
with respect.  Anyone wanting to operate a Public Mail Server should have 
no objection to offering an ID.  Owners of reputable IDs will not tolerate 
abuse of those IDs.  Receivers will quickly learn which IDs they can 
trust.  The rest will be easily ignored, even if spammers own 99% of the 
Internet.
Having a neutral syntax for an ID declaration is one of the few things that 
all methods could agree on.  This is a small step away from a de-facto 
standard with a "lock in" for whatever method wins the marketing and PR 
battles ahead.
In summary, even with the future you are expecting, I see substantial 
advantages to having senders declare their ID, and no possible harm.
I think I have a good understanding now of the objections to a universal ID 
declaration.  I will post a summary shortly, and ask for 
clarifications.  When we have "consensus" at least that the statements are 
complete and represent the different points of view fairly, then I will 
submit the draft to the IETF.
--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg 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          *
************************************************************     *