Re: [exim] DKIM in exim: Broken?

On 11/10/2014 4:12 AM, Patrick von der Hagen wrote:
>> Yet, this appears to not be possible with the version of exim I am using
>> (4.80.1). I have the DKIM checking enabled, I know that the emails I am
>> looking at were sent with valid signatures and have not been altered in
>> transit, yet exim asserts (in the log) for each and every email we
>> receive from Chase:
> I'm curious how you know that those were valid signatures and no changes
> took place in transit?

My exim configuration implements spf checking. My server receives these
emails directly from a Chase server whose spf record matches the IP of
the sending host. All servers in the transit are Chase's own servers.
So, on that basis, I can believe the email is validly from Chase.

Furthermore, I reject any that fail spf, so as a practical matter I can
rely on spf and forget about DKIM for Chase. I am more concerned about
the reliability of DKIM in general if it gives false negatives, because
some other sources may have only DKIM but not spf to rely on.

When I asserted I "know" that the bank's emails were signed correctly, I
admit that assertion was NOT based on actual certain knowledge. Instead,
it was based on a more heuristic sort of reasoning:
(a) This is one of the world's largest financial institutions
(Multiple trillions of dollars on deposit, tens of millions of accounts)
Their alert emails come from a massive server farm in NYC, operating
under a single domain, not from my local bank branch. These are all
signed with the same certificate.
(b) Among the millions of emails it sends daily, if the ones I
receive have faulty signatures, surely the ones sent to me are not the
only ones signed faultily?
(c) If then, millions of emails with faulty signatures are being
sent, how is that no one else has discovered this, or if they have, why
has an institution with trillions on deposit done nothing to fix the
problem?

Please note: In the signature, d=alertsp.chase.com, s=smtpout. These are
generic for the entire Chase empire.

> 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.

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.