Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>  wrote:
> 
> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
> wrote:
>> The fun is moving to ARC
>> 
>> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
> 
> Sad to see that Gmail plan to move to p=reject

I’m hoping that it encourages the mailing list folk who have been reluctant to 
become DMARC safe to reconsider, whether thats ARC or wrapping.
As an enterprise hoping to go p=reject, this is potentially a big deal for me :)

> 
> It will be interesting to see what the scammers come up with when that
> happens.
> 
> Let's hope ARC delivers.
> 
> Andy
> 
> ___
> 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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> On Oct 22, 2015, at 3:43 PM, Payne, John  wrote:
> 
> 
>> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>>  wrote:
>> 
>> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
>> wrote:
>>> The fun is moving to ARC
>>> 
>>> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>> 
>> Sad to see that Gmail plan to move to p=reject
> 
> I’m hoping that it encourages the mailing list folk who have been reluctant 
> to become DMARC safe to reconsider, whether thats ARC or wrapping.
> As an enterprise hoping to go p=reject, this is potentially a big deal for me 
> :)


I’m not exactly in the loop, but besides this article almost a year ago, I 
haven’t seen anything else about gmail going p=reject… and it’s now 3 months 
past the advertised date.
Any word there?

Somewhat related (to my earlier post) - are there any _enterprises_ on this 
list that have experience or are currently attempting to either go p=reject or 
enforce DMARC policies inbound?

Thanks
John



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

Awesome!  I’m almost there but it’s been a long slog.


- Are you using any DMARC analysis providers, or home grown?
- Are you using *aaS providers that “legitimately” spoof you?  If so - how was 
your experience in getting them compliant?
- Are you seeing unexpected reports from Google?  (They seem to be reporting 
their own IPs as sending mail)
- Does your staff participate on mailing lists?  If so - how do you handle that 
for inbound DMARC filtering?  Whitelist?



My answers:

- Agari - and I’ve been very happy with their support
- Yes - and the hardest part has been finding someone who understands what DKIM 
means - once that happens things typically move quickly
- Yes - it’s killing my numbers :(
- TBD :/

Thanks
John



> On Sep 20, 2016, at 2:44 AM, Povl Hessellund Pedersen via dmarc-discuss 
>  wrote:
> 
> I work in a larger enterprise, largest retailer in Denmark with branches in 
> multiple countries.
> We have been using SPF for years now with -all 
> We started on DKIM / DMARC earlier this year for outbound, we are on O365.
> We had some issues that are resolved. 
> We have moved all mass mailing / external partners to subdomains and use a 
> reply-to where needed.
> We are doing inbound DMARC on our own addresses to stop most obvious CEO scam.
> 
> We use O365, so we are using this header to run check against (sender domain 
> p=quarantine). So I can't really see the dmarc policy set by the sender, and 
> filter based on that. It is not available in any header.
> 
> Authentication-Results: spf=pass (sender IP is 209.85.214.50)
> smtp.mailfrom=my.test.dk; dsg.dk; dkim=pass (signature was verified)
> header.d=my.test.dk;dsg.dk; dmarc=pass action=none
> header.from=my.test.dk;dsg.dk; dkim=pass (signature was verified)
> header.d=my.test.dk;
> 
>> On Oct 22, 2015, at 3:43 PM, Payne, John  wrote:
>> 
>> 
>>> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>>>  wrote:
>>> 
>>> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
>>> wrote:
 The fun is moving to ARC
 
 https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>>> 
>>> Sad to see that Gmail plan to move to p=reject
>> 
>> I’m hoping that it encourages the mailing list folk who have been reluctant 
>> to become DMARC safe to reconsider, whether thats ARC or wrapping.
>> As an enterprise hoping to go p=reject, this is potentially a big deal for 
>> me :)
> 
> 
> I’m not exactly in the loop, but besides this article almost a year ago, I 
> haven’t seen anything else about gmail going p=reject… and it’s now 3 months 
> past the advertised date.
> Any word there?
> 
> Somewhat related (to my earlier post) - are there any _enterprises_ on this 
> list that have experience or are currently attempting to either go p=reject 
> or enforce DMARC policies inbound?
> 
> Thanks
> John
> 
> 
> ___
> 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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

On Sep 22, 2016, at 10:34 PM, Franck Martin 
mailto:fmar...@linkedin.com>> wrote:

https://engineering.linkedin.com/email/dmarc-new-tool-detect-genuine-emails<https://urldefense.proofpoint.com/v2/url?u=https-3A__engineering.linkedin.com_email_dmarc-2Dnew-2Dtool-2Ddetect-2Dgenuine-2Demails&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=Vk1IAqiPW_HhrMpaN7jpo7ofj3cE-yod0vWmR1RVSlY&e=>
https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode<https://urldefense.proofpoint.com/v2/url?u=https-3A__engineering.linkedin.com_email_dmarc-2Dmoving-2Dmonitor-2Dreject-2Dmode&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=hxBXMPfwpVPp9OjNX5g_MGRP3WAYgVlfJZZ57lQuKOM&e=>

google.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__google.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=EZCpx1XS6E0RlPrXwJwQ-rjXlv1eIef8v1YTrtbjHZ8&e=>
 is p=quarantine
yahoo-inc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__yahoo-2Dinc.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=-hb-p4StcL11rm8kVxjALkpozYMuHSpBT2kM6HfV_E0&e=>
 is p=reject
microsoft.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__microsoft.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=lSvflBjO4CTTS40XQzyG-i55yHF4hxO7Oa73V5xHN6k&e=>
 is p=quarantine
paypal-inc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__paypal-2Dinc.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=HVYtBaLvaLL64MGFFzjMs5nsCuxKUD8AaAQRZzkgwJs&e=>
 is p=reject

You will find other resources at dmarc.org<http://dmarc.org>

google.com<http://google.com> is p=reject FWIW

I’m interested in how these companies got to that point.  What workarounds are 
they relying on if any?
Are they enforcing DMARC policies inbound?


As for the Gmail question, I think it is linked to the release of ARC.

So I’ve heard.  I hope that turns out to be useful for the rest of us :)


On Mon, Sep 19, 2016 at 12:06 PM, Payne, John via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:

> On Oct 22, 2015, at 3:43 PM, Payne, John 
> mailto:jpa...@akamai.com>> wrote:
>
>
>> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>> mailto:dmarc-discuss@dmarc.org>> wrote:
>>
>> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
>> wrote:
>>> The fun is moving to ARC
>>>
>>> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/<https://urldefense.proofpoint.com/v2/url?u=https-3A__dmarc.org_2015_10_global-2Dmailbox-2Dproviders-2Ddeploying-2Ddmarc-2Dto-2Dprotect-2Dusers_&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=RY-gGeFkzI6d-8J-08vlsFsISSguMO0jJBoGASk9_UE&e=>
>>
>> Sad to see that Gmail plan to move to p=reject
>
> I’m hoping that it encourages the mailing list folk who have been reluctant 
> to become DMARC safe to reconsider, whether thats ARC or wrapping.
> As an enterprise hoping to go p=reject, this is potentially a big deal for me 
> :)


I’m not exactly in the loop, but besides this article almost a year ago, I 
haven’t seen anything else about gmail going p=reject… and it’s now 3 months 
past the advertised date.
Any word there?

Somewhat related (to my earlier post) - are there any _enterprises_ on this 
list that have experience or are currently attempting to either go p=reject or 
enforce DMARC policies inbound?

Thanks
John


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
http://www.dmarc.org/mailman/listinfo/dmarc-discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dmarc.org_mailman_listinfo_dmarc-2Ddiscuss&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=eMppF7rXKy9Ae992X-v1YNrKhFN1KplgK27cUZrxuTo&e=>

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dmarc.org_note-5Fwell.html&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=TgyMWJzUPFzT0ty-VIZaQeIReOkrro70rp5gZkRzHjg&e=>)


___
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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> On Sep 26, 2016, at 4:34 PM, Franck Martin  wrote:
> 
> We do enforce inbound policy, in fact this has been very useful, when you 
> send to yourself a copy of the failure reports, It allows you to find 
> problems with your email streams before they become real problems (as well as 
> all the details helping you to fix them).

Yep, I’ve been collecting inbound reports via Agari’s reflect product, as our 
MX provider doesn’t (yet???) send reports.  For the last couple of weeks I’ve 
been at 95-98.5% DMARC compliant for my own email coming in from the outside, 
as I’ve been working with all of our legit 3rd parties.



> 
> cf: https://github.com/linkedin/lafayette/wiki/Screenshots
> 
> I had to put one or two companies in a local policy exception, but they were 
> emailing only our employees, not the whole world.
> 
> Many third parties can abide to your DMARC policy, but you need to spell it 
> out what you want them to do, as many do not understand what DMARC is.

Yes.  I’ve been ramming DKIM down the throat of my vendors, as I have scaling 
concerns with SPF (plus alignment is a huge issue).


However… we have staff on non-DMARC-“fixing” mailing lists, like IETF, OpenSSL, 
etc.  

How are companies dealing with that while waiting for ARC?   Are you 
whitelisting the “well known” mailing list servers?  My original thought was to 
put mailing list users onto a non-DMARC protected domain, but I see users from 
Microsoft, Google, LinkedIn on those same lists, so either they’re not 
enforcing inbound (but LinkedIn and Microsoft are), or you’re whitelisting - 
right?

If so, is there a place to share those IPs, or is everyone on their own to 
figure out what IPs for even the most common lists are?


Thanks
John


> 
> I have used that FAQ entry a lot with all 3rd parties: 
> https://dmarc.org/wiki/FAQ#My_organization_uses_third-parties_senders.2C_how_can_I_get_them_DMARC_compliant.3F
> 
> On Mon, Sep 26, 2016 at 9:03 AM, Payne, John  wrote:
> 
>> On Sep 22, 2016, at 10:34 PM, Franck Martin  wrote:
>> 
>> https://engineering.linkedin.com/email/dmarc-new-tool-detect-genuine-emails
>> https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode
>> 
>> google.com is p=quarantine
>> yahoo-inc.com is p=reject
>> microsoft.com is p=quarantine
>> paypal-inc.com is p=reject
>> 
>> You will find other resources at dmarc.org
> 
> google.com is p=reject FWIW
> 
> I’m interested in how these companies got to that point.  What workarounds 
> are they relying on if any? 
> Are they enforcing DMARC policies inbound?
> 
> 
>> As for the Gmail question, I think it is linked to the release of ARC.
> 
> So I’ve heard.  I hope that turns out to be useful for the rest of us :)
> 
>> 
>> On Mon, Sep 19, 2016 at 12:06 PM, Payne, John via dmarc-discuss 
>>  wrote:
>> 
>> > On Oct 22, 2015, at 3:43 PM, Payne, John  wrote:
>> >
>> >
>> >> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>> >>  wrote:
>> >>
>> >> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
>> >> wrote:
>> >>> The fun is moving to ARC
>> >>>
>> >>> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>> >>
>> >> Sad to see that Gmail plan to move to p=reject
>> >
>> > I’m hoping that it encourages the mailing list folk who have been 
>> > reluctant to become DMARC safe to reconsider, whether thats ARC or 
>> > wrapping.
>> > As an enterprise hoping to go p=reject, this is potentially a big deal for 
>> > me :)
>> 
>> 
>> I’m not exactly in the loop, but besides this article almost a year ago, I 
>> haven’t seen anything else about gmail going p=reject… and it’s now 3 months 
>> past the advertised date.
>> Any word there?
>> 
>> Somewhat related (to my earlier post) - are there any _enterprises_ on this 
>> list that have experience or are currently attempting to either go p=reject 
>> or enforce DMARC policies inbound?
>> 
>> Thanks
>> John
>> 
>> 
>> ___
>> 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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> On Sep 27, 2016, at 12:23 PM, Terry Zink via dmarc-discuss 
>  wrote:
> 
>> Somewhat related (to my earlier post) - are there any _enterprises_ on this 
>> list that have
>> experience or are currently attempting to either go p=reject or enforce 
>> DMARC policies inbound?
> 
> I just wrote one for Microsoft: 
> https://blogs.msdn.microsoft.com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-pquarantine-dmarc-record/

This is the blog post I wanted to write :)  I’m just behind on getting to 
p=quarantine.

There are 2 things slowing me down:

1. As I just replied to Franck - enforcing inbound (which is my primary goal) - 
I need to handle mailing lists (and I don’t want to wait for ARC adoption).   
So I have to figure out all the mailing lists my users are posting to so I can 
whitelist those IPs coming back unless anyone wants to share a list? :)

2. Google seems to report itself as a DMARC failing sender for unrelated 
domains to me.  This really started in earnest in March, but I’m getting 
40k-60k what seem like unrelated reports a day, for example:


Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth   Total
akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass  Pass237

So that’s killing my confidence on publishing p=quarantine (I can fake one 
inbound).  Are others seeing this, or am I a special snowflake?



Thanks
John

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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

On Oct 26, 2016, at 11:36 AM, Franck Martin 
mailto:fmar...@linkedin.com>> wrote:

Couple of points...

1) 
https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L804<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_linkedin_dmarc-2Dmsys_blob_master_dmarc.lua-23L804&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0&s=hDD4-nPPyBu_1mywET_mBGcElRBl6KNh6Zl5oYeShVM&e=>
This is how we detect if the email is likely to be from a mailing list. I parse 
the logs from time to time, and put exceptions in our local policy.

Awesome. I don't have a good place in our mail flow to put something like this, 
but it certainly seems like a feature request to my partners :)



2) very few lists discard DMARC protected emails on reception. So as long you 
don't post too often, you are not triggering the unsubscribe due to bounce 
function in mailman...

It's not the list discarding DMARC, I accidentally enabled enforcement inbound, 
and bounced a bunch of mail from a Google employee through an IETF mailing 
list. It's whether the ultimate recipients reject the mail as to whether or not 
we'll get unsubscribed.


3) we tell our employees to use personnal email addresses for mailing lists... 
It makes sure they are not speaking on our behalf ;)

For non-work related lists, this is fine and the way we'll likely go. For 
things that are directly work related this isn't a reasonable option for us.



4) GApps DKIM signs all the emails with 
.gappssmtp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__gappssmtp.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0&s=_XoQC4NVb7n1WYwgSSXzArix4Yggz3vYMPInHGFa7R0&e=>
 until said customer DKIM signs with its own domain (because they want all 
emails to be authenticated).

Yeah, but why are they showing up in _my_ DMARC reports?




On Tue, Oct 25, 2016 at 1:14 PM, Payne, John via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:

> On Sep 27, 2016, at 12:23 PM, Terry Zink via dmarc-discuss 
> mailto:dmarc-discuss@dmarc.org>> wrote:
>
>> Somewhat related (to my earlier post) - are there any _enterprises_ on this 
>> list that have
>> experience or are currently attempting to either go p=reject or enforce 
>> DMARC policies inbound?
>
> I just wrote one for Microsoft: 
> https://blogs.msdn.microsoft.com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-pquarantine-dmarc-record/<https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.msdn.microsoft.com_tzink_2016_09_27_how-2Dwe-2Dmoved-2Dmicrosoft-2Dcom-2Dto-2Da-2Dpquarantine-2Ddmarc-2Drecord_&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0&s=MqBeSM06lR4ty4r8zNucKDlk3jvkh0Qah-SW1wTjMZM&e=>

This is the blog post I wanted to write :)  I'm just behind on getting to 
p=quarantine.

There are 2 things slowing me down:

1. As I just replied to Franck - enforcing inbound (which is my primary goal) - 
I need to handle mailing lists (and I don't want to wait for ARC adoption).   
So I have to figure out all the mailing lists my users are posting to so I can 
whitelist those IPs coming back unless anyone wants to share a list? :)

2. Google seems to report itself as a DMARC failing sender for unrelated 
domains to me.  This really started in earnest in March, but I'm getting 
40k-60k what seem like unrelated reports a day, for example:


Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth   Total
akamai.com<http://akamai.com> 
oppa.com.br<https://urldefense.proofpoint.com/v2/url?u=http-3A__oppa.com.br&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0&s=rtlqCpIg6ZivlkZLSgiF1miH_AHJoPh4RFuE_99I4oo&e=>
 
oppa-com-br.20150623.gappssmtp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__oppa-2Dcom-2Dbr.20150623.gappssmtp.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0&s=2WRrk-QbD3c6SGDsxBoU0dJ8hH4NobkdIQA5HLv8lqc&e=>
 Pass  Pass237

So that's killing my confidence on publishing p=quarantine (I can fake one 
inbound).  Are others seeing this, or am I a special snowflake?



Thanks
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
http://www.dmarc.org/mailman/listinfo/dmarc-discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dmarc.org_mailman_listinfo_dmarc-2Ddiscuss&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOuf

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

> 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  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   DKIM domain SPF AuthDKIM Auth   Total
akamai.com  kohls.com   kohls-com.20150623.gappssmtp.comPass
Pass369
akamai.com  stickyads.tvstickyads.tvPassPass256
akamai.com  jforce.com.tw   jforce-com-tw.20150623.gappssmtp.comPass
Pass238
akamai.com  ziffdavis.com   ziffdavis-com.20150623.gappssmtp.comPass
Pass205



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.

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)

Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation

[Payne, John via dmarc-discuss]

> On Nov 14, 2016, at 9:49 AM, Petr Novák via dmarc-discuss 
>  wrote:
> 
> Hello,
> 
> I saw that FortiNet's FortiMail is listed as a product that has a DMARC 
> support here: "https://dmarc.org/resources/products-and-services/"; .
> 
> I wonder what do you guys think about it's DMARC implementation. If you 
> enable DMARC check in FortiMail it rejects(or performs other configured 
> action) any mail that fails DMARC check no matter what policy source domain 
> has configured. So it also rejects mails from domains that have policy 
> p=none. After contacting their support I was told that this implementation is 
> by desing and they dont have any plans to change it.
> 
> In DMARC RFC there is:
> "To enable Domain Owners to receive DMARC feedback without impacting existing 
> mail processing, discovered policies of "p=none" SHOULD NOT modify existing 
> mail disposition processing."
> 
> So I guess it doesn't break RFC if there is "SHOULD NOT" and not "MUST NOT"? 
> But I still think this implementation of DMARC is wrong. What do you guys 
> think?


Speaking only as an enterprise trying to use DMARC, FortiMail’s implementation 
as described above is wrong and serves only to discourage others from 
implementing a DMARC policy.  p=none is vital.

That said, I would have no objection to fortimail customers having the option 
to treat p=none as p=quarantine or p=reject -> that’s completely up to them.  
But by default no thank you!

___
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)

Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation

[Payne, John via dmarc-discuss]

> On Nov 14, 2016, at 2:42 PM, Terry Zink via dmarc-discuss 
>  wrote:
> 
>> Well, DMARC addresses one particular vector - we still need to find more 
>> effective ways 
>> to address cousin domains, display name abuse, etc.
> 
> I didn't mean cousin domains, I mean domains that are not the same but have a 
> relationship (e.g., one is a vendor of the other). They both have weak 
> authentication records (no DMARC, or DMARC + p=none), and then one of them 
> gets spoofed.
> 
> So yes, the fix is to publish a stronger DMARC policy, but lots of domains 
> who publish DMARC have a weak policy. It's hard to get to p=reject/quarantine 
> if you are not a big company and are doing it yourself.

But (by default) overriding a p=none to something stronger is punishing those 
who at least have heard of DMARC in favor of not publishing a record at all, 
and thus not gathering enough data to be able to get to reject or quarantine.  
It can take a long time to get beyond p=none depending on internal priorities, 
politics, size of problem to begin with… if I had thought there was any 
reasonable expectation of having my p=none get overridden by default 
(especially as they don’t seem to be sending any reports?) I wouldn’t have been 
able to start on this path at all.



> 
> 
> -Original Message-
> From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of 
> Steven M Jones via dmarc-discuss
> Sent: Monday, November 14, 2016 11:24 AM
> To: dmarc-discuss@dmarc.org
> Subject: Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation
> 
> On 11/14/2016 10:33, Terry Zink via dmarc-discuss wrote:
>> In my experience, domains sit on p=none for a long time, and in the meantime 
>> a lot of other senders send email as them - most legitimate but some 
>> malicious. This setting is designed to catch the malicious.
> 
> Maybe I need to make that a more central focus in 2017...
> 
> 
>> So, either (a) you rely upon DMARC proper but have to add additional layers 
>> to catch the rest of the phish, or (b) you go hyper-aggressive and then add 
>> layers (overrides) to allow the legitimate email.
>> 
>> Both options are not great, although having to set up override after 
>> override after override is management pain as it is prone to false positives.
> 
> If the option were there to make those overrides I'd be more supportive, but 
> it didn't sound like that was the case with this particular product/service. 
> If somebody with access could clarify, I'd appreciate it.
> 
> 
>> I used to say that I would probably treat your own domain(s) as 
>> p=quarantine/reject but respect the setting for domains you don't own. But 
>> in the past month or two, I've seen plenty of "other-domain" spoofing, that 
>> is, spammers/phishers spoofing domains with weak authentication policies and 
>> getting in that way.
> 
> Well, DMARC addresses one particular vector - we still need to find more 
> effective ways to address cousin domains, display name abuse, etc. Some 
> products/services have moved in that direction, and there are some efforts 
> trying to determine if there's an approach amenable to being standardized.
> 
> --S.
> 
> 
> ___
> 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)

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 mail-oi0-x248.google.com (IPv6) 99.96%  2,673 
>   2,674
> 
> 
> Drilling into that first one and again, 

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

On Jan 19, 2017, at 12:26 AM, Roland Turner via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:

John Payne wrote:

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

It is a reasonably safe bet that pct=0 will prevent quarantining. (Any receiver 
observed doing otherwise will no doubt be promptly encouraged to stop doing 
so.) Whether other forwarders will rewrite in this case is an open question.

Well… we’ll find out.  I did this earlier today :)

___
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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

On Jan 19, 2017, at 12:26 AM, Roland Turner via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:


Brandon Long wrote:


> 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 is excellent and revolting at the same time! Thank you.

And it did the trick.  Down to a manageable number of failures now, thanks for 
the hint Brandon :)


Thanks
John
___
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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

Spoke too soon. I'm getting reports of IETF list mail from @akamai.com ending 
up in Gmail spam folders :(

> On Jan 31, 2017, at 9:07 AM, Payne, John via dmarc-discuss 
>  wrote:
> 
> And it did the trick.  Down to a manageable number of failures now, thanks 
> for the hint Brandon :)

___
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)

Re: [dmarc-discuss] A bit quiet?

[Payne, John via dmarc-discuss]

replied offlist


On Feb 3, 2017, at 8:09 PM, Brandon Long via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:

Actually, do you have any more specifics for me to take a look?  Best case 
would be the recipient and message-id of something that ended up in the spam 
label.

Off list would be fine.

Brandon

On Fri, Feb 3, 2017 at 5:05 PM, Brandon Long 
mailto:bl...@google.com>> wrote:
I'll take a look.

On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner 
mailto:roland.tur...@trustsphere.com>> wrote:
John Payne wrote:

>> Presumably this just indicates that the rewrite rule that Brandon described 
>> for Google Groups
>> is not in use by IETF's mailing lists?
>>
>> Tradeoffs in every direction...
>
> I wasn't expecting behavior changes for ietf mail.
>
> To clarify, with p=none I had no complaints. With p=quarantine, pct=0 I have 
> complaints from gmail users.
>
> I believe this points to gmail perhaps not looking at the pct...

Apologies, wrote before thinking it through. What should have happened is that 
the failures identified in aggregate reports should have gone down as Google 
Groups would rewrite because of it, but that no changes in receiver behaviour 
should occur.

I agree, this looks like a Gmail bug.

Brandon, are you able to explore this with your colleagues?

- Roland


___
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)

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

[Payne, John via dmarc-discuss]

> On Oct 9, 2018, at 10:59 AM, Jonathan Kamens via dmarc-discuss 
>  wrote:
> 
> As I'm sure the folks on this list are aware, apparently some ESPs and 
> software maintainers have chosen to behave differently when forwarding emails 
> (most notably to mailing lists) depending on whether the sender's domain 
> DMARC policy is nonexistent or p=none, vs. p=quarantine or p=reject.
> 
> In particular, the ones that I know about are Google Groups and GNU Mailman, 
> both of which have decided to rewrite From: lines when they see p=quarantine 
> or p=reject but leave them intact when they see no DMARC policy or a policy 
> with p=none.
> 
> I find this bewildering and frustrating both for domains attempting to roll 
> out DMARC and for the administrators of mail servers attempting to enforce it 
> on incoming emails.
> 
> From the outbound email point of view, what good does it do to get aggregate 
> reports telling you messages forwarded through mailing lists weren't DMARC 
> compliant when you can't do anything about it and when messages sent through 
> those same mailing lists will magically become compliant when you switch from 
> p=none to p=quarantine? This is especially true since you can't actually know 
> that those messages are going to magically become compliant, because you 
> can't know which mailing list platforms play this game.
> 
> From the inbound email point of view, having just deployed the current beta 
> release of OpenDMARC on my personal (not Quantopian's) mail server 
> (Incidentally, an aside: is anybody actually maintaining OpenDMARC? There are 
> multiple significant bugs in it that have been reported with patches on 
> Github and the maintainers there have been radio silent for months), I am 
> carefully monitoring the logs, both to confirm that it is behaving properly 
> and so that I can detect and report any problems to the OpenDMARC maintainers 
> (I've already submitted several bug reports and patches). Several times a 
> week I get a "domain fail" log message from OpenDMARC and I have to 
> investigate it, only to discover that the only reason for the failure is 
> because someone on my server received a message through a mailing list and 
> the sender domain's DMARC policy is p=none.
> 
> I see people behaving badly here in both directions. In my opinion, servers 
> that do message forwarding should rewrite headers for DMARC compliance 
> whenever there is a DMARC policy, not just when the policy is p=quarantine or 
> p=reject. And on the other end, given that the servers that do forwarding 
> aren't behaving that way, nobody should be using p=none in their policy; they 
> should instead use p=quarantine; pct=0 to force their headers to be rewritten 
> during forwarding.
> 
> Am I missing something here?

Thats exactly the situation I’m in.I believe that p= should 
trigger “special handling” if there is any to be triggered.  p=none is 
semantically different from the record not existing, but it’s being treated the 
same.

Of course, p=quarantine; pct=0 does run the risk of receivers not obeying the 
pct… which I think there’s at least 1 out there….

___
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)

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

[Payne, John via dmarc-discuss]

> On Oct 9, 2018, at 3:17 PM, Mark Fletcher via dmarc-discuss 
>  wrote:
> 
> On Tue, Oct 9, 2018 at 8:06 AM Jonathan Kamens via dmarc-discuss 
>  wrote:
> I see people behaving badly here in both directions. In my opinion, servers 
> that do message forwarding should rewrite headers for DMARC compliance 
> whenever there is a DMARC policy, not just when the policy is p=quarantine or 
> p=reject. And on the other end, given that the servers that do forwarding 
> aren't behaving that way, nobody should be using p=none in their policy; they 
> should instead use p=quarantine; pct=0 to force their headers to be rewritten 
> during forwarding.
> 
> We only re-write From lines for quarantine or reject, not none. We want to 
> re-write as few From lines as possible; the user experience is degraded when 
> we have to re-write From lines.

p=none -> “we’re trying to figure out if we’re going to be able to go to 
p=quarantine”

If you treat quarantine differently than none, you’re sending me misleading 
data in the reports you send (if of course you send reports) - or your 
downstream recipients send.


___
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)