Re: DMARC Deployment

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

On Oct 21, 2015 at 10:30 -0400, Brian Epstein wrote:
=>I haven't deployed DMARC, yet, for the IAS, however, I have deployed
=>it for 5 other organizations that I am a part of.  In its first phase,
=>I have made all the DMARC and SPF settings pretty forgiving and am
=>collecting reports from domains to see how my users are doing.
=>
=>Once I gather a few months of details, I'll be in a better position to
=>write better SPF records.  I'm always amazed at the number of
=>legitimate third party places that need to send emails as my domain.

When you find these "legitimate third parties" are you contacting them 
to inquire why they feel they need to send emails with an envelope from 
address (RFC5321.MailFrom) that is not from one of their own domains?

For proper list/bounce management, these senders should be using a 
domain that they control.  Not yours.

Note the envelope from address is not what mail clients display to 
users.  It is used solely for the routing of the message.  The From 
displayed to users is the body from or RFC5322.From and that can and 
usually should be an address/domain of yours.  Take a look at the mail 
headers sent via any ESP (Contact Contact, MailChimp, etc) and you will 
see what I mean.  The domain in the envelope from (seen in the headers 
as Return-Path:) is the ESPs, but the body from (RFC5322.From) is an 
address of the ESP's customer.

With the proper set up with regards to SPF, you shouldn't be adding 
their (legitimate third parties) IP addresses to your record.  If you 
try to start adding every "legitimate third party" sender you will 1) 
exceed the DNS look-up limit in the SPF spec causing a PermError or 2) 
you will find yourself playing whack-a-mole with constantly trying to 
keep your SPF record up to date.


You would also want to work with them to sign any DKIM signatures with a 
key you have given them.  This allows them to set the body from with an 
address in your domain and use that to pass (hopefully along with 
their own SPF pass) DMARC.


=>After identifying those places, I'll probably start locking it down
=>and asking mail servers to start denying email from places not in my
=>SPF records.
=>
=>So, I definitely suggest adding the ruf= stanza to the DMARC record
=>for the trial period at least.
=>
=>Once I'm more comfortable with these other organizations, I'll start
=>the same process for ias.edu.


Also be in the look out for issues if you allow your user's to forward 
their email to other providers.  If you do allow forwarding, your mail 
flow should modify the envelope from to a domain in your control so SPF 
passes on the next hop.  Also, it will need to make sure it doesn't do 
any body modifications otherwise you will break the DKIM signature and 
thus fail DMARC.  This has been discussed recently on the Office365 [1] 
list as well as other lists.


1: Archives at <https://lists.ucdavis.edu/sympa/arc/office365>

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