Subject: [ietf-dkim] Some concerns with SSP impact on very small businesses

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 8 Jan 2008 15:02:07 -0500

All,

I apologize for being a bit late to the table... I've been working with
DKIM for a while now, but only recently sat down and read through the
details of SSP. 

I'm a bit concerned that widespread adoption of SSP, although it sounds
like it will work great for large organizations, will likely hurt a
large population segment of individuals, small businesses, and
non-profits. Many of these do not have the time, money, and/or expertise
to manage their own domains but are professional enough to want to
outsource their (outbound) email to a 3rd party service. Although each
member of this segment is small, collectively the segment represents a
very large number of people and small organizations. 

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.
[email-masked]), and is usually the primary electronic identity.
So the body From: address would be [email-masked], 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. 

In other words, once the major ISPs start publishing SSP records there
will be no way for people matching the above profile to avoid having
their mail marked as suspicious by SSP unless they stop using their ISP
email, which is most cases is the one that's recognized and trusted by
their customers. Until we get to the point where domain registrars make
creating authentication related DNS records foolproof so that
essentially anyone can do it, and until domain hosting services provide
email clients that are as familiar and robust as those of the major
ISPs, SSP is going to make life very painful for a significant segment
of the population once ISPs start publishing records with anything other
than dkim=unknown. 

How big is this segment? It mainly consists of some individuals, small 
businesses, and non-profits too small to manage their own 
domains who want more professional email and more delivery 
consulting than a simple ISP account can provide. Some fraction of these
do not even have a domain, and most of the rest have one but 
don't have sufficient access or technical expertise to manage 
it themselves (i.e., they may have a mostly static website, but 
generally don't use it for anything else including email). 

Unfortunately, I don't have a specific proposal on how to fix this
problem for the little guys without breaking the much-needed solution
for the large organizations. I'm hoping that in describing the problem
I'll trigger some new ideas that may help, or alternatively an
explanation of how this problem can already be addressed within the
constraints of the current version of the spec. 

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. 

Ellen Siegel
Constant Contact

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Jan 2008 18:49:15 -0800

On Jan 8, 2008, at 12:02 PM, Siegel, Ellen wrote:

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

Agreed.  A DKIM signature does not establish compliance for an email- 
address unless the selector is referenced at or above the email- 
address's domain.

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

Correct, but such a domain is unlikely to publish a restrictive  
policy.  Such a policy would reduce the utility of the domain's email  
by making use of mailing-lists problematic.  Mike's suggested partial  
signatures might offer a somewhat successful solution, but this would  
be a rather dangerous strategy that could defeat the purpose of using  
DKIM.

> In other words, once the major ISPs start publishing SSP records  
> there will be no way for people matching the above profile to avoid  
> having their mail marked as suspicious by SSP unless they stop using  
> their ISP email, which is most cases is the one that's recognized  
> and trusted by their customers.

TPA-SSP is a solution allows vanity domains to authorize third-party  
email providers such as "outsource.com".  These third-party domains  
should be authenticating identities using RFC 4409 and ensuring  
exceptions for From header are limited to email-addresses associated  
by procedures approximating that used to assign S/MIME certificates.   
A vanity domain could publish SSP "strict+TPA" and create a TPA-SSP  
for outsource.com's signature.  The TPA-SSP label is created by a  
utility that does a SHA-1 hash and base32 encoding of "outsource.com"  
that is published below the "_ssp." domain.

There would not be any need for a vanity domain share a private key or  
to delegate one of their subdomain's to outsource.com, or for  
outsource.com to apply different signatures based upon From header  
content.

> Until we get to the point where domain registrars make creating  
> authentication related DNS records foolproof so that essentially  
> anyone can do it, and until domain hosting services provide email  
> clients that are as familiar and robust as those of the major ISPs,  
> SSP is going to make life very painful for a significant segment of  
> the population once ISPs start publishing records with anything  
> other than dkim=unknown.

SSP currently does not offer enough flexibility for ISPs to make  
restricted policy assertions.   TPA-SSP however could allow email  
providers partition their domain and to assist owners of vanity  
domains obtain restrictive policy protections.

Ideally, SSP would provide a convention to assert the use of a TPA  
extension initially.  Not having a TPA extension defined may create an  
upgrade venerability for some domains.   Whatever assertion that might  
be used to replace "strict" or "all" to mean "strict+TPA" or "all+TPA"  
is not assured to be recognized otherwise.

> How big is this segment? It mainly consists of some individuals,  
> small businesses, and non-profits too small to manage their own  
> consulting than a simple ISP account can provide. Some fraction of  
> these do not even have a domain, and most of the rest have one but  
> don't have sufficient access or technical expertise to manage it  
> themselves (i.e., they may have a mostly static website, but  

At the relative cost of a CNAME, TPA-SSP permits subdomain signatures  
to partition a domain's policies without altering the domain used in  
an email-address.  TPA-SSP offers a solution that avoids the use of  
domain delegation or sharing private keys when asserting restrictive  
policies across third-party MTAs.   The number of places where TPA-SSP  
might be used is rather vast, as even dealing with mailing-lists  
signing with DKIM represents an administrative quagmire.  Partial  
signatures should not become a recommended solution for a mailing-list  
problem, nor should verifier based white-listing of domains be used  
either.

TPA-SSP offers a practical and simple method for domain owners to  
assert policy in a highly flexible manner, while avoiding difficulties  
associated with sharing private keys or delegating one's domain.  Even  
if administration of private key sharing or domain delegation could  
become practical, such a provider would be holding private keys for  
perhaps thousands of other domains.  Such providers would become a  
prime target, where a security breach would be devastatingly difficult  
to report and to defend against.  Such breaches by prime targets would  
significantly lower DKIM's credibility as a secure solution. : (

See:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt

I would refer to you the DKIM.org website, but this site erroneously  
references version 00 as an early proposal for SSP, rather than as an  
extension of SSP.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 08 Jan 2008 20:14:08 -0800

> though it is authenticated and even though the address belongs to the

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

> 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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 9 Jan 2008 10:53:47 +0100

Jim Fenton wrote:
 
> We need to make every effort to make everyone know that publishing
> 'all' or (particularly) 'strict' is not something that is done
> lightly.

+1  

It is similar for publishing PRA FAIL and SPF FAIL, so you are
not forced to start this education from scratch.   In a nutshell
policies allowing efficient identification of *suspicious* mails
will cut both ways, and limit some uses possible without such
policies.

Mechanisms allowing only to identify *good* mails like pure DKIM
don't have this problem, and on the other hand they can't cut ;-)

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

It's possible to use the SPF and PRA "exists" mechanism to figure
this out, but for SSP with its "first author" you'd miss exactly
the interesting cases (for SSP) if you log Mail From or PRA uses.

 Frank

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 9 Jan 2008 10:34:12 -0500

> -----Original Message-----
> From: Jim Fenton [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2008 11:14 PM
> To: Siegel, Ellen
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Some concerns with SSP impact on very small
> businesses
> 
> Siegel, Ellen wrote:
> >
an
> > included in the list of Verifier Acceptable Third Party signatures
at a
> proportion of domains that will ever be able to publish anything other

I hope you're right, and encourage you to drive this point with the
ISPs. It would also be interesting to get some direct feedback from them
on this point- it would be useful to have some data. ISPs tend to have
concerns with abusive use of their email addresses just as many other
large brands do, so I would tend to expect them to push for at least
dkim=all publication. If it is in fact reasonable to expect that ISPs
will tend to stick to 'unknown', then the impact on these small senders
should be relatively minor. 

Ellen

---

From: Jim Fenton <[email-masked]>
Date: Wed, 09 Jan 2008 07:28:46 -0800

> will cut both ways, and limit some uses possible without such

Unfortunately, I see efforts to encourage publication of SPF/SenderID
-all records without explaining all the implications of that so the
"education" being done there may not exactly be helpful.

> the interesting cases (for SSP) if you log Mail From or PRA uses.

I'm not sure I understand exactly what you're getting at, but if you
mean that the definition of author/responsible/From domain is different
in SPF, PRA, and SSP, that's true, and if the tool doesn't take that
into account, it might miss some interesting cases.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 10 Jan 2008 02:34:39 +0100

Jim Fenton wrote:
 
> Unfortunately, I see efforts to encourage publication of
> SPF/SenderID -all records without explaining all the 
> implications of that so the "education" being done there
> may not exactly be helpful.

I've no idea what the SenderID (i.e. PRA) folks do, but
the SPF site highlights the problem several times, e.g.
point 5 in <http://www.openspf.org/FAQ/Hints_for_ISPs>:

| You should never publish "-all" for customers domains
| without the consent of your customers. They *will* have
| ways of sending mail that you don't know about. Keep
| your customers informed about your SPF roll-out, this
| will prevent them from being unpleasantly surprised by 
| mail that suddenly is not delivered due to SPF "fail"
| results. Insufficient communication will drive up your
| support costs and result in your customers being less
| happy with both your service and SPF

 [tools to detect outgoing on mail from obscure places]
> I'm not sure I understand exactly what you're getting at

The "exists" mechanism can be used to track which IPs
send mail for a given domain (down to most local parts
if necessary), but of course only for what's checked,
HELO, MAIL FROM, maybe PRA, not "first author" unless
it happens to match the checked identity.  

> if the tool doesn't take that into account, it might
> miss some interesting cases.

Yes.  I'm lost how the tools you talked about can get
better data, or is it a case of senderbase datamining ?

 Frank

---

From: "J D Falk" <[email-masked]>
Date: Thu, 10 Jan 2008 13:03:27 -0500

> ISPs. It would also be interesting to get some direct feedback from
> them on this point- it would be useful to have some data. ISPs tend to
> have concerns with abusive use of their email addresses just as many
> other large brands do, so I would tend to expect them to push for at
> least dkim=all publication. If it is in fact reasonable to expect that
> ISPs will tend to stick to 'unknown', then the impact on these small
> senders should be relatively minor.

Any ISP is going to have to weigh the security of their entire domain
against the convenience desired by a few users.  Some will default to
the latter, some will choose the former.  This is all still very new --
we won't see a standard practice emerge for a few years, at best.

ESPs should think of this as an upsell opportunity, and encourage your
users to get their own domains so they can (pay you to) set their own
policies!

--
J.D. Falk
Receiver Products
Return Path

---

From: Mark Martinec <[email-masked]>
Date: Thu, 10 Jan 2008 20:30:32 +0100

Ellen,

> [...] they allow the customer to
> sending agent would be the 3rd party service (e.g. outsource.com). [...]
>
> address domain (yahoo.com). [...]
>
> their customers. [...]

Douglas Otis writes:
> by making use of mailing-lists problematic.

Here is my heretic view: in my opinion it is pretty much irrelevant
what SSP is published by a large ISP such as yahoo.com. Recipients
are free to associate any reputation (or spam score) to received mail,
independent, or in accordance, or in contrast with a published SSP.

Let's look at some data I collected from mail that we received (at
the ijs.si institute) during last two months or so. I'll concentrate
on yahoo.com (and gmail.com) mail as it was mentioned in the posting,
and as it offers a perfect example of what I want to show.

On all mail with a From address [email-masked], some is coming
directly from yahoo servers and is signed by DomainKeys, and
the rest is coming from other hosts, and as such is not signed.

The average SpamAssassin score (values below 1 are clear ham,
higher values, e.g. above 5 are spam) across all yahoo.com-signed
mail is around -1, i.e. very much clean and trustworthy.

Average spam score for all non-signed (or broken signature) mail
with a From address being yahoo.com is 27, i.e. outrageous spam!

I'd be an irresponsible mail administrator if I'd treat
yahoo.com-signed mail the same as other unsigned mail claiming
to be from yahoo.com but failed validation. It is natural to
treat as second-class all mail not bearing a valid yahoo.com
signature (e.g. assign few spam points to it), IRRESPECTIVE OF
SSP which might have been published.

With gmail.com this is similar, although less extreme:
- valid gmail.com signature, spam average = -3.9
- no valid gmail.com sign.,  spam average = +3.2

This demonstrates that these two service providers do take
their reputation seriously and they do take action on cases
where one of their mail accounts gets abused for sending
fraud or spam. Recipients benefit from their efforts only
on mail bearing a valid post stamp by an ISP.

As a side-note, the non-repudiation offered by signatures
facilitates the ISP's task of weeding abuse reports
into ones which can be acted upon (true mail account abuse),
and those which can not be acted upon, when a spam sender
just 'borrowed' a domain name but send mail directly.
I have a good experience with yahoo.com and their reacting
to every qualified abuse report I send them (once you
learn they can't deal with attachments but need original
mail in-line :)

So back to original topic:

- I think any user of a valid yahoo.com or gmail.com account would
be ill-advised to send his mail directly, instead of through the
native domain of his sending address. This is true today, and
will be even more pronounced in the future. Regardless od SSP.

- nowadays where practically all modern MUA clients are able to
authenticate on submitting mail, and mail servers not offering
some form of submission verification (SASL, TLS, pop-before-smtp,
IP checks, ...) are a rare bird, it is a poor excuse not to submit
mail through a native domain's mailers, even for roaming or home users.

Note that this distinction between mail coming through a native
domain and the rest is not specific to DKIM or to DomainKeys,
similar is achieved by other means, such as SPF, or even checking
the reverese DNS on an client's IP to fall under the domain claimed
in From.

Jim Fenton writes:
> [...] I am not aware of any consumer
> 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.

There needn't be any such explicit requirement. Senders will eventually
learn that it is to their best interest to submit mail through their
native domain.

> would have the same problem.

I hope this will be less and less of a problem. Mail submission
port is 587, not 25. While there are good reasons to block
outgoing connections to port 25, nobody in its good will should
be blocking outgoing connections to 587 (if they allow outgoing
connections to port 80). As a last resort, there is always a web
interface to mail submission.

> users to get their own domains so they can (pay you to) set their own

I fully agree.

  Mark