[ietf-dkim] Re: The Value of Reputation

[Douglas Otis]

On Jan 2, 2006, at 11:16 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> dangerous open-ended policies as seen with SPF. (Very bad.)
>
> Define "open-ended":

A set needs a definition for grouping.  In email, the obvious  
distinction for this grouping would be acceptance versus rejection,  
based upon an identifier being found in a set.  For SPF this would be  
an IP address list, and for SSP this would be signatures.  When  
acceptance requires the identifier be contained within the set, this  
could be described as Closed.  When acceptance does not require the  
identifier be contained within a set, this could be described as  
Open.  For example, depending upon the qualifiers, the empty set  
could be either Open or Closed.

For SPF the qualifiers are:
  "+" Pass  (Open)
  "-" Fail  (Closed)
  "~" SoftFail (Open)
  "?" Neutral (Open)

For SSP the qualifiers are:
  "~"  Signs some (Open)
  "-"  All signed & allow other signatures. (Open)
  "!"  All signed. (Closed)
  "."  Never sends mail. (Closed)
  "^"  Check User specific policy (deferred)


> I've no idea what you're talking about, or rather if it's NEUTRAL  
> you're wrong.

When an email-address domain owner is held accountable for abuse  
permitted by their "authorization" record, then whatever that is  
allowed as a result would impact upon their reputation.  When  
subsequently having their messages blocked by a faction of receiving  
MTAs, recovery would be difficult.  Those wishing to avoid such  
problems (coerced) would then be required to implement a "Closed"  
acceptance set.  Those authorizations defined here as "Open" expose  
the email-address domain owner to substantial risk of being unfairly  
held accountable, even though "Open" allows normal email practices.

Indications being displayed to the recipient that highlight messages  
found within a set of identifiers will likely mislead the majority of  
recipients.  Any "within the set of identifiers" indication would  
likely increase a success rate of fraud.  Bad actors can achieve this  
requirement the same as the good actors.  It would be very dangerous  
to expect the recipient would be able to recognize good actors from  
the bad based upon what is displayed by the MUA.


> And for your favourite "pure DKIM" I'd like to know what it's good  
> for:

The base DKIM draft offers a more stable identification of email  
sources, as opposed to the client IP addresses.  In the case of  
"phishing" attacks, only a minority of recipients even see the email- 
address, but instead see the "display-name".  To effectively abate  
these exploits, the content of the message must be examined for  
deceptive links and information that purport to be from a "phished"  
site.  Having a stable identifier upon which to compare valid  
messages from those that are invalid, these fraudulent messages can  
be blocked which a much lower false positive rate.  This effort must  
_not_ depend upon the From email address.  Making the From email- 
email address restriction disrupts how email is normally used, but  
relying upon the more stable DKIM source identifier does not create  
this disruption.

MUA can also make good use of a stable DKIM source identifier to  
recognize prior correspondents.  Highlighting those source  
identifiers as belonging to a prior correspondent would be a safe  
indication shown to the recipient, and would not depend upon their  
ability to recognize or even see the email-address.


> As an example, what exactly could say Ironport do with it?

If "binding advise" were added to the signature as described within  
the dkim-options draft, then a binding that assures the entire domain  
is always signed would allow refusal of non-signed messages.  This  
would not require looking up label trees of each email-address  
received, where the vast majority of the DNS lookups would not be  
cached.  This would require the repetition of several DNS lookups for  
each message.  The "binding" strategy avoids this overhead and avoids  
the misused "authorization" record.


> Organize senderbase more efficiently, would that be all, or what  
> else is the purpose of your "pure DKIM"?

Adding the Opaque-Identifier to the signature would also permit the  
detection of inter-domain spoofing without any email-address  
constraints being made by the MSA.  The Opaque-Identifier also offers  
a means to deal with abusive message replays.  This would not be  
"pure" DKIM perhaps, but it would not be an email-address  
authorization scheme either.  SSP is Sender-ID in a different suit.


> This "pure DKIM" needs some convincing reasons why senders and  
> receivers should bother to implement it, "helps to create white  
> lists" isn't good enough from my POV, but probably I just miss some  
> of your points.

Once MUAs offer the ability to recognize prior correspondents,  
especially those considered critical to the recipient, then not  
having just the base DKIM implemented would be a major short-coming  
in the eye's of most consumers that desire "safe" assurances.  SSP  
can never ever offer a safe assurance.   With DKIM used in  
conjunction with the MUA at the request of the recipient, there would  
be a _safe_ means to abate much of the fraud that seem all too  
rampant.  SSP can _not_ play a safe role in this endeavour however.

-Doug