Re: Email Server DKIM Configuration

[Derek Diget <derek.diget+educause-security () WMICH EDU>]

On May 7, 2013 at 08:24 -0400, Aaron Kirby wrote:
=>I'm looking for some feedback/comments from this group.  My organization is
=>currently implementing Email Authentication (SPF/DKIM/DMARC) for our
=>outgoing email traffic.

Don't forget to post something to the Higher Education Email 
Administrators mailing list.

        <http://listserv.nd.edu/cgi-bin/wa?LIST=HIED-EMAILADMIN>


=>We have been monitoring the traffic for a month or so and have noticed a
=>few interesting nuances related forwarding.  The situation is a user has
=>defined their primary contact email address, however, when the message is
=>sent to that address they most likely have an auto-forward rule to their
=>"real" primary contact email address.  The nuance comes in when we start
=>looking at the effect of implementing a DMARC REJECT policy.  A portion of
=>the forwarded email appears to be fine, however, there is a portion that
=>gets blocked.  The vast majority of the blocked forwarded email seems to be
=>coming from .EDU systems.   See the FAQ below I pulled from DMARC.org.


Note sure if it has made it into any FAQs, but there are several posts 
on DMARC-Discuss that say DMARC and "real users" don't work so well.  
DMARC's "reject" is directed at/designed for domains that only send 
transaction emails.


=>Couple of questions for the group
=>- Do .EDU servers modify the message in such a way that results in DKIM
=>failing?

Yes.  We see all kinds of broken MIME structures that get fixed up and 
thus break the DKIM signature.  What we have found is that a DKIM 
signature can only be expected to stay valid from one ADministrative 
Management Domains (ADMDs) to another.  It can't be expected to stay 
valid from submission to final delivery into a mailbox if there are 3 or 
more ADMDs.



=>- Do any schools out there have plans to help support the 
=>implementation of DMARC?

As a sender or receiver?  As a sender, the reporting is really nice to 
help determine where your users's are submitting messages.  Helps show 
forgeries, too.  If your goals are for messages sent with your domain to 
originate within your ADMD, then it will help.

As a receiver, it might be a little too new.  I haven't really looked at 
what it will take to collect the data and send the reports in our email 
infrastructure.


=>I'm a DMARC newbie so please excuse any errors in my note.

Ask on HEEA and the DMARC-discuss mailing list.


=>Thanks in advance for comments!
=>
=>
=>My users often forward their emails to another mailbox, how do I keep 
=>DMARC valid?DMARC relies on SPF and DKIM. In the case of forwarding 
=>emails, SPF is likely to fail, in a DMARC sense, at the receiver.  
=>You are resending from your infrastructure and it is unlikely your 
=>sending IP is in the SPF record of the domain contained in the from 
=>header of the email.

If you are forwarding and not modifying the RFC5321.MailFrom domain, 
then yes, you will break SPF.  You should probably be looking at SRS or 
some other address rewriting system.


=>However there is no reason for DKIM to fail. For 
=>DKIM not to fail, you must ensure that your mail server does not 
=>drastically modify the message. Typically, the only modification that 
=>preserves DKIM is to add new email headers to the messages without 
=>touching the subject or the body of the message. Headers protected by 
=>DKIM should not be modified in any way, and the message should not be 
=>converted from one encoding to another.

False.  re-encoding happens more that the DKIM folks what to 
acknowledge.  Again, DKIM from one ADMD (signer) to another ADMD 
(verifier) should work, but don't be surprised when a message that 
passes through an intermediary (forwarder?) breaks the initial DKIM 
signature.  That is why some mailing lists software verifies the DKIM 
signature, adds an Authentication-Results: header, and then resigns the 
message with their signature as they relay it on its way.


So in one view both SPF and DKIM need the forwarder to take 
responsibility of the message.  They verify on ingress, and then resign 
(RFC5321.MailFrom changed to use forwarders domain for SPF, DKIM gets 
new signature with forwarder domain) on egress.  The days of .forward 
files (or equivalent) are long gone if you care about message 
authentication/authorization.


Now saying all of the above.  We don't allow user's to automatically 
forward messages.  So what I say above is not first hand operation 
experience, but rather years of lurking and contributing in/on IETF 
working groups and other mailing lists/forums.



-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************