Stephen Farrell wrote:
Hi Jim,
A couple of further comments on comments below. Other bits deleted.
I totally agree that the bigger issues should be addressed after
the wg is off the ground, and not before (unless Russ insists;-)
Jim Fenton wrote:
Stephen Farrell wrote:
>
5. Does section 5.2.2 cover cases like a mail from
"support(_at_)ebay(_dot_)example(_dot_)com"
signed by example.com's MTA? If not it should be covered somehwere.
If so,
maybe reword to make this clearer or else add an example which does so.
No, it doesn't; nor does it cover cases where the mail is signed by a
"lookalike" domain, e.g., bakofamerica.com or the famous examples
using internationalized domain names.
I'd argue that its worth saying that DKIM doesn't address these so
as not to confuse some readers. You could of course, argue that its
impossible to make a list of everything DKIM doesn't do, which is
true, but cases where there's liable to be confusion are worth
calling out IMO. Its certainly a matter of opinion though.
I have added a paragraph to the section on "Use of Specific Identities"
to discuss this.
8. DKIM can help a bit with message replay in that it can allow for
better
volume controls. Say if I keep a count of the number of times I see
a given
set of signature bits in a time window and once the count crosses a
threshold I
become more agressive in treating the message as spam. The point is
that the
signature itself is a handy reply detection value so even if I can't
detect
*a* replay, I can possibly detect excessive replay.
Sometimes you can, that's true. Large domains have an advantage
here, because they have more traffic to observe. Small domains are
in a tough position, because it's unlikely that they'll see many of
anything and the (mostly uncacheable) transaction load of looking up
signature values on a shared reputation system is likely to be very
large.
Hmm... Depends what "small" means I guess, but I'd have thought that
even so this is worth a mention since validly DKIM-signed mail at
least has a nice replay detection value, whereas other mail doesn't.
When I think "small", I think of my home domain as a limiting case,
which is about as small as they get.
It's true that you can use the signatures on validly DKIM-signed mail to
identify receipt of unusually large numbers of exactly the same
message. But you really don't need a DKIM signature to do this; you
could just calculate a hash over the (perhaps canonicalized) body and
selected headers, and remember that value. I think this has been done;
I'm sure someone else on the list can provide the specifics.
I suppose that this might also be of more importance in future if
mail based attacks become more directed at specific things.
The transaction load may be a killer in some cases, but that's
someone else's problem since DKIM is just enabling a service rather
than providing one and there will be circumstances where this could
be usefully done.
9. (Part of #2 above really but worth calling out) DKIM creates new
opportunities for service providers (key managers, DNS providers) to
sort-of
revoke a domain's ability to send mail. Those should be discussed so
we can
minimise them to the extent possible.
I'm not sure why this would more of an issue here than revoking a
domain's ability to receive mail by fiddling with their MX records.
Not necessarily more of an issue, but isn't it a bit different
since the DNS provider for the sending domain is now most likely
causing the vulnerability, rather than the DNS provider of the
receiving domain? IMO that's a significant enough difference.
I'm trying to understand why this would be an issue. What would be the
motivation for the DNS provider to do this, especially when a domain can
very easily move to a different provider?
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org