Re: Declaring an Identity

At 06:10 PM 5/19/2005 -0700, william(at)elan.net wrote:
> On Thu, 19 May 2005, David MacQuigg wrote:
>
> > OK, let's nail this down.  Here is the example incoming email, with the 
> > proposed ID command.  Assume you have no prior relationship with the 
> > sender, so you don't know what authentication method he uses.
> >   EHLO  mailserver7.bigforwarder.com
> >   ID  bigforwarder.com
> >   MAIL 
> > FROM:<<mailto:bob(_at_)sales(_dot_)some-company(_dot_)com>bob(_at_)sales(_dot_)some-company(_dot_)com>
> How did you ever manage to invent that mailfrom syntax :)
I think Eudora invented it. :>)  I'm sending plain text.  Maybe it was 
Hypermail at listbox.com.  Here it is without the angle 
brackets:       MAIL FROM: bob(_at_)sales(_dot_)some-company(_dot_)com
and without @:  MAIL FROM:<bob at sales.some-company.com>

> > 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?

I disagree with your statements below, but lets focus for now on this first 
barrier.  If we can't get past this, the rest of the discussion may be a waste.
--
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          *
************************************************************     *


> On the other hand its the recipient that decides which identity (not 
> address, but identity type) it needs for whatever mechanism it wants to 
> use to find if client can be trusted (i.e. accreditation/reputation call).
> Note that its important to understand that if there was no pre-negotiated
> trust then all decisions should be left to recipient and nothing that
> sender gives about its identity can be believed.
>
> > For each possible Identity (mailserver7.bigforwarder.com, 
> > bigforwarder.com, sales.some-company.com, some-company.com) you need to 
> > search every possible location for DNS records (<Identity>, 
> > _client._smtp.<Identity>, ...), and we still haven't searched all the 
> > header identities.  This is what I mean by DNS "hunting" - searching for 
> > records that may not be there.
> The thing is if those identities involve different domains/addresses, you 
> still end up searching from all those locations. If they involve same 
> domain, there is some value in having lookup at one dns record instead of 
> several and be able to see policies for multiple identities and verification
> records for different authorization methods (i.e. I agree with you that 
> there is value in putting cryptographic verification into SPF record as 
> modifier, but as I'm worried about size of such records, my preference has 
> always been on fingerprint data in dns, rather then public key; 
> additionally with crypto auth info, its easy to specify exact location, so 
> all that is needed is really to confirm that specified location is 
> associated with correct identity, which means something like SRV).
> > With the ID command, the receiving MTA does a DNS query for a TXT record 
> > at a standard location, like _AUTH.bigforwarder.com.mail.net  The query 
> > returns a record that specifies exactly what methods are supported by the 
> > owner of the Identity.
> Which identity?!!!! You do not know if it is "Sender" or "From" or "MAILFROM"
> and without that the info you have means nothing (also note that all the 
> above I listed are identities associated with message sender but you're 
> taking it to mean that each identity would be one associated with last 
> hop, which is only true for EHLO). You also can not actually verify the 
> majority of identities until you see message header and for most
> cryptographic proposals (domainkeys BUT NOT metasignatures) you need 
> entire messge data before you can verify.