On Oct 26, 2005, at 6:01 PM, Mark Delany wrote:
Risks to valid messages associated with these policies and a lack of
a defensive strategy remain the greatest risks to a successful
outcome. There are several that see From email-address authorization
mechanisms as the means for abating spam. I see this as a dead-horse,
I disagree completely. Since we're talking about a sender policy, each
sender is at liberty to inflict as much (or as little) damage on their
own traffic as they see fit.
This concept of "their" would depend upon how one defines message
ownership.
There are vast numbers of messages legitimately sent by those not
identified in the From header. Should these messages all be rejected
or deleted?
The current SSP prohibition is exclusively based upon the email-
address found in the From header and is the _only_ means available to
repudiate messages from Bad Actors.
The impact of only allowing this the sole choice is significant and bad.
As a receiver, I have zero problem with
that. If BofA can convey to me that no one can use their domain in
2822.From unless authenticated, I'd love to oblige.
There should be draconian measures made with respect to specific
domains impacted by phishing when they are willing to endure the
limitations. A simple mechanism that indicates which domains require
such protections would be more immediately effective than the
mechanism currently envisioned for SSP.
More importantly, the ability to constrain inappropriate use of a
domain is clearly the number one desire of high value domains. SSP is
often the *only* thing of interest to these folk wrt email
authentication.
I agree, and every effort should be made to allow these domains to
assert that they sign all "their" messages without negative
ramifications. When the term "their" considers who introduced the
message, then normal email services are not disrupted.
They could care less about the bits involved in
implementing DK, DKIM, SPF, Caller-ID, whatever. They care about the
consequential outcome and the levers they have to protect themselves.
At some point, this protection will include making the signing-domain
visible to the recipient. In the mean time, having DKIM widely
deployed with a large number of domains asserting that they sign all
of their mail, then far greater protections can be afford by DKIM.
Attempts to bind the assertion to the From address will result in
negative ramifications that will inhibit an otherwise greater number
of advantageous assertions and deployment of DKIM itself.
Far from being a dead horse, a workable SSP is probably the primary
motivation for adopting DKIM by such folk. If this group can't make
SSP/DKIM be a basis for solving those needs then we'll lose our most
valuable constituency - senders of value to our recipients.
By this statement, I assume you mean that DKIM must overcome
phishing. I continue to see phishing as representing as special case
that can be advantaged by DKIM. Don't consider using clever policy
records, however. It should be something that can be put in place
quickly for these limited cases. A single A record lookup at some
label, for example. Attempting to incorporate a text parsing program
into all SMTP applications is not something that can be done safely
in a hurry. A simple A record lookup to trigger the "phishing" mode
of protections could be defined and done quickly. It would and
should not need to be part of the DKIM protocols or signing
policies. It would likely be faster to put this mechanism in place
by NOT being part of the DKIM effort. : )
... and I do emphasize "basis". In a years time, maybe BofA will ask
us to reject content that contains their URL unless authenticated. I'm
amenable to that. In two years time they may ask us not to release a
BofA password from our Crypto-Wallet excepting to a matching
authenticated URL. I'm amenable to that too.
All good. But phishing protection will form a poor basis for
establishing a ubiquitous DKIM signature on all emails. The current
SSP policy will not allow the typical ISP to sign their email
traffic. Making the needed policy assertions will also break the use
of hundreds of email services. Hardly a good start. : (
I'm sure we'll get this SSP wrong. We will miss a whole bunch of
stuff. Exploiters will show our failings as soon as we ship. But we
will have a basis for SSP2 and maybe by SSP4 we'll get it mostly
right, but we need SSP1 to get the ball rolling.
I too want to see the ball rolling. First, target getting DKIM
signing all mail and allowing everyone that signs all of their mail
to safely indicate that they do without seeing email go missing or
enduring endless support calls. Trust that there is greater
intelligence within the system than at the end-point. : )
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org