On Jul 27, 2006, at 5:20 PM, Jim Fenton wrote:
Douglas Otis wrote:
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.
"Spreading" was perhaps not the right word to use. But the
signature is now coming from a different place, so whom it reflects
poorly upon is now changing. That makes it a fundamentally
different thing than key delegation. Allowing a domain to delegate
the ability to sign their mail and not holding the delegating
domain responsible at all seems undesirable in that it doesn't
discourage domains from doing business with dubious mailing services.
There are many organizations that use email-servers to attract users
and their eyeballs. Vetting customers is part of their cost of doing
business. DKIM makes reporting abuse easier, where then the report
also has a much greater signal to noise ratio. DKIM should make this
domain's life easier, so don't shed any tears or expect anything to
get worse as a result.
By design, DKIM is not obvious to the recipient without some type of
annotation. When just display-names are visible or international
domain names are used, the recipient may be unable to ferret out
spoofing attempts based solely upon strict OA policy. This issue is
indicated as having both a high impact and high likelihood in the
Threat draft. It seems reasonable to assume message annotation
conveys the signing domain when it does not match the OA.
It seems wrong to suggest a signature is coming from a different
place. The signature comes from where the key was obtained. The OA
is coming from a different place, but message annotations should make
this apparent. While the designation of signing domains by the OA
could be incorporated into message annotations, this is not really
required when the signing domain is conveyed. The signing domain
should also be annotated when found within a prior correspondence
list or address book.
As a separate issue from spoofing, message acceptance should improve
when associations are validated with the DSD list. It would be
surprising for Cisco to designate popular mailing list domains,
however. It would be likely that Cisco might create a separate
subdomain in order to establish different policy arrangements.
Perhaps for staff.cisco.com, the policy would look like:
staff.cisco.com Policy DSDL: <cisco.com> MODE: Open-ended (allows
the use of mailing lists)
cisco.com Policy DSDL: <cisco.com> MODE: Closed-ended (better
prevents spoofing of transactional messages)
blue-example.net DSDL: <blue-example.net>, <cisco.com> MODE: Open-
ended (allows use of companies outbound services and mailing lists)
This may mean that when you want to send messages to a mailing list,
[EMAIL PROTECTED] or [EMAIL PROTECTED] would be used,
instead of [EMAIL PROTECTED] The mode "open-ended" for
staff.cisco.com and blue-example.com also indicates the OA can be
signed by any other domain, or even not have a valid signature.
There does not appear to be a reason to differentiate between being
signed by some other domain, and not being signed at all. The
typical reason for allowing this exception would be to handle
messages damaged in transit, or messages sent through other outbound
services such as auction websites and the like.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html