You can install a recent opendkim package for your distribution, and
install it. Then run the raw, delivered email through it in a testing
mode and it will tell you if it successfully passes DKIM verification.
...Todd
Example:
KVM-CentOS[root@smtp4 ~]# opendkim -vvW -b v -t /root/6.eml
opendkim: using default configfile /usr/local/etc/opendkim.conf
opendkim: mlfi_connect() returned SMFIS_CONTINUE
opendkim: /root/6.eml: mlfi_envfrom() returned SMFIS_CONTINUE
opendkim: /root/6.eml: mlfi_envrcpt() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 1: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 11: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 12: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 14: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 15: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 16: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 17: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 18: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: line 19: mlfi_header() returned SMFIS_CONTINUE
opendkim: /root/6.eml: mlfi_eoh() returned SMFIS_CONTINUE
opendkim: /root/6.eml: mlfi_body() returned SMFIS_CONTINUE
### INSHEADER: idx=1 hname='Authentication-Results' hvalue='DEBUG-j; dkim=fail
reason="verification failed; unprotected key"
header.d=gmail.com header.i=@gmail.com header.b=UPsksNQm;
dkim-adsp=none (unprotected policy); dkim-atps=neutral'
### INSHEADER: idx=1 hname='DKIM-Filter' hvalue='OpenDKIM Filter
v2.9.2 DEBUG-j DEBUG-i'
opendkim: /root/6.eml: mlfi_eom() returned SMFIS_ACCEPT
opendkim: /root/6.eml: verification (s=20120113 d=gmail.com, 2048-bit
key, insecure) failed: signature verification failed
opendkim: mlfi_close() returned SMFIS_CONTINUE
On Mon, Nov 10, 2014 at 11:45 AM, Phillip Carroll
<postmaster@???> wrote:
> 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.
>
>
>
>
> --
> ## 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/
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
