Author: W B Hacker Date: To: exim users Subject: Re: [exim] Testing DKIM
l.rinetti@??? wrote: > Using Exim 4.71 on Ubuntu Server 10.04,
> i'd like to test DKIM on incoming messages: what i can do ?
>
> Thenk You
> Regards
> luciano
>
Couple of possibilities;
First, if you have not dones so already, activate Exim's DKIM parsing.
The ability is compiled-in by default, but the acl's are up to you to
'map' to an acl to activate use of it. See acl_smtp_dkim
For testing, use 'warn' class verbs, not deny-class.
'tailing' the logs may show you enough...
Second, 'mine' your own *existing* mailstore for messages you already
have with DKIM sigs. If no joy, grab some examples from mailing lists.
Submit what you have to an Exim debug run against your 'hopefully
correct' ~/configure.
The output will give you more than you wanted to know as to what acl's
are being traversed, and what would have been done if each such message
were 'live'.
For the most part, Exim's handling of 'incoming' DKIM should JFW so long
as you don't try anything 'clever' just yet.
Setting your server up to generate valid DKIM sigs of your own is a bit
more work, as you ALSO have to insure the DNS entries are proper.
While you do not HAVE to use DKIM at all, nor use it outbound, even if
checking it inbound, nor the reverse...
... once you publish a DKIM policy in DNS you really should intend to
adhere to that policy, as those who DO test DKIM will now expect it.
CAVEAT: DKIM presents 'extra' credentials that hope to improve the
likelihood that a message comes from an authorized source. It CANNOT be
assured of replacing the 'basic' BIND and smtp RFC mandated credentials,
as rejections for the absence of those (PTR RR and/or full rDNS check)
happen in CONNECT, well before the DKIM sig is even conveyed.
In your present situation, Exim's 'tahini' MTA accepted your post from
mail2.movimatica.com on IP 77.74.16.37
Many servers would have rejected that.
mail2.movimatic.com responds when pinged on that IP, but ...
host 77.74.16.37 ... times out w/o finding an answer of any kind, let
alone a proper PTR RR. Fatal, that.
dig mx movimatica.com
turns up both mx, and the 10-priority one, mail.movimatica.com, on IP
213.144.72.163 DOES return a PTR RR:
163.72.144.213.in-addr.arpa domain name pointer rigel-eth0.reteitaly.com
which in turn can be resolved back to that same IP.
That one MAY pass an rDNS test, as reteitaly.com matches even with no
further mention of movimatica.com.
