Avoiding the DNS Hunt

At 07:54 AM 5/20/2005 -0500, Daniel Taylor wrote:
> David MacQuigg wrote:
> > At 06:10 PM 5/19/2005 -0700, william(at)elan.net wrote:
> >> On Thu, 19 May 2005, David MacQuigg wrote:
> >>
> >>> Without the ID command, you will waste a bunch of DNS queries and
> >>> possibly conclude this sender offers no authentication.
> >>
> >> He doesn't!!!!!
> >> If sender wants to authenticate, he can just go ahead and use AUTH
> >> command, Authentication involves mutual pre-negotiated trust.
> >
> > We're talking about a syntax that might be useful for SPF, CSV,
> > DomainKeys, etc.  None of these require pre-negotiation.  I hope this
> > isn't the start of a debate on the meaning of "authentication".
> >
> > So, to get back on track, assume you are a well-equipped receiver, and
> > you have available any method that might be needed, including the three
> > I mentioned.  All you know about the incoming mail is it's IP address,
> > the following two commands:
> >
> >   EHLO  mailserver7.bigforwarder.com
> >   MAIL FROM:<bob-at-sales.some-company.com>
> >
> > What do you do to avoid a DNS hunt?
> >
> > <snip>
> >
> For SPF the answer is ridiculously simple.
We don't know yet if the sender uses SPF.

> You query TXT for sales.some-company.com against the source IP.
> If you want to check permission for HELO, you do the same for
> mailserver7.bigforwarder.com.
>
> Since bigforwarder.com is probably in trusted forwarders, you might
> ignore a FAIL on MAIL FROM:, but definitely would not ignore a FAIL
> on the EHLO.
Probably ... probably ... We need to remove this uncertainty about the 
sender's intent.
>  <snip>
OK, I think I see the problem.  I should not have used "ID", or anything 
suggesting "identity" as the keyword.  That will immediately block 
consideration by anyone who has strong beliefs about which identity a 
sender should be using.  I need a more neutral term.
Let's try this again.  We need some way to avoid the DNS hunt that Daniel 
just described.  Here is the incoming message:
   EHLO  mailserver7.bigforwarder.com
   CLUE bigforwarder.com
   MAIL FROM:<bob-at-sales.some-company.com>

At this point, we have no idea what method will be used.  Without a clue, 
we have no idea where to look for some possible authentication records.  We 
need to do a DNS query to every possible location for those records 
(mailserver7.bigforwarder.com,
bigforwarder.com, sales.some-company.com. some-company.com, 
_client._smtp.mailserver7.bigforwarder.com, etc.) and we need to look for 
records of type TXT, SRV, SPF, etc.)  This still doesn't cover the 
identities found in the mail headers.  Even after all these queries, we 
still can't conclude the search.  We need to transfer at least the headers, 
look for DomainKeys, and maybe a few others, and the result of all this 
effort may still be - no authentication found!  This entire hunt will be 
repeated at every forwarder along the way.
With a clue, all we need is one query to _AUTH.bigforwarder.com.mail.net 
(or some other neutral location).  The response to that one universal query 
should be packed with useful information - ratings from reputation 
services, list of authentication methods, even some parameters needed for 
the authentication.
--
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          *
************************************************************     *