[ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
martijn.grooten at virusbtn.com
Thu Aug 5 07:35:30 PDT 2010
> On 8/4/2010 2:01 PM, John Levine wrote:
> >> There's a scenario where a spammer/phisher sets up a mailing list,
> > I don't see how this poses any new problems.
> More to the point is that this attack does not appear to be relevant to
> question I asked.
> Phrased differently, the question I am asking is:
> A mailing list digest does not preserve DKIM signatures from (any
> of) the
> original messages, and this appears to be acceptable to the community.
> Given that, why is it important to have those same signatures
> preserved, on
> the whim of a recipient's happening to decide to receive postings one
> at a time?
In my understanding, The Problem isn't that recipients want emails sent through a mailing list to preserve DKIM signatures. As you point out, it'd be a bit silly to expect that.
Rather, The Problem is that as a sender who DKIM signs their messages, you would _ideally_ want all your messages to arrive at the final recipients with a valid signature. If this were the case (and if you could be sure all your mail left your systems with a valid DKIM signature) you could publish an ADSP dkim=discardable record.
Mailing lists are one of the reasons why this isn't the case and thus I believe that only in exceptional cases one should publish an ADSP dkim=discardable record. However, if we could somehow find a way for DKIM signatures to survive list servers, it would be worth looking into. (Mind you, I don't think we can or at least not unless we reinvent email or something.)
Even if we will still have the "problem" of unsigned messages to arrive in mailing list digests. Because -- and that's why I mentioned the scenario -- there are phishing attacks possible that work through lists but are extremely unlikely to work when the message is part of a digest.
Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.
More information about the ietf-dkim