Re: [ietf-dkim] requirements
2006-07-27 16:29:29
On Jul 27, 2006, at 3:40 PM, Jim Fenton wrote:
3) have the ability for the policy statement say that a provider
(s) legitimately signs for that domain.
The potential scaling problem with multiple providers in (3) is one
of my main concerns with this approach. I have heard of
enterprises with upward of 100 authorized mailers, so this has real
potential to be an excessively long list.
For large enterprises, establishing formalized arrangements where
either a zone is delegated or a private key and selector information
is shared with trusted vendors will likely be a typical solution.
For a vast number of mom and pop outfits, a list of providers
offering their outbound services would likely never require anything
more than a few names. If mom and pop are also active on many
mailing lists, they may also want to express their list as "open-
ended" at this time.
I have a somewhat less tangible concern, too. If example.com
publishes an SSP record saying that some mail provider is an
authorized sender, and there is an abuse problem, will example.com
feel the same responsibility for the use of their address as if the
message had been signed directly "by" their domain? They may not,
and I view any spreading of the responsibility to be undesirable.
Regardless of the OA, spam will reflect poorly upon the signing
domain. Reports of abuse and expectations of who will resolve an
abuse issue always falls to the signing domain. There will not be
any "spreading" of responsibility. There is no means to know whether
the OA is even valid! The identity of the OA depends upon the
assertion made by the signing domain.
We have put in lots of mechanisms for domains to delegate signing
authority: they can delegate individual keys, the entire
_domainkey zone, or a subdomain of that. Mailing providers are
free to use the same keypair to sign for all of their customers, if
they want to assume that risk, and they only need to apply the
right domain name and selector when they sign. Is that really a
big burden?
Yes. For a mom and pop outfit depending upon their ISP for outbound
mail service, setting up DKIM signing or zone delegations would be a
big burden. The support required to handle key or zone arrangements
would be an increased expense that might impeded DKIM adoption.
Setting up a static DSD list should be much less effort. The DSD
should also represent a significantly lower burden for smaller
outfits. They should still obtain improved annotations and be
affording added protections when their list is closed. If there is a
problem, mom and pop would then know where to complain, their
provider. They can always find a new provider as well.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [ietf-dkim] The URL to my paper describing the DKIM policy options, (continued)
- RE: [ietf-dkim] The URL to my paper describing the DKIM policy options, Bill.Oxley
- Re: [ietf-dkim] The URL to my paper describing the DKIM policy options, Scott Kitterman
- [ietf-dkim] requirements, Michael Thomas
- Re: [ietf-dkim] requirements, Scott Kitterman
- Re: [ietf-dkim] requirements, Michael Thomas
- Re: [ietf-dkim] requirements, Scott Kitterman
- RE: [ietf-dkim] requirements, Bill.Oxley
- Re: [ietf-dkim] requirements, Michael Thomas
- Re: [ietf-dkim] requirements, Douglas Otis
- Re: [ietf-dkim] requirements, Jim Fenton
- Re: [ietf-dkim] requirements,
Douglas Otis <=
- Re: [ietf-dkim] requirements, Jim Fenton
- Re: [ietf-dkim] requirements, Hector Santos
- Re: [ietf-dkim] requirements, Douglas Otis
- Re: [ietf-dkim] requirements, Hector Santos
- Re: [ietf-dkim] requirements, Jon Callas
- Re: [ietf-dkim] requirements, Hector Santos
- Re: [ietf-dkim] requirements, Douglas Otis
- Re: [ietf-dkim] requirements, Michael Thomas
- Re: [ietf-dkim] requirements, Arvel Hathcock
- Re: [ietf-dkim] requirements, Douglas Otis
|
|
|