On Friday, March 29, 2013 10:55 PM [GMT+1=CET],Elizabeth Zwicky wrote: > On Mar 29, 2013, at 1:14 PM, J. Gomez wrote: > > > I think this means that DMARC when using a "reject" policy breaks > > mailing lists. And that is ugly. > > Yes, DMARC p=reject will not allow you to send mail to mailing lists > reliably. p=reject is a suitable setting for transactional mail for > your brand, which is not a situation in which mailing lists generally > interfere. > > If you wish to set p=reject on a domain which contains people who > send to mailing lists, you have at least four options: > > 1) Decide that the domain does not actually send transactional domain > for a brand that needs protection from forged mail. Reconsider the > p=reject decision.
For me, it's either p=rejection or p=none. I don't want to put my IT team (or my correspondent organization's IT team) through the help desk hell of guiding users through the spam folder, etc. > 2) Decide that you do not care what happens to the > mail that goes to mailing lists or is forwarded, or actively > disapprove of it, and the mail that is saved either intentionally by > people trying to exempt mailing lists or accidentally by people not > enforcing DMARC is good enough. Set p=reject without doing anything > else except warning pe I do care what happens to mail that goes to mailing lists. There are legitimate business reasons for select users to be subscribed to mailing lists, and to do so using the company's domain in their email address. > 3) Move the individuals to another sending > domain. Set this one to p=reject. Not going to happen, convoluted and hard to justify to management. > 4) Move the transactional mail to > another sending domain, which is set to p=reject. Not going to happen, convoluted and hard to justify to management. > All of these options are popular. Sadly, so is > 5) Set p=reject without taking this advice into account and then be > shocked and horrified that mail you wanted to deliver is rejected. > > Admittedly 5 does happen in situations where it is under documented > -- but I have also seen 5 happen in response to mail that explicitly > said "Do not do this on a domain containing end users or you will be > sorry." Bottom line: if your domain contains users that send regular email, just use DMARC to get aggregate reports with p=none. On the other hand, if your domain is a big brand and regarding email it is mostly used to send one-way email notifications, then use DMARC p=reject and get full advantage out of it. Well, I do have users that send regular email, and I'm now seeing little incentive to implement DMARC processing in my systems. First, because I cannot get full advantage out of it without nasty side effects, and second because I cannot be sure that other people implementing DMARC are fully aware of it's implications. Regards, J. Gomez _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
