Re: [exim] DKIM, Mailing-lists and signing lengths

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] DKIM, Mailing-lists and signing lengths
Ian Eiloart wrote:
>
>
> --On 15 June 2010 14:55:55 -0400 W B Hacker <wbh@???> wrote:
>
>> Ian Eiloart wrote:
>>>
>>> --On 14 June 2010 11:59:30 -0700 Phil Pennock <exim-users@???>
>>> wrote:
>>>
>>>> I think that if you run a mailing-list manager which modifies content
>>>> at all, whether it's a message footer or Subject: manipulation, then
>>>> you should be looking to strip DKIM-Signature: from mails as part of
>>>> processing the mails. There's no need to embed any replacement
>>>> signatures or know anything more than "this is a checksum header, we're
>>>> breaking the checksum, strip the header out". It would probably be
>>>> more polite to rename it to Old-DKIM-Signature: rather than remove it.
>>>> And processing DomainKey-Signature: in the same way would be good.
>>>
>>> I think the recommended behaviour is to leave alone the original
>>> signature, and add your own. Given that mailing lists can break
>>> signatures, it's unwise to reject an email on the basis that it carries
>>> a broken signature.
>>>
>>
>> Well there yah go ... the pragmatic world bites again. And rightly so.
>>
>> But one of the reasons I've not been enamored of DKIM and predecessors from
>> the outset.
>>
>> While 'on point' - my suggestion that MLM admins strip-now-probably-broken
>> and replace with known-good sigs would (AFAICS) at least reduce the need
>> to give a pass to broken DKIM, AND centralize the source AS the MLM, not
>> sideswipe the validity of the creds of every possible poster TO a given
>> list ... means 'somewhat' fewer broken DKIM in the wild.
>>
>
> I think this somewhat misses the point of DKIM. Like SPF, it's used for
> authentication, not for authorisation.


ACK.. 'an attempt to enhance authentication' might be more realistic.

>
> Successful authentication with DKIM simply means that the message is
> unalterered (in certain respects) since it was signed by the signing domain.
> There are many ways that messages might carry broken signatures, including
> forwarding by DKIM unaware MLMs, and by MUAs.


ACK. Worse - not necessarily visible to the *end user*.

Breaking, for example a PGP-encrypted and signed. properly MIME-typed attachment
can happen also. But the end-user will be *highly* aware it has happened
regardless of what ANY intervening organization or device has done.

One of my biases against DKIM is that it relies almost entirly on sysadmins and
their tools - is NOT necessarily 'in your face' w/r the end-user at all.

>
> The DKIM specification says that a broken signature is to be treated like the
> absence of a signature.


'Yes but' - I think we are already seeing evidence that there WILL be sysadmins
who choose to reject on broken.

> However, a broken signature might help an administrator to trace a problem
> with an email, so there is some value in retaining it when forwarding.
>

Possibly so. Though - MLM-altered headers aside, I'm not sure it adds anythign
not already there in 'most' traffic (domain.tld and/or IP's all the way back to
the composing desktop, generally true even for the tahini mailman for example).

> The presence of a good signature simply means that you can (a) apply some
> kind of reputation assignment to the message on the basis of: (i) the
> reputation of the signing domain, and (ii) reputations that might be applied
> to the signed content in the context of the signing domain.
>


That is the intent, certainly. And it is an honourable - even laudable - intent.

But the model is 'just flawed enough' to make it insufficiently reliable to
accomplish the intended goal 'enough better' than older means to make it worth
the not-insignificant extra effort.

Enough admins realize that to decide not to bother with the added complexity of
just-one-more leaky bandage.

The resulting low takeup, in turn means exponentially lower usefulness.

Worse yet - it attracts enough of the malicious who apply a fake DKIM sig
that would not stand proper analysis that it behooves one to *penalize* all DKIM
signed arrivals with spam points 'just in case' - that being cheaper than
attempting a proper verifications that can fail.

That is already happening, and it does not bode well for increased DKIM takeup.

> and, (b) use the content of the message to modify your reputation database.
>
> An example of (ii) above might be that you could use the "From:" header
> address for reputation, provided that it's signed. You might only want to do
> that if the address domain matches (or, perhaps is a subdomain of) the
> signing domain.
>


All technically possible. But none of it buys anything I/we cannot already do
better, faster, and cheaper with *simple* means. IP's and DNS RR remain cheap to
check and expensive to fake well. Public RBL's run by a dedicated few have a
massive multiplier effect at cheaply serving many.

I will agree that - to the extent it has any value at all - retaining a prior
DKIM sig when traversing an MLM can be more useful to *someone* than stripping it.

I still believe that - IF/AS/WHEN DKIM is to be used at all - the MLM adding a
fresh sig with its OWN creds is the 'least-broken' or 'most supportive' choice.

Not that I personally expect to inevest any further effort in any of it.

PGP encryption and signing, or S-MIME leave all players out of the game but the
correspondents themselves. Let those who need it apply it. Else not.

Bill