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 Long <bl...@google.com> 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" < > 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)
