DKIM Deployment

[James Morris <>]

There's potentially a subtle distinction that I've been pondering:  signing 
everything emitted vs. signing everything emitted "in your name".  

What I'm thinking about, as one example of many, are the folks that we have 
in West Africa currently.  They're using local ISPs that require they use the 
local smtp services.  Internet connectivity back to the rest of the world is 
spotty at best which precludes webmail for example.  For institutional 
reasons, they need to use their @washington email addresses.  There's no 
chance that I'd be able to sign those messages, nor would I trust the local 
ISPs to sign them for us.

I'm not sure that it's practical to sign everything "we" emit.  There are so 
many mail servers on campus and third-party vendors sending mail on our 
behalf that we could spend a year tracking them all down and trying, mostly 
unsuccessfully based on similar experiences, to arrange for signing.  

I think the reasonable starting place, for us anyway, is likely the 
low-hanging fruit of official mail and possibly authenticated user 
submissions.  Even those could have some pain points depending on the 
performance hit from signing.  

-J
---
James Morris
Lead Engineer
University of Washington

> -----Original Message-----
> From: Jesse Thompson 
> [mailto:]
> Sent: Monday, December 01, 2008 12:39
> To: Dave CROCKER
> Cc: RL '. Morgan; DDX
> Subject: Re: [ddx] sign everything?
> 
> Well, I think that we should take responsibility (and hence sign)
> everything we emit.  If we aren't willing to take responsibility for
> the
> messages, then we shouldn't send them.
> 
> For instance, we drop spam before forwarding to yahoo, gmail, hotmail
> and aol.  Our servers were being blacklisted because we forwarded spam
> on behalf of our users.  We weren't willing to take responsibility for
> the spam, so we started discarding it.
> 
> I agree that there are different "classes" of mail our servers will
> emit.  To name a few:
> A. official mailings (admissions, etc; very trustworthy)
> B. user submissions (trustworthy, but prone to compromise)
> C. forwarded mail (not trustworthy; might include spam)
> 
> Is it enough to use different d= names for each class of mail?  Such
> as:
> A. official-mailings.wisc.edu
> B. user-submitted.wisc.edu
> C. forwarded-for-users.wisc.edu
> 
> Is this on the right track?
> 
> Jesse
> 
> 
> Dave CROCKER wrote:
> > Bob,
> >
> > Yum.  What a tasty message.  Thanks for sharing.  Lots to chew on...
> >
> >
> > RL 'Bob' Morgan wrote:
> >> Assume a situation where your campus has a primary set of MTAs that
> >> most outgoing mail goes through for all kinds of purposes:
> >>   ... so not everything goes through the central
> >> ones, but most does. The simple assumption is that if your site
> >> decides to do DKIM it would sign all messages sent from these MTAs.
> >
> > I think this describes an environment where some of the mail is out
> of
> > the scope of control of the organization and hence the organization
> > should not be seen as taking responsibility for those message.
> >
> > Most organizations don't even know all of the MTAs sprinkled around
> > sending mail under the organization's domain name (in the From:
> field).
> > They couldn't sign everything even if they wanted to.
> >
> > Especially during early stages of adoption, this probably describes
> all
> > organizations, except very small and completely disciplined ones.
> >
> > At the least, it suggests trying to distinguish among different mail
> > streams to identify potentially different responsibilities.
> Something
> > from a Chancellor's office probably permits taking more
> responsibility
> > than from the dorms.  Sign them with different d= DKIM parameter
> domain
> > names and the receivers can develop different reputations for the
> > different mail streams.
> >
> > It's probably worth clarifying a basic point about DKIM:
> >
> >      DKIM does not certify that the contents of a message are valid,
> > that the author From: field is valid, or frankly that anything is
> true
> > or safe about a message except the signature.  Or, rather, the
> > identifier that is used in the DKIM-Signature: header field.  So,
> DKIM
> > is nothing like OpenPGP or S/MIME. Given that DKIM is touted as an
> > authentication mechanism, that sounds pretty bizarre.
> >
> >      DKIM is merely a way of associating a "responsible"
> organizational
> > identity to a message, where the exact meaning of "responsible" is
> not
> > really defined in the DKIM specification, except that the
> responsibility
> > is limited to transmission rather than necessarily having anything to
> do
> > with content.
> >
> > The responsibility is intended as a short-term assertion for use in
> > email transmission decision.  And the responsibility is at an
> > organizational level, rather than a personal one.  (OpenPGP and
> S/MIME
> > are personal and long-term.)
> >
> > So, the most basic meaning is that DKIM gives you an organization to
> > point to and contact, if there is a problem with the message.
> Someone
> > to blame and deal with.  That you can believe really is responsible,
> > rather than an identity that has been spoofed.
> >
> > Any responsibility beyond this needs to be developed over time,
> through
> > reputation assessment mechanisms.
> >
> > Therefore I think it can help discussion to re-cast your query as
> being
> > "what messages should the organization take responsibility for?"  And
> I
> > think that's really the view that your message landed on, toward the
> end
> > of your message.
> >
> > Especially during these early days of DKIM use and most especially
> > during the early stages of DKIM adoption, I suspect most folks will
> > decide that the answer would be to take responsibility for as little
> a
> > necessary to get the "important" mail delivered.
> >
> > Start small and grow carefully.
> >
> >
> >> At the meeting I think some people were nervous about that, since we
> >> know that there may be many sources of spam/phishing from our
> >> campuses, via stolen accounts, hacked machines, even enterprising
> >> students or staff.  If we sign everything we'd be tarnishing our
> >> reputations and obliging ourselves to take responsibility in some
> >> fashion for all that bad traffic.
> >> So we would restrict signing to some more well-behaved mail streams.
> >
> > Exactly.
> >
> >
> >> I think DKIM orthodoxy, on the other hand, says that indeed
> everything
> >> should be signed.
> >
> > DKIM has been a standard only for 1 1/2 years.  Prior to that,
> adoption
> > was only among a very small set of organizations.
> >
> > I think you are correct about what is the common view, but really the
> > orthodoxy is based on theory rather than practice.  As practice is
> > developing, or at least as people try to develop deployment plans,
> they
> > are encountering exactly the challenge you are citing.
> >
> >
> >>  I think the argument goes that if you are injecting
> >> messages into the Internet mail system then you are "responsible"
> for
> >> them whether you sign them or not.
> >
> > Certainly receivers would love to be able to base their decisions on
> > something that simple.  But they can't.  Anymore than they can treat
> the
> > promises of an organization's janitor the same as of a CEO.
> >
> > So the best that can reasonably be demanded of is that mail that is
> > signed distinguish between major categories of mail.
> >
> > It can help to think in terms of setting expectations in a way that
> the
> > signer has some chance of meeting.  Trying to sign everything allows
> > undisciplined mail to pollute the reputation of mail streams from the
> > more disciplined parts of the organization.  It sets the expectations
> > very high -- I would say too high -- from the start.
> >
> >
> >>     Signing just helps recipients determine more easily and
> accurately
> >> that it really was your MTAs that forwarded them.  If you let lots
> of
> >> bad mail go through and take no actions to stop it then your
> >> reputation will suffer in any case.  Signing doesn't make you more
> >> liable or accountable really, it just makes clear who the
> accountable
> >> party is.
> >
> > Exactly.
> >
> > d/
> 
> --
>   Jesse Thompson
>   Division of Information Technology, University of Wisconsin-Madison
>   Email/IM: 
>