[ietf-dkim] Next steps for draft-ietf-dkim-ssp
MH Michael Hammer (5304)
MHammer at ag.com
Wed Jan 7 10:46:03 PST 2009
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.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.com> wrote:
> >> -----Original Message-----
> >> From: Jim Fenton [mailto:fenton at cisco.com]
> >> Sent: Tuesday, January 06, 2009 8:20 PM
> >> To: MH Michael Hammer (5304)
> >> Cc: John L; ietf-dkim at mipassoc.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
> >> requirement that they do). Someone spoofs a message from
> >> chair at ietf.org, which is of course unsigned. The message coming
> > of
> >> the list looks like it has an author signature. I have a problem
> >> 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,
> 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
> If it chooses 'unknown', then the list manager might adopt the (very
> sensible) policy of signing all list submnissions with
'i=lists at ietf.org'
> (Note that 'lists@' would probably be more sensible than Jim's
> 'ietf@'. I would not expect receivers to be particularly concerned
> the presence or absence of this signature, but individual recipients
> 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
> real name might be 'john') would have to arrange to submit his
> via the ietf server if he wished to use the From line
'chair at ietf.org'.
> More often, he would send it fron his own domain with a From line such
> 'john-ietf-chair at example.com', in which case the signing policies of
> example.com would apply. But if his message is sent to the list, it
> still attract an (additional) signature with 'lists at ietf.org'.
> would treat any other signature according to the example.com policies.
No, because lists at ietf.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.org', then it
> probably attract two signatures. Moreover, if he was foolish enough to
> sent it via example.com's servers, then Receivers ought to be treating
> with suspicion.
> As to whether the list manager ought to be rejecting messages that
> 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
> > Either the message has a valid signature or it does not. If there is
> > valid signature then ietf.org is claiming responsibility. If it
> > have a valid signature....then not so much. If ietf.org is sending
> > spoofed messages spoofing a "from" then it has a problem regardless
> > whether it DKIM signs, uses ADSP or does anything else..
> If ietf asserts 'all', and the message sent to the list by the chair
> the example.com server, and which receivers _ought_ to have treated as
> suspicious, passes the through on account of the list manager's
> then indeed you may have identified a valid point. But it is a point
> none of our drafts covers, nor was intended to cover, so I don't see
> a reason for mucking about with it at the present time. It belongs to
> 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.
More information about the ietf-dkim