Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> 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?

[Brandon Long via dmarc-discuss]

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  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 
>> *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