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 <jpa...@akamai.com> > *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 Auth DKIM > 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 Name SBRS Country 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 DKIM domain SPF Auth DKIM Auth > Total > akamai.com kohls.com kohls-com.20150623.gappssmtp.com > Pass Pass 369 > akamai.com stickyads.tv stickyads.tv Pass Pass 256 > akamai.com jforce.com.tw jforce-com-tw.20150623.gappssmtp.com > Pass Pass 238 > akamai.com ziffdavis.com ziffdavis-com.20150623.gappssmtp.com > Pass Pass 205 > > > > There are no RUFs generated, only RUAs. > > As an example of why this is a problem for me… Yesterday out of 53,078 > DMARC failures, 49,101 were from Google IP space. I can’t even find the > 4,000 other failures amongst all the Google ones to see if they’re things I > need to worry about or not! > > I’d love to understand either why I’m so special in this regard, or if I’m > not how others are dealing with this. We do use Google Apps (just not > mail), and a lot of our customers are Google mail customers, so I really > don’t want to ask Agari to filter out reports from Google - but I’m at my > wits end with this. > > _______________________________________________ > 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) >
_______________________________________________ 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)
