Calender invites are a known issue, and the issue is mentioned in RFC 7960.
The exact scenario is: User A creates a meeting and invites User B who is in a different email domain.User B forwards the invite to User C, who is in a different administrative domain than User B. The invite is sent using User A as the sender, so the invite fails DMARC tests. The problem does not occur if User A extends the invite to User C. The problem does not occur if User B and User C are in the same administrative domain,on the assumption that DMARC is not checked or enforced on messages that are internal to the administrative domain. For invitations that are relayed across administrative boundaries within the organization, email filtering exceptions should work around the problem. If not, the organization needs a different email filtering product. For invitations that are relayed outside the organization, the policy of the receiving domain will determine whether the message is blocked or allowed.. I would expect that most DMARC enforcers have encountered this problem and have developed a workaround to it. Or course, this WG or a spinoff could investigate ways for cooperating MUAs, to send invites that do not encounter this problem. As Laura Atkins said, DMARC implementation is not easy. Nonetheless, deployment is slowly increasing, not decreasing. It seems unlikely that DMARC enforcement will go away. ---------------------------------------- From: atyrsalvia=40agari....@dmarc.ietf.org Sent: 7/28/20 2:54 AM To: "dmarc@ietf.org" <dmarc@ietf.org> Subject: [dmarc-ietf] non-mailing list use case for differing header domains Hello, I recently had a conversation with Dave Crocker about proposed changes for DMARC, and mentioned a use case to him that is not well served by the current situation that is not a mailing list. He said it might be useful to share this to this list, so I'm writing it out here. A customer of mine is a large financial services company. Like many in that field, they have acquired several other companies over the years, and now operate multiple different brands, which send email using different domains... While many companies like this maintain one primary domain for corporate email and others only for marketing purposes, this company maintains multiple distinct domains even for corporate workplace email. The challenge is that they have many administrative assistants who send out meeting calendar invitations on behalf of the executives they support, and the executive and the assistant do not always use the same email domain. The resulting messages are not aligned, so they fail DMARC. To put it another way: assist...@firstbrand.com is organizing a meeting for executive@secondbrand.comassist...@firstbrand.com sends out a calendar invite from their own messaging client, using execut...@secondbrand.com in the From: fieldThe resulting message uses execut...@secondbrand.com in the friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.Both firstbrand.com and secondbrand.com are set to DMARC p=reject.Messages like this are then rejected by receivers that validate DMARC results. Whenever possible, they tell me they change the assistant's email domain to match the executives they support, but as people leave or change departments, they sometimes end up with assistants supporting executives across multiple different domains, so they can't ensure they always have the same domain. Maybe the ultimate answer for this customer and others in a similar situation is simply that this is a use case that can no longer be supported due to evolving security needs, and yet if that's the case, I thought it would be helpful to share a real world scenario that is currently impacted that isn't part of the previously existing discussion around mailing lists. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
