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)

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] 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 
> <dmarc-discuss@dmarc.org> 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]

On Jan 19, 2017, at 12:26 AM, Roland Turner via dmarc-discuss 
> 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]

> 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] 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] 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] A bit quiet?

[Payne, John via dmarc-discuss]

On Oct 26, 2016, at 11:36 AM, Franck Martin 
<fmar...@linkedin.com<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=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=hDD4-nPPyBu_1mywET_mBGcElRBl6KNh6Zl5oYeShVM=>
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=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=_XoQC4NVb7n1WYwgSSXzArix4Yggz3vYMPInHGFa7R0=>
 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 
<dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>> wrote:

> On Sep 27, 2016, at 12:23 PM, Terry Zink via dmarc-discuss 
> <dmarc-discuss@dmarc.org<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_=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=MqBeSM06lR4ty4r8zNucKDlk3jvkh0Qah-SW1wTjMZM=>

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=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=rtlqCpIg6ZivlkZLSgiF1miH_AHJoPh4RFuE_99I4oo=>
 
oppa-com-br.20150623.gappssmtp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__oppa-2Dcom-2Dbr.20150623.gappssmtp.com=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=2WRrk-QbD3c6SGDsxBoU0dJ8hH4NobkdIQA5HLv8lqc=>
 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=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI=muN8iCc9IrsFz5Xpe1BKqQYoYLfDoE09qlNlu578rB0=r8XbSCPWM75VrQ3AsZUbuvH8leM1jFKDwccNhdV81ss=>

NOTE: Participating in this list mean

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 Sep 26, 2016, at 4:34 PM, Franck Martin <fmar...@linkedin.com> 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 <jpa...@akamai.com> wrote:
> 
>> On Sep 22, 2016, at 10:34 PM, Franck Martin <fmar...@linkedin.com> 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 
>> <dmarc-discuss@dmarc.org> wrote:
>> 
>> > On Oct 22, 2015, at 3:43 PM, Payne, John <jpa...@akamai.com> wrote:
>> >
>> >
>> >> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss 
>> >> <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/
>> >>
>> >> 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 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)