|
Re: [ietf-dkim] Re: DKIM and mailing lists
2006-01-19 16:43:27
On Jan 19, 2006, at 12:19 PM, Earl Hood wrote:
On January 18, 2006 at 10:20, Douglas Otis wrote:
Modifying the message is already a common practice by list-servers
and resigning a modified message may not overcome restrictions
imposed by a From email-address policy.
I wonder if there are any legal ramification of modifying messages.
It is common for list software to modify messages, but one could
consider this a violation of copyright law. If DKIM gets deployed,
legal ramifcations may become more probable.
On the contrary, if not obfuscating the signature causes harm when
used to abuse the reputation of the list participant, then perhaps
that would provide a basis to claim damages. Of course a list can
issue any AUP they desire, but the general design should be safe.
Not obfuscating the signature is not safe.
In the dkim-options draft, rather than restricting an email-
address, the goal was to identify unique sources and highlight
recognized correspondents. This included the ability to assert a
signing role such as mediator, as in the case of a list-server.
Adding a signing role avoids difficulties in classifying the
nature of the source and may squelch conflict notifications.
Would specifying which field a signature is asserting a role
against be sufficient?
Not as DKIM is currently specified. The single character "binding
and role" assertion in the dkim-options draft can be added to the
signature and would be upwardly compatible with the current scheme.
The role could even impose which headers are allowed to be associated
with the signature, as suggested.
Note, this does not preclude a signer from including any header
field in the signature. The role assertion only designates which
header fields it is applying a role to. This way, a mailing list
can add a signature w/o interfering with any SSP of an originator.
On the contrary, SSP interferes with the normal use of the From
header. : (
Taking the way SSP is defined now, it only needs to be examined wrt
the From field if a signature asserts a role against it. I.e.
Assertions against a known originating field (as defined in
RFC-2822) warrant an SSP check. This will allow domains to apply
DKIM signatures on messages without worrying if the domain
associated with the originating address disallows third-party
signatures since such signatures contain no assertion against an
originating header field.
I am not sure I understand this statement. The SSP needs to be
checked when the signature does not conform to the domain found in
the From header email-address, perhaps just the first or all. (Not
just when there is no signature as some have suggested.) Those who
are hoping what _may_ be visible to the recipient is being checked
will not want conformance based upon any other header. Of course,
what is visible remains within the control of the sender, social
engineering is a practiced art, and where native languages are being
used, any protection offered by this scheme remains highly dubious.
I am sure any phishers listening were delighted by the suggestion
conformance could be signaled to the recipient. : o
Note, this does not address your [Doug] overall concerns about SSP,
but only the security problems of allowing third-party signatures
as SSP is currently defined.
If a commerce site felt better about publishing a SSP record of
'o=!', there is no underlying problem with that concept, except it is
really painful to find this policy amongst millions of other domains
that still want to use list-servers, e-invites, etc. Most domains
make exceptions for large domains because of the constant background
of abuse coming from their servers. When DKIM becomes a basis for
acceptance, that background noise will be amplified a billion fold by
a replay strategy. It is also nonsense to suggest that list-servers
should be held to a higher standard than most large domains.
Jim just suggested that some protection can be achieved using an open-
ended policy that excludes unsigned messages. Beyond the issue where
messages are modified by a list-server and treated as unsigned,
signed messages may then quickly become the next spam-validating
commodity.
Not to be critical, but too many decisions have been made from the
perspective of being a big domain. For them, recipients want to
quickly identify these domains to white-list them so they are not
disrupted by a block-list. It is like the driver that throws away
their rear-view mirror because they are the fastest thing on the
road. For all those smaller domains, the concerns are much
different. What happens when bigdomain.com increases the ratings for
messages with an email-address policy? The email-address is then
assessed for abuse, regardless whether the policy is open-ended or
not. Heck, different types of policies are not a problem that
bigdomain.com ever sees.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|