Siegel, Ellen wrote:
I'll walk though an example of how SSP is problematic for this segment.
The typical behavior for 3rd party services that cater to individuals,
small businesses, or non-profits is that they allow the customer to
choose the From: address that is used in their outbound emails so that
the email will be recognizable to its recipients. In general, this email
address will be an address from a large ISP (e.g.
joesbikeshop(_at_)yahoo(_dot_)com), and is usually the primary electronic
identity.
So the body From: address would be joesbikeshop(_at_)yahoo(_dot_)com, but the
sending agent would be the 3rd party service (e.g. outsource.com). The
email may be authenticated either by having outsource.com sign it
directly, or by creating customer-unique subdomains used solely for
authentication, but either way the signing would be done by
outsource.com.
With SSP in play, once the ISP (e.g. yahoo.com) decides to publish an
SSP record things start to go downhill. The above configuration will
always trigger a lookup since the signature will never come from the ISP
domain, and the Verifier will only look for the SSP policy in the From:
address domain (yahoo.com). Since it's unlikely that any third party
signature used by outsource.com on behalf of their customers (whether
it's outsource.com directly, or unique signatures per-customer) will be
included in the list of Verifier Acceptable Third Party signatures at a
given Verifier, a record with either dkim=all or dkim=strict will cause
the joesbikeshop email to be consistently labeled as suspicious even
though it is authenticated and even though the address belongs to the
author of the email.
The premise here is that a consumer ISP such as yahoo.com is going
publish an 'all' or 'strict' SSP record. I am not aware of any consumer
ISP that, as part of its Terms of Use, requires its customers to send
outgoing mail through its mail servers. There might be some that have
this requirement in order to do more effective outbound spam filtering,
but I'm not aware of them. In the absence of such a requirement, it
would be improper for these ISPs to publish an 'all' or 'strict' SSP, as
that would be, in effect, imposing a restriction that wasn't there.
Customers sending mail using their personal addresses through their
company's mail infrastructure, or from a hotel that blocks port 25,
would have the same problem.
Hopefully the consumer ISPs will recognize this. We need to make every
effort to make everyone know that publishing 'all' or (particularly)
'strict' is not something that is done lightly. I know of tools that
are under development to help domain owners know from where mail from
their domains is being sent, and hopefully this will raise awareness
too. I expect that it will be a small but economically significant
proportion of domains that will ever be able to publish anything other
than 'unknown'.
Disclaimer: I work for an ESP whose customer base is almost entirely
made up of this segment of senders, currently over 150,000 of them. We
know a fair bit about the profile of these senders. While I obviously
have concerns about the business model impact to the ESP, I'm trying to
focus here on the impact to the many, many individuals, small
businesses, and non-profits who will feel the impact should SSP in its
current state gain traction in the current ecosystem.
We've done our best (with key delegation in -base, for example) to
accommodate the needs of ESPs with DKIM, and hope (and expect) that SSP
isn't a problem either.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html