Arvel Hathcock wrote:
I suppose bad actors could also be construed as any person or process
which introduces unauthorized email message content change. I for one
will have to think on this one before answering.
Does anyone else have anything to say on this thread? Please post and
help us out.
--
Arvel
Here's what I think.
1. Who are the bad actors that DKIM is trying to thwart? Put another
way, if DKIM is deployed, what bad actors will have to find a different
way to perform their bad acts.
I think this is right on.
The bad actors are anyone who would use a domain name in an identity
header of an email message without authorization from the domain
owner. The same will have to discover a new means of doing so.
2. Where are these bad actors in the protocol environment? Where in
the email system do they pop up to perform the acts that DKIM is trying
to prevent. Again, different bad actors may appear at different places.
This is probably easier to answer in the negative. Where don't they pop
up?
A better question to answer might be where in the SMTP architecture can
they be stopped. At what points in the architecture is DKIM attempting
to stop them. Unauthorized use might in theory be stopped anywhere in
the MUA-->MSA-->[insert arbitrary number of MTAs here]-->MDA-->MUA chain.
It isn't entirely clear to me exactly where DKIM wants to live in this
chain. Is it a tool for the SMTP server to reject messages from SMTP
clients that are doing something unauthorized? Is it a tool for
post-acceptance filtering and routing in the MDA? Is it a tool meant to
give MUAs information to display to end users?
Given the transient nature of information in DNS, I think that any
technology that relies on DNS needs to be primarily a tool for the MTA
with the potential for secondary use at the MDA level if the latencies
are low enough. For MUAs, results need to be captured by the MTA/MDA
for display by upgraded MUAs.
I would answer this that these bad actors can pop up nearly anywhere in
the SMTP environment and so DKIM does not presume to try and figure out
the source of bad actors, just to detect and stop them as close to the
edge of the receiver's network as possible. I believe that the design
goal should be to enable DKIM rejection after DATA, but before
acceptance of a message from an SMTP client. This might also be a
useful MSA check.
3. What are the bad acts that DKIM is trying to thwart? The first two
questions are really background for this question.
These are so related it's hard for me to separate. Unauthorized
domain use is a means to several ends. The 'end' will determine
where, in the email delivery chain, the bad actor "pops up". When the
goal is to trash the reputation of a domain owner in the eyes of an
email user or ply some scam part of which requires the unauthorized
use of a domain to lend it credibility, the "pop up" is the MUA of an
email user and the effect takes place in the mind of that user. When
the goal is to thwart filtering agents or attempt to manipulate a
receiving domain's incoming email policy in some way the "pop up" is
at the point wherein those processes are invoked and the effect is in
reducing or rendering useless the effectiveness of those processes.
--
The bad act that DKIM is, I think, trying to prevent is unauthorized use
of 2822 mail identities. If that's so, some link to the policy
established by the 2822 mail identity domain owner would seem to be
essential.
I'm curious what those of you who have been arguing against inclusion of
SSP in the working group effort would define as the bad act that DKIM
will prevent in the absence of a sender policy of some kind.
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org