> On Jan 17, 2017, at 4:56 PM, Brandon Long via dmarc-discuss > <dmarc-discuss@dmarc.org> 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 <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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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)
