On 10.11.2014 20:45, Phillip Carroll wrote: > On 11/10/2014 4:12 AM, Patrick von der Hagen wrote: [...] >> Some other big sources of email like paypay, facebook, linkedin or gmail >> definitely know how to do DKIM, so you might check whether you get valid >> DKIM from those sources. It shouldn't be hard to send a test-message >> from gmail to your server if you don't see such traffic anyway. Having >> your bank send a test-message to gmail, so you can check their setup is >> not the culprit is certainly harder. > > I am not quite sure that I follow your reasoning with respect to PayPal > et al. It sounds as if you are asserting that if PayPal (et al) > signatures are declared valid by exim, then any email declared not valid > by exim is therefore not valid. If that is the reasoning, then I assert > that is fallacious reasoning. But yes, the emails I receive from PayPal > are asserted to have valid signatures by exim. My reasoning is simple: I don't know about your bank, I've never been in contact with them. But if those parties that send messages with valid signatures to me would fail your verification, I'd guess there is an issue with your own installation/configuration.
However, since you can confirm that DKIM-signatures are not broken in the general case and your problem is specific to your bank, I boldly state: your bank got it wrong. And I'd really place a bet, that the first server in the chain adds a valid DKIM-signature and the second one breaks it. Like adding a disclaimer to the message only if it is leaving the corporate network and thus breaking the signature in a way that is not detected by their staff if they only test their setup internally. > > What I just may do instead is play around with openssl a bit to > determine if I can manually verify the signature. > >>> or >>> (c) Or is the whole DKIM concept intrinsically broken? >> Let's not get philosophical. ;) > > Why not? ;) > > I prefer technologies that I can rely on to reject emails. spf has that > capability, if the site has -all. A technology that simply tells me only > "this is possibly fishy" if the email fails the test seems a bit weak. > Yet, that seems to be the universal advice with DKIM. OK, we can go there. I'll be short, though. SPF is completely broken, since it does not only rely on sender and recipient, but imposes requirements on all parties in between, which neither sender nor recipient have any influence on. (i.e.: if people do not implement SRS, forwarding will break SPF). You can't act on SPF-violation, since you as a provider are in no position to identify if there has been some additional forwarding taking place, intended by one of your customers. So it's quite lame, actually. DKIM is in theory way superior, since it only relies on sender and recipient and should be resilient to forwarding of emails etc. However, bad setups (issues with key-management, etc.) are more likely for DKIM than for SPF, and it will still be broken, for example by the exim mailinglist which adds "[exim] " to the subject, which is usually signed. Still, replacing mailman with sympa (for example) still involves less parties than implementing SRS on a global scale. Real-world-application: if you get spam/virus/phishing carrying a valid DKIM-signature, you can probably easily identify someone to complain to. But by reading Received-headers carefully, that's usually possible anyway. -- Karlsruher Institut für Technologie (KIT) Steinbuch Centre for Computing (SCC) Patrick von der Hagen Zirkel 2, Gebäude 20.21, Raum 005.1 76131 Karlsruhe Telefon: +49 721 608-46433 E-Mail: [email protected] Web: http://www.scc.kit.edu KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
smime.p7s
Description: S/MIME Cryptographic Signature
-- ## List details at https://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/
