ietf-mxcomp
[Top] [All Lists]

Re: Sender-ID != SPF

2004-11-01 11:01:32

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







<Prev in Thread] Current Thread [Next in Thread>
  • Re: Sender-ID != SPF, Douglas Otis <=