Re: Avoiding the DNS Hunt

David MacQuigg wrote:
> 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.
And with the ID you are placing trust in the sender.  And if we could 
trust the sender, we wouldn't need SPF/CSV/the other ones.
> > >>
> > >> 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.
Doesn't matter if the sender uses SPF.  It matters if the DOMAIN the 
email is claiming to come from uses SPF.  (Unless you are doing 
EHLO/HELO checking but that is an ADDITIONAL check the receiver opted to 
do anyway)
> > 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.
You remove it by white listing trusted forwarders as the appear.  Its 
not uncertainty.  Its certain they will not be whitelisted until they 
ARE white listed.
> >  <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.
Doesn't matter.  You still cannot trust the information from the sender, 
no matter what label you apply to it.
> 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.  
NOR SHOULD YOU:  You cannot trust *anything* the sender is saying (they 
could be filthy rotten lying spammer, remember?)
> 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.  
There is no DNS record type "SPF".  When there is one it will deprecate 
and then replace TXT use of SPF.  SRV is not used by SPF, it is used by CSV.

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.
And will be cached at after the first hit at every DNS along the way also.


> With a clue, all we need is one query to _AUTH.bigforwarder.com.mail.net 
Only if you are doing EHLO/HELO checking.

Otherwise you need to check the DNS records for some-company.com

> (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.
Your idea is a good idea: One place to look to see what 
authorization/authentication/"whatever you call it" methods to use.
But your implementation is wrong, it *cannot* be passed in with the 
email, because the email cannot be trusted.
If you want it to mean something, setup a new DNS record type 
"AUTHMETHODS", and each domain can publish the indicators of which 
methods they publish e.g. "SPF" or "SPF,CSV" or "SPF,CSV,SID".
Then 1 query determines which further queries should be pursued to 
gather info for the domain the email is coming from (or is being relayed 
from if you do HELO checking).
Terry

> --
> 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          *
> ************************************************************     *
>
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription, please go to 
> http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085