Re: [dmarc-discuss] A bit quiet?
> On Jan 17, 2017, at 4:56 PM, Brandon Long via dmarc-discuss >wrote: > > Someone asked a followup question here, and something else occurred to me. > > If you go to p=quarantine and pct=0, Google Groups will still do the > rewriting, but no one should enforce the quarantine. I know this is true for > our own code, but I don't know how well others handle it to know if it's a > safe thing to do or not. That’s awesome. Do we have enough implementers on this list to gain any confidence on whether or not p=quarantine and pct=0 would enforce quarantine or not? Thanks John > > Brandon > > On Fri, Oct 28, 2016 at 4:30 PM, Brandon Long wrote: > This sounds likely to be messages from your domain that were forwarded by > Google apps, most likely mailing lists. > > If the message was authenticated inbound to the mailing list, it will be > signed outbound by the domain hosting the list. > > If you were p=reject or quarantine, we would rewrite the from. It's > unfortunate that we don't rewrite while you are p=none, I'm unsure whether we > should change that or wait for arc. > > As everyone knows, rewriting isn't a great experience, which is why we > haven't done it for p=none, but if it makes the reporting too annoying to go > to p=reject, we should rethink. > > Also, if you're using a third party to analyse your rua reports, perhaps they > should do more to help for this case. > > Would it help if we reported these as a passed by local policy, since they > would by xoar? > > Brandon > > > On Oct 27, 2016 8:19 PM, "Roland Turner via dmarc-discuss" > wrote: > John, > > > My apologies, I appear to have misinterpreted this completely, not sure what > I was thinking: > > • DMARC reports are sent to the address specified in the DMARC record > associated with the 5322.From address, not the source IP addresses. > • Therefore, these reports are sent to you because the 5322.From header > contains an akamai.com address. > • The examples that you're citing showing a 5321.MailFrom address (with > SPF pass) and DKIM d= domain (with DKIM pass) that are aligned with each > other. This suggests either (a) a message sent legitimately by yourselves and > legitimately forwarded or (b) an impersonation, also legitimately forwarded. > It is to be hoped that Google's DMARC reports preferentially report on > DMARC-aligned DKIM passes if they're present, suggesting that the messages in > question are passing through DKIM-breaking forwarding (case (a)) or lack DKIM > signatures (hopefully case (b)). > I'm guessing that you'd already worked this out. > > > The forwarding cases are the awkward corner case for DMARC. As a domain > owner/registrant there's probably not much that you can do about this. > Someone like PayPal can, because of the stakes involved, stipulate that users > (a) provide an end-address and (b) not forward it. I don't imagine that > you're in a position to do so. ARC goes some way to helping receivers make > better decisions, but that doesn't give you much to work with. > > > Is there email sent legitimately with an @akamai.com email address that isn't > from an Akamai employee or automated system? If so, are the stakes high > enough that you're in a position to direct employees to avoid using their > work email addresses for mailing lists? (This won't solve the problem, but > may significantly reduce it.) Are you able to quantify the damage being done > at present? (If not, stop work on this now!) > > > - Roland > > From: Payne, John > Sent: Friday, 28 October 2016 04:45 > To: Roland Turner > Cc: DMARC Discussion List > Subject: Re: [dmarc-discuss] A bit quiet? > > > > On Oct 26, 2016, at 8:56 PM, Roland Turner via dmarc-discuss > > wrote: > > > > Payne, John wrote: > > > > > Yeah, but why are they showing up in _my_ DMARC reports? > > ... > > > Domain MAIL FROM DKIM domain SPF AuthDKIM Auth > > > Total > > > akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass Pass > > > 237 > > > > oppa.com.br has a syntactically invalid SPF record, so it's odd that it's > > passing at all. You didn't show which IP address the reporter saw this > > stream coming from: were they forwarded in your environment with their DKIM > > signatures intact? > > That was just a random example. The IPs are all Google. These are not > forwarded within my environment. > > > First couple from literally thousands of Google IPs: > IP PTR NameSBRSCountry DMARC Fail %DMARC Fail Total > 2607:f8b0:4003:c06::247 mail-oi0-x247.google.com (IPv6) 99.96% 2,847 > 2,848 > 2607:f8b0:4003:c06::245 mail-oi0-x245.google.com (IPv6) 99.96% 2,792 > 2,793 > 2607:f8b0:4003:c06::246 mail-oi0-x246.google.com (IPv6) 100.00% 2,769 > 2,769 > 2607:f8b0:4003:c06::248
Re: [dmarc-discuss] A bit quiet?
Someone asked a followup question here, and something else occurred to me. If you go to p=quarantine and pct=0, Google Groups will still do the rewriting, but no one should enforce the quarantine. I know this is true for our own code, but I don't know how well others handle it to know if it's a safe thing to do or not. Brandon On Fri, Oct 28, 2016 at 4:30 PM, Brandon Longwrote: > This sounds likely to be messages from your domain that were forwarded by > Google apps, most likely mailing lists. > > If the message was authenticated inbound to the mailing list, it will be > signed outbound by the domain hosting the list. > > If you were p=reject or quarantine, we would rewrite the from. It's > unfortunate that we don't rewrite while you are p=none, I'm unsure whether > we should change that or wait for arc. > > As everyone knows, rewriting isn't a great experience, which is why we > haven't done it for p=none, but if it makes the reporting too annoying to > go to p=reject, we should rethink. > > Also, if you're using a third party to analyse your rua reports, perhaps > they should do more to help for this case. > > Would it help if we reported these as a passed by local policy, since they > would by xoar? > > Brandon > > On Oct 27, 2016 8:19 PM, "Roland Turner via dmarc-discuss" < > dmarc-discuss@dmarc.org> wrote: > >> John, >> >> >> My apologies, I appear to have misinterpreted this completely, not sure >> what I was thinking: >> >>- DMARC reports are sent to the address specified in the DMARC record >>associated with the 5322.From address, not the source IP addresses. >>- Therefore, these reports are sent to you because the 5322.From >>header contains an akamai.com address. >>- The examples that you're citing showing a 5321.MailFrom address >>(with SPF pass) and DKIM d= domain (with DKIM pass) that are aligned with >>each other. This suggests either (a) a message sent legitimately by >>yourselves and legitimately forwarded or (b) an impersonation, also >> legitimately >>forwarded. It is to be hoped that Google's DMARC reports >>preferentially report on DMARC-aligned DKIM passes if they're present, >>suggesting that the messages in question are passing through DKIM-breaking >>forwarding (case (a)) or lack DKIM signatures (hopefully case (b)). >> >> I'm guessing that you'd already worked this out. >> >> >> The forwarding cases are the awkward corner case for DMARC. As a domain >> owner/registrant there's probably not much that you can do about this. >> Someone like PayPal can, because of the stakes involved, stipulate that >> users (a) provide an end-address and (b) not forward it. I don't imagine >> that you're in a position to do so. ARC goes some way to helping receivers >> make better decisions, but that doesn't give you much to work with. >> >> >> Is there email sent legitimately with an @akamai.com email address that >> isn't from an Akamai employee or automated system? If so, are the stakes >> high enough that you're in a position to direct employees to avoid using >> their work email addresses for mailing lists? (This won't solve the >> problem, but may significantly reduce it.) Are you able to quantify the >> damage being done at present? (If not, stop work on this now!) >> >> >> - Roland >> >> -- >> *From:* Payne, John >> *Sent:* Friday, 28 October 2016 04:45 >> *To:* Roland Turner >> *Cc:* DMARC Discussion List >> *Subject:* Re: [dmarc-discuss] A bit quiet? >> >> >> > On Oct 26, 2016, at 8:56 PM, Roland Turner via dmarc-discuss < >> dmarc-discuss@dmarc.org> wrote: >> > >> > Payne, John wrote: >> > >> > > Yeah, but why are they showing up in _my_ DMARC reports? >> > ... >> > > Domain MAIL FROM DKIM domain SPF AuthDKIM >> Auth Total >> > > akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass >> Pass237 >> > >> > oppa.com.br has a syntactically invalid SPF record, so it's odd that >> it's passing at all. You didn't show which IP address the reporter saw this >> stream coming from: were they forwarded in your environment with their DKIM >> signatures intact? >> >> That was just a random example. The IPs are all Google. These are not >> forwarded within my environment. >> >> >> First couple from literally thousands of Google IPs: >> IP PTR NameSBRSCountry DMARC Fail %DMARC Fail >> Total >> 2607:f8b0:4003:c06::247 mail-oi0-x247.google.com (IPv6) 99.96% >> 2,847 2,848 >> 2607:f8b0:4003:c06::245 mail-oi0-x245.google.com (IPv6) 99.96% >> 2,792 2,793 >> 2607:f8b0:4003:c06::246 mail-oi0-x246.google.com (IPv6) 100.00% >> 2,769 2,769 >> 2607:f8b0:4003:c06::248 mail-oi0-x248.google.com (IPv6) 99.96% >> 2,673 2,674 >> >> >> Drilling into that first one and again, just taking the first couple >> because it’s just more of the same with many different domains: >> >> Domain MAIL FROM