On Mar 12, 2007, at 7:54 AM, Hector Santos wrote:
The original scope (SSP) was on track with addressing with what I
believe were the most marketable features of the product:
- High benefits for exclusive domain policies
Benefit is a rather general term. In marketing terms, a benefit
could mean greater opening rates and fewer false positive detections
as a spoof. Both of these benefits occur without SSP.
It is dangerous to suggest recipients will soon expect protection
with MTA filtering using some SSP policy assertion. This method of
protection is too prone to many types of visual attack. This
"benefit" also assumes recipients will remain unaware which email-
address has been assured by DKIM. For a mailing list, the email-
address being assured will differ from that assured when signed by a
first party. Perhaps the mail-list is trusted enough to allow first
party "policy conflicts" to exist within their messages. Should the
MTA operator make this decision for everyone?
In addition, SSP benefits will be nil when signing messages of public
accounts such as "[EMAIL PROTECTED]". SSP acceptance benefits
can be jeopardized by abusive replay. A high benefit should include
some means of protection.
- High benefits in exposing the nature of domain usage
Why would the nature of the message be placed into a generalized
policy statement? Whoever signs the message could make such an
assertion on a per message basis.
As a product producer, this is how I am going to be able to "help"
the "world of domains" outside my own control. It is what I see my
customers will desire, and at the same time, as a USER of the
product, I would like to also protect my own domains being
exploited and used at other compatible DKIM/SSP systems out there.
I would rather that they honor our DKIM/SSP own policies.
What happens when your customer happens to communicate through an
IPv6 to IPv4 gateway? What happens to messages when the IPv4 address
resolves to ipv4-gateway.com and signed by my-domain.com? Now
imagine the signing is for public accounts that have been rate
limited as a means to reduce abuse. In this case, the signature
still does not offer a basis for acceptance, as it remains easily
abused if it did.
For replay abuse, SSP could offer some real value. SSP could provide
a safe means to authorize the transmitter of the message, where when
the signature is found conjunction with a transmitter authorization,
the recipient will have been offered a safe basis for acceptance.
This would also prevent the signer's reputation from being damaged
due to abusive replays as well. It seems this is where SSP can offer
real value. For cases where transmitter authorization is not found,
receiver side rate-limiting can be employed instead.
We are simply not going to protect the entire spectrum of DKIM with
no or flexible SSP policies. But we can MOST definitely address
domains (HIGH VALUE or not, but HIGH VALUE will probably be most
interested) with "tighter" policies who simply do not expect MIDDLE
WARE and/or LIST SERVERS to be "touching" or passing thru such
mediums.
Anything created with a high value should include some means of
protection. The ability to replay a signed message may place even
"HIGH VALUE" signatures in jeopardy of no longer being white-listed.
SSP can defend the benefit of DKIM by offering a safe means to
authorize the transmitter. Sender-ID does not offer a safe means.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
