Graham Murray writes:
"Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)com> writes:
Read the headers of this message and you'll discover that it is signed
with DKIM.
Yes, and my system (which should also sign this reply) shows it as a
DKIM failure. It seems that, like DomainKeys before it, DKIM does not
survive all mailing lists.
Correct. As I said, DKIM has issues of its own, and this mailing list
issue is a big one. Don't get me wrong - I am not a DKIM advocate, at
least not yet. I would object to misrepresentations of SPF on a DKIM
list as much as I object to misstatements about DKIM here.
DKIM does have one promising feature that addresses the mailing list
problem. Mailing list mail usually fails due to an appended footer,
and DKIM signatures can contain an optional "l=" tag specifying the
length (in bytes) of the signed message.
However, as the draft notes, using this to make DKIM ignore mailing
list footers when verifying signatures causes it to ignore anything
else that might be appended. In effect, it turns a DKIM-signed
message into a header that can be prepended to some other message
(such as spam) to pass DKIM verification. This in turn can be
partially addressed with an optional "t=" tag to specify an expiration
time.
(If you think fail vs. soft-fail is trouble, imagine fail vs.
partial-pass vs. pass-but-expired vs. partial-pass-but-expired.)
DKIM also has an optional "i=" tag to specify an "identity of the user
or agent (e.g., a mailing list manager) on behalf of which this
message is signed". That sounds a lot like a prime PRA candidate to
me.
So I envision something like this: first, use v=spf1 to check the MAIL
FROM, then use spf2.0/pra to check the "i=" tag if present or the M$
PRA if not, then use DKIM to classify the signature verification
state. All that remains then is specifying a matrix of what to do
with all the results.
I probably better duck ...
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com