[ietf-dkim] ISSUE 1547: SSP-02: MX Record publishing mandateto reduce DNS overhead for SSP Discovery and to detectfraudulent messages
dotis at mail-abuse.org
Sun Feb 17 12:51:51 PST 2008
On Feb 17, 2008, at 9:32 AM, Hector Santos wrote:
> Douglas Otis wrote:
>>> I really don't see why it matters from where it sent and how. Do
>>> you have a preferred type of burglar knocking on your door? <g>
>> Many different doors could be helped by DKIM. While there might be
>> an expectation that those knocking at the front door will validate
>> their affiliation, there may be different expectations for those at
>> the back door. The difference might be as simply as not buying
>> wares from those at the back door. When someone escorts them to
>> the front door, they might be asked to validate their affiliation,
>> although likely unprepared to do so. While moving everyone to a
>> common doorway may seem ideal, this creates a significant problem
>> when the front door carries a greater obligation. Different doors
>> need different policies when there are different levels of trust
>> based upon the door used. At some distant point in the future,
>> perhaps all doors will be treated the same, but time has not arrived.
> That time came long ago.
> Remember, this is predominately about anonymous vs non-anonymous
> transactions and systems have always treaty anonymous and non-
> anonymous transactions differently.
> An anonymous back door is the last thing we want, although this
> strongly appears what the ASP model is promoting. :-)
DKIM is not about identifying the individual, so in that sense it is
not about anonymity. DKIM establishes an affiliation with a domain.
The identification of individuals depends upon how each domain handles
and marks their messages, where this is fully determined by what
messages the domain signs. *SP policy allows the purported author's
domain to establish domain affiliation requirements.
Do not suggest that *SP includes identification requirements. This
was declared out-of-scope when the WG charter was formed, and remains
a good recommendation. By establishing domain affiliation
requirements, the question of identification depends _completely_ upon
what messages the domain signs.
It is pointless for DKIM policy to impose requirements that a
signature validate a From header identity. RFC 4871 indicates that
signatures are valid when associated with _any_ header and can even
remain ambiguous with respect to who introduced the message.
Identification is clearly a decision of the signing domain that is
made when the signature is applied. It should not be the role of
verifiers to second guess whether the domain made the proper choice.
This choice is fully within the prerogative of the signing domain.
Nonetheless, DKIM will not be implemented across all message protocols
for practical reasons. Until such time, when a domain's policy states
that "all" messages are signed, in all practicality, this currently
means "all" SMTP messages are being signed. Over time, it would be
wrong to assume DKIM policy only pertains to SMTP. However, as far as
protocol gateways into SMTP are concerned, messages should be treated
"as if" the transport were SMTP, which may become problematic in some
cases. So in that sense, there is agreement.
So how can DKIM policy be structured to permit message protocols not
related to SMTP a means to separately announce when DKIM policy can be
applied? One solution suggested by Jim was to introduce a transport
scoping parameter within the policy record. Unlike the service
parameter within the key, policy scoping should also indicate which
protocols are used that do not support DKIM. It would be unreasonable
to assume all protocols will have implemented DKIM when policy is
published. It would be unreasonable for the policy record to change
as DKIM protocol adoption in the wild changes.
It would be safer and less work for policy scoping to list the
domain's supported protocols, and protocols the domain has implemented
DKIM. This listing could allow abuse to be blocked that might be
introduced through protocol gateways. This listing can also prevent
the undesired blocking of messages intended for non-SMTP
infrastructure when it is known the domain has not implemented DKIM
for that protocol. Such policy scoping would permit other message
protocols an ability to introduce DKIM policy independently from that
of SMTP, and to improve protections ASAP.
More information about the ietf-dkim