Main Nav

Message from 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. =>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/ ***********************************************************************

Comments

Message from akirbyco@gmail.com

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.  

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.

Couple of questions for the group
- Do .EDU servers modify the message in such a way that results in DKIM failing?
- Do any schools out there have plans to help support the implementation of DMARC?  

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

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


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.