|
Re: [ietf-dkim] Responsibility vs. Validity
2007-11-28 11:53:47
On Nov 28, 2007, at 5:35 AM, Charles Lindsey wrote:
On Tue, 27 Nov 2007 20:21:32 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
Not exactly.
-------
3.5 The DKIM-Signature Header Field
...
[Regarding i= tag]
INFORMATIVE NOTE: The local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may wish to
assert that although it is willing to go as far as signing for the
domain, it is unable or unwilling to commit to an individual user
name within their domain. It can do so by including the domain part
but not the local-part of the identity.
INFORMATIVE DISCUSSION: This document does not require the value of
the "i=" tag to match the identity in any message header fields.
This is considered to be a verifier policy issue. Constraints
between the value of the "i=" tag and other identities in other
header fields seek to apply basic authentication into the semantics
of trust associated with a role such as content author. Trust is a
broad and complex topic and trust mechanisms are subject to highly
creative attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not well
established, nor is its vulnerability to subversion by an attacker.
Hence reliance on the use of these options should be strictly
limited. In particular, it is not at all clear to what extent a
typical end-user recipient can rely on any assurances that might be
made by successful use of the "i=" options.
That almost, but not quite, says the right thing.
Essentially, the signature MUST include the From header (others are
at the signer's discretion). So, at a minimum, the signer is
asserting that this message came into bis possession via a route
that indicacted that its origin was within the domain within the
From (mailing list signatures excepted, of course). If the signer is
not prepared to vouch for that, then he has no business signing it.
Many providers do a good job, and only ensure behaviour of those
granted access. These providers might not require From email-address
vetting equivalent to that of S/MIME certificates before granting
access. Such a provider may wish to ensure recipients that their
outbound SMTP clients sign _all_ outbound messages. If this assurance
were possible, it could avoid complaints related to any spoofing which
does not include their signature. This is different from saying that
all email-addresses within the From header are assured to belong to
the purported author, as some might wish to assume. SSP does _not_
allow this distinction. SSP policy is From domain centric, rather
than from the perspective of the SMTP client.
This is a important distinction. The provider might only vouch for
the behaviour of their users, and not the accuracy of the From
header. Spam is defined based upon behaviour and not content, after
all.
This becomes problematic when large providers using DKIM end up
signing a fair amount of spam. The proper way to handle this spam
will depend upon knowing whether there are restrictions placed upon
the use of the From email-address.
Unfortunately, providers may assert an SSP "all" to mitigate spoofing
related complaints for messages they did not originate from their SMTP
clients. Before making this assertion, the provider instructs their
customers to submit using only their outbound servers without imposing
other restrictions. This provider might even assign keys with "g=*
+<group-number>" (based upon RFC 3598 sub-address extension)
restrictions for MUA signed by customers who complain they don't
always have access to the outbound servers. And yes, some firewalls
block port 587 for strange reasons.
When there are no or only limited restrictions on the From email-
address use, the email-address in conjunction with the signing-domain
should not be used as a basis for filtering spam. A method to handle
a situation of non-restricted From email-addresses being exploited by
bots would be to include an opaque identifier based upon the account
granted access. An opaque identifier could track bot compromised
systems independently from that of the From address. An Opaque
Identifier might be something as simple as u=<account-number> added to
the DKIM signature.
DKIM must ensure correct identities are used to block spam. For large
domains, blocking can not always be done at the signing domain due to
high levels of collateral blocking.
Likewise, if he goes to the trouble of including an "i=foo(_at_)bar(_dot_)com",
then he is asserting that foo(_at_)bar(_dot_)com had played some part in
introducing the message into his system. Otherwise, he should not
have included that tag.
The i= parameter include the localpart to enable a key assigned to a
group of users using the g= wildcard feature. The i= syntax has been
made necessary for a type of key which does not assure a unique
identity. Requiring the g= mask to be copied within the i= parameter
would be a change to the DKIM base specification. Not having the g=
parameter contained within the message makes spam related filtering
based upon the i= problematic.
So if the present documents do not make these things clear, then we
need a further (BCP?) document that sets out, in the form of a Code
of Practice, just what obligations are entailed by creating such a
signature.
There remains a problem related to a provider's desire to avoid costly
unwarranted complaints. SSP currently does not offer an SMTP client
centric policy assertion. This limitation will tend to distort how
Form header policy will be defined. This situation requires that
email-address restrictions must be made extremely clear. Expecting
this clarity based upon i= semantics remains problematic. The TPA-SSP
draft adds a scope= parameter that can be added to the non-TPA SSP
record to make this assertion explicit.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|