ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests

2010-08-05 09:41:41
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
the
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.

Martijn.


Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>