Re: Email ID Declaration - Summary of Objections

Mark,

Let's wrap this up.  We seem to have a fundamental disagreement on the 
purpose of authentication.  I need to summarize your objection in a short 
statement, and present both sides fairly.  My previous summary is 
apparently not adequate, since you did not respond.  I'll attempt one more.
Objection:  Why should I care what the ID owner (who is trying to claim 
responsibility of some sort) wants or expects with respect to 
authentication tests?
Response:  When an email arrives with an ID declaration, the sending MTA is 
making a claim.  It is saying - "Hello, this is <ID> sending to you from 
<IP>."  If you check the authentication records for <ID> you will find what 
methods <ID> offers to authenticate that claim.  No other identity in the 
mail transfer can be expected to authenticate the sending MTA's 
claim.  There are legitimate reasons, or at least plausible excuses, for 
the other identities being unverifiable.
I will list both objections, since they seem to be distinct.

<end of discussion for those who think this thread is going off topic>
<continuation just to reply to Mark's latest questions and statements>

At 12:21 AM 5/24/2005 -0400, Mark Shewmaker wrote:
> Mon, 2005-05-23 at 16:42 -0700, David MacQuigg wrote:
> > At 05:30 PM 5/23/2005 -0400, Mark Shewmaker wrote:
> > >
> > >How does your ID proposal get me reliable knowledge of the exact
> > >definitions of forgery from these three separate parties for these three
> > >separate arguments without use of an additional reputation server that
> > >says I can trust the ID domain's hearsay claim about these other domains?
> >
> > If the declared ID authenticates, then we have our responsible party.
>
> Why should I care in the slightest that an identified but untrusted
> third party is claiming responsibility that the mailfrom is nonforged,
> that the helo is unforged, and that the pra is unforged?  (Or that it's
> telling me something about these domain owners' rules about how to
> determine forgeries.)
>
> My primary goals are to detect and reject forgeries.
>
> My secondary goals are to look at the reputation of these three
> entities.
Reputation and authentication are *both* necessary.  We will always have 
forgeries like smith-barney.com that authenticate perfectly, because there 
are many slight variations in spelling, and we have to assume that spammers 
of the future will have perfect SMTP commands, flawless headers, complete 
DNS records, etc., everything but a good reputation.
> ID-type proposals can be useful for helping out reputation computations,
> (and I've proposed that sort of thing in various forums), but that's not
> the same as figuring out if these things are forged in the first place.
>
> > We
> > don't need the other identities, unless the ID owner expects them to be
> > checked.
>
> Why should I care what the ID owner (who is trying to claim
> responsibility of some sort) wants or expects with respect to forgery
> tests?
>
> > You keep saying that the ID declaration is hearsay.  I don't understand
> > what you mean by that word.
>
> I referred to "the ID domain's hearsay claim about these other domains".
There is no such claim.  The only claim is that of the sending MTA - I am 
authorized to use this ID.
> If the ID is claiming that these other domains are claiming that these
> specific things are not forged, then that's hearsay by definition.
The Return Path is hearsay (information passed on), regardless of what 
authentication method you (the final receiver) use.  All the headers are 
hearsay, except those added at the top by the sending MTA.  Exception:  If 
you receive the email directly from the original sender, then all 
information is first-hand.
> If the ID is not claiming that these other domains are claiming that
> these specific things are not forged, then it's not helping me in my
> goals of determining if the message is forged in those ways.
>
> > The record for a declared ID may specify, by the list of methods, what
> > identities are to be checked.
>
> Why should I care what identities this declared ID wants checked?
Because that is the only way to authenticate the sending MTA's claim that 
it is authorized.  If the ID says do a CSV check on the EHLO name, and that 
check fails, they you can't hold the ID responsible for the transfer.
> As a side note:
>
>   It occurs to me that it would be useful if there were
>   a place where these discussions would be on-topic.
>
>   I would ask if you would please set up a mailing list
>   for discussion of these topics, and then make an
>   announcement here as to its location.
I'm not going to set up a mailing list with such a narrow scope.  It would 
be helpful if there were a mailing list for email authentication in 
general, but it seems the community as a whole is not as well organized as 
the groups promoting specific authentication methods.  Mipassoc looked like 
a good start.  Their charter includes all, but it seems they are now CSV 
only, and their discussions are much more tightly 
controlled.  [spf-discuss] seems to be the only open forum relating to 
email authentication.   I think this is a good thing for the community, and 
for SPF.  If the SPF council feels otherwise, they can certainly do like 
mipassoc.  When a discussion goes in a direction they don't like, a 
respected leader cuts it off.
So if you want me off this list, ask one of the council members to step 
in.  Otherwise, I will continue to post, doing my best to keep the thread 
on track, not hijacking other threads, not responding to personal attacks, 
not insulting other list members, doing my best to understand the other 
point of view before responding, not clipping relevant context, trying 
always to understand the truth rather than win a debate, and understanding 
that behind most differences of opinion are hidden, but legitimate assumptions.
--
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          *
************************************************************     *