Re: Sender-ID != SPF

On Sun, 2004-10-31 at 04:29, James Couzens wrote:
> On Fri, 2004-10-29 at 15:46 -0700, Douglas Otis wrote:
> > On Fri, 2004-10-29 at 09:44, James Couzens wrote:
> > 
> > > SenderID != SPF.  Please don't associate the two.
> > 
> > I agree.  How does one establish a mix of divergent approaches?  A chain
> > of trust is broken when each node checks a different mailbox-domain.  It
> > is also seems inappropriate to misapply a record intended for a
> > different mailbox-domain.  Handing multiple accountable identities is
> > daunting, especially when a change in convention between administrative
> > domains makes spoofing easy.  Correlating the mailbox-domain checked and
> > then displayed becomes another matter.
> > 
> > Regardless of the mailbox-domain checked, leaving authorization normally
> > open-ended overcomes present problematic header conventions.  Only
> > institutions dealing with a phishing problem would have an incentive to
> > tackle closing the authorization list.  Changing from an address-list to
> > a name-list overcomes exploits invited by an open-ended authorization
> > list as well, as this would imply a separate entity is utilized for
> > reputation. 
> 
> . o O Mmmmmm... I wonder just how it was possible that something like
> the KISS principle was completely cast aside instead opting to do the
> exact opposite.  

KISS Principles?

 1) Email authentication must aid security and reputation assessment.

 2) Only the administrator of each MTA is accountable for its security.

 3) Only a validated HELO-domain directly identifies the administrator.

 4) Lack of security is the principle enabler of spam.

 5) Reputation remains a principle tool to abate spam.

 6) Any mailbox-domain within a message is hearsay without a signature.

 7) Reputation should be based upon the administrator's response to
    notification of a security breach.

 8) Reputations based upon a mailbox-domain with a prescribed
    mail-channel invites litigation.

 9) A prescribed closed-ended mail-channel breaks SMTP.

10) An open-ended prescribed mail-channel, when combined with
    mailbox-domain reputation, invites spoofing.

11) An open-ended prescribed mail-channel, when reputation is based upon
    the administrator, does not invite spoofing nor breaks SMTP.

12) Prescribing a mail-channel using a root-name-list of HELO domains
    is achieved within a single lookup without the need for script.

13) Prescribing a mail-channel using a comprehensive address-list may
    require many scripts and perhaps hundreds of lookups to resolve.

14) Any script, especially extensible scripts, pose risk.

15) Script within email imposes greater risk than that in a browser.

16) Script within email & DNS imposes greater risk than script in email.

-Doug