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: hagen@???
Web:
http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
