-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles Lindsey
Sent: Wednesday, January 07, 2009 12:18 PM
To: DKIM
Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
On Wed, 07 Jan 2009 02:06:48 -0000, MH Michael Hammer (5304)
<MHammer(_at_)ag(_dot_)com> wrote:
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Tuesday, January 06, 2009 8:20 PM
To: MH Michael Hammer (5304)
Cc: John L; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
Suppose that ietf.org asserts an ADSP record but doesn't require
signatures on incoming messages, even from its own domain (there's
no
requirement that they do). Someone spoofs a message from
chair(_at_)ietf(_dot_)org, which is of course unsigned. The message coming
out
of
the list looks like it has an author signature. I have a problem
with
that.
If ietf.org is willing to put it's signature on the spoof message I
would assert that it has a DKIM problem more than an ADSP problem.
Ietf is no different from any other domain. It is entitled to choose,
in
its ADSP policy, either 'unknown' or 'all' or 'discardable'.
I absolutely agree. People can choose to do whatever they want. Remember
though, that inherent in the right to make choices is the right to make
suboptimal choices.
If it chooses 'unknown', then the list manager might adopt the (very
sensible) policy of signing all list submnissions with
'i=lists(_at_)ietf(_dot_)org'
(Note that 'lists@' would probably be more sensible than Jim's
original
'ietf@'. I would not expect receivers to be particularly concerned
about
the presence or absence of this signature, but individual recipients
might
like to inspect it if a message appeared suspicious.
If one chooses unknown I would question what one is doing with ADSP in
the first place.
But if it chooses 'all', or even 'discardable', then the ietf chair
(whose
real name might be 'john') would have to arrange to submit his
messages
via the ietf server if he wished to use the From line
'chair(_at_)ietf(_dot_)org'.
More often, he would send it fron his own domain with a From line such
as
'john-ietf-chair(_at_)example(_dot_)com', in which case the signing policies
of
example.com would apply. But if his message is sent to the list, it
would
still attract an (additional) signature with 'lists(_at_)ietf(_dot_)org'.
Receivers
would treat any other signature according to the example.com policies.
No, because lists(_at_)ietf(_dot_)org is not the From (if I follow you
correctly)
then that signature is irrelevant from an ADSP perspective assuming that
the list doesn't rewrite the from line.
Note that, if john did choose to use 'From: chair(_at_)ietf(_dot_)org', then
it
would
probably attract two signatures. Moreover, if he was foolish enough to
sent it via example.com's servers, then Receivers ought to be treating
it
with suspicion.
As to whether the list manager ought to be rejecting messages that
already
appear bogus, that is a separate issue (though one might expect list
members to be aware if his policy). It is not covered by any of our
present drafts.
That was exactly my point. The issue has nothing to do with DKIM other
than the list manager is choosing to take responsibility for the message
by signing.
Either the message has a valid signature or it does not. If there is
a
valid signature then ietf.org is claiming responsibility. If it
doesn't
have a valid signature....then not so much. If ietf.org is sending
out
spoofed messages spoofing a "from" then it has a problem regardless
of
whether it DKIM signs, uses ADSP or does anything else..
If ietf asserts 'all', and the message sent to the list by the chair
using
the example.com server, and which receivers _ought_ to have treated as
suspicious, passes the through on account of the list manager's
signature,
then indeed you may have identified a valid point. But it is a point
that
none of our drafts covers, nor was intended to cover, so I don't see
it as
a reason for mucking about with it at the present time. It belongs to
some
future Lists draft.
My point was that if someone is implementing ADSP then they need to
exercise due diligence and care in both their initial overall messaging
implementation and in their ongoing operations.
Receivers will do what receivers choose to do. They will whitelist,
blacklist, greylist, reputationalize, spam folderize, spindle and
mutilate. The sender cannot force them to do any particular thing. John
would at this point invoke King Canute.... I do so preemptively.
I don't think this is something a draft will fix. It's called think
about what you are doing.
Just my 2 cents. I might be a bit slow with any additional responses
this week due to operational overload.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html