[ietf-dkim] Consensus point on ADSP
Charles Lindsey
chl at clerew.man.ac.uk
Tue Mar 31 03:25:38 PDT 2009
On Tue, 31 Mar 2009 06:13:41 +0100, Jim Fenton <fenton at cisco.com> wrote:
> The second two cases are not my example. Concern #2 in my message has
> to do with messages where the signing address is a different address in
> the same domain as the From address. The correct test case is:
>
>> From someone at foo.example
> Valid signature from ietf-examples at foo.example
>
> Let's also use "all" instead of "discardable" as the test case because
> it's the harder problem to solve. As you point out, the mailing list
> should be acting on the Discardable practice rather than trying to send
> the message to the list.
>
> Let's say that ietf-examples at foo.example is a mailing list that re-signs
> mail sent to the list (or it could be a forwarder or similar agent).
> foo.example's mail server gets a message from an address in the same
> domain, someone at foo.example, that has no Author Signature or has a
> broken one. ...
But how come it had no Author signature? Presumably because it arrived
over some internal LAN, and internal mail is not signed (or all signing is
done at the point where mail is finally dispatched to the Big Wide World
outside).
> ... In accordance with the domain's policy, it subjects the
> message to additional scrutiny because of the "all" practices and lack
> of an Author Signature. The message passes this test and is sent to the
> mailing list manager.
So the mailing list manager, or some agent just prior to it, has satisfied
itself that it was a valid message from someone at foo.example (hence no
reason not to send it out to the mailing list).
>
> At this point, the mailing list manager would normally sign the
> message. Let's examine this with the i= and d= choices:
>
> Using i= as the basis for Author Signature, the list can sign the
> message, and the eventual verifier/assessor that does an ADSP check will
> see that it (still) lacks an Author Signature since
> ietf-examples at foo.example does not match someone at foo.example.
But we are agreed that (at least for now) we don't use i= as the basis for
Author Signature. The mailing list expander may well add
i=ietf-examples at foo.example, but that is just so humans (and maybe some
super-smart Assessors) can observe what has been happening. But, for
normal Assessors, that i= is just "opaque" stuff that it can ignore.
>
> Using d= as the basis for Author Signature, if the list signs the
> message, an eventual verifier/assessor will erroneously see that
> signature as an Author Signature, and therefore might not give the
> message the desired treatment. ...
Why ever not? It is From: someone at foo.example. The agent that signed it
has already satisfied itself that it is genuine ("additional scrutiny"
maybe), and it is signed with d=foo.example. It looks like a Author
Signature, it quacks like an Author Signature, therefore it IS an Author
Signature. Subsequent Assessors should be perfectly happy to accept it
(whether the ADSP for foo.example is "All", "Discardable", or anythng
else).
So where is your problem?
> ... Another option would be for the mailing
> list manager not to sign this message, which means it needs to do a
> special case not to sign messages if they're from the same domain and
> lack an Author Signature. This is certainly possible, but would be more
> challenging if the MTA manages many domains. I also think it's the
> wrong place to solve the problem.
Why should that be? It is either signed by the mailing list manager, or it
is signed by the outgoing gateway to the Big Wide World, or maybe both. So
who cares? Either way, it is sufficiently well signed for it to be
acceptable everywhere.
I just don't see what your problem is.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-dkim
mailing list