Ian Eiloart wrote: > > > --On 15 June 2010 14:55:55 -0400 W B Hacker <[email protected]> wrote: > >> Ian Eiloart wrote: >>> >>> --On 14 June 2010 11:59:30 -0700 Phil Pennock <[email protected]> >>> 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
