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
|
|