Re: [ietf-dkim] SSP acceptance chart

On Nov 4, 2005, at 10:01 AM, Hector Santos wrote:

> ----- Original Message -----
> From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
> To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
>
> > The limitations of specifying the relationships between signing-
> > domains and email-address make SSP impractical.  Once SSP is
> > attempted however, one can expect that compliance will be coerced
> > where everyone must give up on seeing the email-address be
> > independent of the signing-domain, and where many things break.
> You have a very verbose way of saying that a Sender Authorization  
> Framework
> is the way to go here, a "Chain of Trust" concepts across the board.
An email-address authorization scheme has the unfortunate outcome of  
assuming accountability at the email-address rather than the signing- 
domain.  The chain of trust is broken when the signing-domain and the  
email-address domain are different, as they frequently will be and  
should be.  An opaque-identifier could be a mechanism that extends  
this trust, but that is also unfortunately missing as well.
With far less overhead, and risk to the email-address domain owner of  
being unfairly held accountable, would be opportunistically asserted  
bindings.  These would be captured automatically from messages where  
the keys are not delegated, and the email-address matches the signing- 
domain.  This on-the-fly record should be just as authoritative as  
any disparate DNS record.  This approach would not entail label-tree  
walking the domain of every email-address received, nor risk unfairly  
attributing accountability on the email-address.
> What I think you fail, no, choose to ignore, no, forget?, whatever,  
> is the
> issues of compliancy.
>
> As a SMTP vendor, how am I going to support backward legacy issues?
>
> It really doesn't matter what method is invented, in the end, the  
> issue of
> backward legacy issues is still a major problematic issue.
You seem to be ignoring the new requirements inflicted by SSP where  
the From header must be altered in thousands of applications to  
introduce two addresses instead of the normal one.

> I see DKIM is a relative simple "addition" that can raise the bar for
> DOMAINS who want to assure that their DOMAINS are not used outside  
> their
> authorized SENDER network.  SPF is the same idea, DKIM does it  
> differently.
Flat-out email-address authorization schemes will cause more grief  
than good!!!

> The key, which is what I think you realized is strategically  
> competitive to
> your DNA service ambitions, is that DKIM can work really well by  
> using a
> lookup concept, not to a REPUTATION system, but to the DOMAIN policy
> statement.
Are you kidding?  Abuse will not be curtailed by mandating a signing- 
domain and an email-address match.  Domains are a dime a dozen and I  
have no ambitions related to accreditation.  How do you envision SSP  
reducing the level of abuse?  SSP is more likely to instill false  
confidence in phishing attempts than preventing any.  You are  
advocating a scheme that tends to ignore the source of abuse as long  
it dances to your tune.  Spammers can dance as well as anyone.

> Even then, do you think you are going to convince people like me,  
> including
> operators that they should abandon DNSRBL lookups.
There are new threats emerging damaging the quality of this  
stalwart.  Although Dave Crocker seems to suggest protecting a DKIM  
process from attack is not related to DKIM, I find this a very  
serious issue worthy of discussion.  I don't want to confuse anyone  
in the process however.  There will be a need moving to a name-space  
mode with signature-based confirmations.  I see a CSA like function  
providing that requisite bridge of black-hole list to domain/ 
extension verification.  I would be interested to hear other views.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org