Hi, Povl, > Say I outsource salary processing to a 3rd party. They would want to send > mail > from main.com. But I instead created a DNS record like > selector.3rdparty.com._domainkey.main.com. > Then I could allow them to send mail on behalf of our company without that > company > having to manage different keys. They would just use 3rdparty.com dkim for > all outgoing. Would simplify it for them as well. And would probably make it > easier for the small companies performing services for multiple companies. > Just sign everything with the same key.
So basically you are stuffing the From: domain into the selector. That's sort of how Office 365 encodes domains that haven't set up DKIM, they are put into the selector, e.g., From: some...@example.com DKIM-Signature: s=selector1-example-com; d=example.onmicrosoft.com What I don't get is why you wouldn't a) Set up a TLS-cert based connector from subbrand.com and provision subbrand.com under the main.com customer b) Connect to Office 365 over that connector c) Send with SMTP MAIL FROM/From/DKIM d= domain of subbrand.com. Why do you need a different SMTP MAIL FROM and From? > Officially Microsoft is supporting dmarc, but we are having issues / a > learning curve. Latest is mails > sent to distribution groups expanded in the cloud (best gues for now) are > "reborn" as new mails, > and this is where we get the newly born mails with protection.outlook.com. I looked into that bug, it doesn't seem like a problem of SendOnBehalfOf, but appears to be an incoming vs. outgoing routing (i.e., identifying directionality of the message) or an attribution problem. -- Terry -----Original Message----- From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of Povl Hessellund Pedersen via dmarc-discuss Sent: Thursday, June 30, 2016 11:06 PM To: 'dmarc-discuss@dmarc.org' Subject: Re: [dmarc-discuss] SendOnBehalfOf in O365 Well, I see the suggestion as more than this. Say I outsource salary processing to a 3rd party. They would want to send mail from main.com - Subdomains is one way to fix this (give them salary.main.com ), but they would have to have keys /settings for all their customers (well, could be the same all customers creates CNAMES to). But I instead created a DNS record like selector.3rdparty.com._domainkey.main.com or selector.3rdparty.com._domainkey.salary.main. Then I could allow them to send mail on behalf of our company without that company having to manage different keys. They would just use 3rdparty.com dkim for all outgoing. Would simplify it for them as well. And would probably make it easier for the small companies performing services for multiple companies. Just sign everything with the same key. I don't see it as complicating things, and it could fix more than the on-behalf-of. But of course it would take time to get deployed. I could probably make a pull request for some OSS software, as this change is trivial. Getting Microsoft to implement a new a new X-behalf-header in the installed base will take many years. I think the on-behalf-of should be rethought, and maybe get it implemented in some SMTP or mail header RFC. But I still feel the dmarc change would be good. Officially Microsoft is supporting dmarc, but we are having issues / a learning curve. Latest is mails sent to distribution groups expanded in the cloud (best gues for now) are "reborn" as new mails, and this is where we get the newly born mails with protection.outlook.com. The distribution group has an internal address, so no dkim. So when it is reborn outside our tenant, it also has no dkim. All headers say it comes from the Internet, so no dkim, and unaligned spf => dmarc=fail. I can handle it somehow in filtering (transport rules), saying anything with smtp.helo = protection.outlook.com and SPF=pass should be allowed, but there is a potential this would allow spoofed mails as I see it. But they would have to come from a Microsoft customer. To get more orgs to implement dmarc, it is important that large providers as Google and Microsoft makes it relative painless. It has been a steep learning curve, especially for our operation architects to really understand how it works. And every single special-case will make the project seem almost impossible. I have 5-6 more domains for daughter companies (in our tenant) I will implement it on very soon with p=quarantine. Here we don't have cross-domain issues I think, but the SPFs might not be updated. But the issues with reborn mails with no dkim is almost a showstopper for full quarantine implementation. As it looks for now, Exchange Online at least raises uncertainty about if we can implement dmarc policy on outgoing mails. For the cross-domain stuff, we will change the identified main.com shared mailboxes to subbrand.com For those that needs to be real cross-domain, we have to dictate that no sendonbehalfof, only sendAs. Microsoft probably has identified the problem, as for shared mailboxes there is no SendOnBehalfOf in the GUI, has to be set using powershell. We use it since we came from Lotus Notes, and are used to it from there. So it is almost considered legacy. -----Oprindelig meddelelse----- Fra: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] På vegne af Terry Zink via dmarc-discuss Sendt: 30. juni 2016 18:18 Til: Povl Hessellund Pedersen via dmarc-discuss <dmarc-discuss@dmarc.org> Emne: Re: [dmarc-discuss] SendOnBehalfOf in O365 > This is implemented by Microsoft by using header.from = > sha...@main.com - And then they use Sender: u...@subbrand.com and > picks the subbrand.com domain for dkim signature. Smtp.from is also > u...@subbrand.com To clarify, Office 365 requires the message to be attributed to a particular tenant (either a fully hosted mailbox, or attributed to a customer using a connector [TLS-cert based or IP-based]). If so, it uses the domain in the SMTP MAIL FROM to assign the d= domain in the DKIM signature. If it is <>, it uses the domain in the header.from. So in your case, you have: SMTP MAIL FROM: u...@subbrand.com From: sha...@main.com Sender: u...@subbrand.com DKIM-Signature: d=subbrand.com Appears in Outlook as "From: u...@subbrand.com on behalf of sha...@main.com" Appears in most other clients as "From: sha...@main.com" I'm not that familiar with the architecture of shared mailboxes, but rather than changing how DMARC works (and getting industry adoption), more likely Office 365 will play around with the From/Sender/Reply-To/Display Name to get SPF/DKIM/DMARC alignment. -- Terry -----Original Message----- From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of Povl Hessellund Pedersen via dmarc-discuss Sent: Thursday, June 30, 2016 12:33 AM To: 'dmarc-discuss@dmarc.org' Subject: [dmarc-discuss] SendOnBehalfOf in O365 Hi, We are using O365, with multiple domains, call them main.com and subbrand.com - in the same tenant + AD domain. We have people in subbrand.com sending mail "onBehalfOn" of the sha...@main.com mailbox. The advantage of this is, that the recipient can see the name of the consultant who answered. This is implemented by Microsoft by using header.from = sha...@main.com - And then they use Sender: u...@subbrand.com and picks the subbrand.com domain for dkim signature. Smtp.from is also u...@subbrand.com The result is, that spf is valid but unaligned, and dkim is valid but unaligned. By giving u...@subbrand.com SendAs permission on the shared mailbox, all u...@subbrand.com identity information I stripped, and we get correct aligned spf and dkim. But the recipient can't see who was original sender. To fix this, and support the SendOnBehalf I suggest that a feature is added to DMARC / DMARC validators. Have it lookup the subbrand selector on the main domain if there is a signature. Say I get a subbrand.com signature, but RFC5322.from is main.com, then looking up the selector1.subbrand.com._domainkey.main.com and validating that would solve our issues with multiple domains. It would work for this case, and could still be limited to the one DNS lookup, as DMARC would see the DKIM does not match the RFC5322.From, so before even validating it would lookup in main.com domain, using the joined s+d as a new selector. Would also make it easier to outsource other mail processing. Example of mail that could be dmarc validated this way. From: Logistik - Shared Mailbox < logis...@main.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=subbrand.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/7WJf8aDqzLc+Rk1lvDhG/l0uAPN+ _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fmailman%2flistinfo%2fdmarc-discuss&data=01%7c01%7ctzink%40exchange.microsoft.com%7c7e31ed10a4784499ce9f08d3a0b96ad4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00jZ2v1ProjUbMRzA0R6WHJD28l%2bwa7eAvkdSWYi2BQ%3d NOTE: Participating in this list means you agree to the DMARC Note Well terms (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fnote_well.html&data=01%7c01%7ctzink%40exchange.microsoft.com%7c7e31ed10a4784499ce9f08d3a0b96ad4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oeMFM%2biC0TeWTu%2bUCrV%2bMlFPivGqqKihiChlWslG9DQ%3d) _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fmailman%2flistinfo%2fdmarc-discuss&data=01%7c01%7ctzink%40exchange.microsoft.com%7c9ae39b790ff5456fe82408d3a1769efa%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bNE2f9%2b1hDyVJD4zXoZYf70FE3Bg%2bLciZ4YrxJId3Tw%3d NOTE: Participating in this list means you agree to the DMARC Note Well terms (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fnote_well.html&data=01%7c01%7ctzink%40exchange.microsoft.com%7c9ae39b790ff5456fe82408d3a1769efa%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3c7kWPGBAemrZSlbPRjvY8DdE6lfov9ztjtpL1wtUHs%3d) _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fmailman%2flistinfo%2fdmarc-discuss&data=01%7c01%7ctzink%40exchange.microsoft.com%7c9ae39b790ff5456fe82408d3a1769efa%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bNE2f9%2b1hDyVJD4zXoZYf70FE3Bg%2bLciZ4YrxJId3Tw%3d NOTE: Participating in this list means you agree to the DMARC Note Well terms (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fnote_well.html&data=01%7c01%7ctzink%40exchange.microsoft.com%7c9ae39b790ff5456fe82408d3a1769efa%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3c7kWPGBAemrZSlbPRjvY8DdE6lfov9ztjtpL1wtUHs%3d) _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org 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)
