ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: The Value of Reputation

2006-01-03 12:28:36

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





_______________________________________________
ietf-dkim mailing list
http://dkim.org