[dmarc-discuss] A bit quiet?

[Mark Rousell via dmarc-discuss]

Is it just me or was the last post on here really on 5th October?

-- 
Mark Rousell
 
 
 


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

[Franck Martin via dmarc-discuss]

The fun is moving to ARC

https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/

On Thu, Oct 22, 2015 at 8:51 AM, Mark Rousell via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Is it just me or was the last post on here really on 5th October?
>
> --
> Mark Rousell
>
>
>
>
>
> ___
> 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?

[Andrew Beverley via dmarc-discuss]

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

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)

Re: [dmarc-discuss] A bit quiet?

[Franck Martin via dmarc-discuss]

On Thu, Oct 22, 2015 at 12:36 PM, Andrew Beverley 
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
>
> It will be interesting to see what the scammers come up with when that
> happens.
>
> Let's hope ARC delivers.
>
> Hopefully you can help achieve this goal with the resources at your
disposition.
___
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: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?

[Rolf E. Sonneveld via dmarc-discuss]

On 22-10-15 21:36, 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


+1



It will be interesting to see what the scammers come up with when that
happens.

Let's hope ARC delivers.


on time...

/rolf
___
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?

[Terry Zink via dmarc-discuss]

> Sad to see that Gmail plan to move to p=reject

Why do you say this? Because it will disrupt mailing lists (as in, yahoo.com 
refugees moved to gmail.com and now that will no longer available)?

If ARC solves the problem of mailing lists, then it means anyone with a domain 
with p=reject can join a mailing list (which is great, no hacky workarounds 
needed) and helps drive email authentication forward.

-- Terry

-Original Message-
From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of 
Andrew Beverley via dmarc-discuss
Sent: Thursday, October 22, 2015 12:36 PM
To: Franck Martin; Mark Rousell
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] A bit quiet?

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

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?

[Scott Kitterman via dmarc-discuss]

On October 22, 2015 1:19:51 PM EDT, 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/
>

How does that actually help? At least as I read the draft, anyone can make up a 
'bad' message and an associated made up DKIM signature and then add their ARC 
stamp claiming the signature was valid when the message arrived?

Scott K

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

[Franck Martin via dmarc-discuss]

On Thu, Oct 22, 2015 at 1:16 PM, Terry Zink via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> > Sad to see that Gmail plan to move to p=reject
>
> Why do you say this? Because it will disrupt mailing lists (as in,
> yahoo.com refugees moved to gmail.com and now that will no longer
> available)?
>
> And it is unlikely recommending users to move to another provider will be
a long term solution. The solution is implementing DMARC, and the community
needs help to tackle all mail software and appliances.

For the forwarders that modify emails, ARC provides a filter (milter) on
the incoming and outgoing path of emails, which means it is unlikely that
mailing lists need to be changed, but only the MTA that support the mailing
list. I think the proposition is slightly simpler to deploy here.
___
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?

[Rolf E. Sonneveld via dmarc-discuss]

Hi, Terry,

On 22-10-15 22:16, Terry Zink via dmarc-discuss wrote:

Sad to see that Gmail plan to move to p=reject

Why do you say this? Because it will disrupt mailing lists (as in, yahoo.com 
refugees moved to gmail.com and now that will no longer available)?

If ARC solves the problem of mailing lists, then it means anyone with a domain 
with p=reject can join a mailing list (which is great, no hacky workarounds 
needed) and helps drive email authentication forward.


True. And I have to say that the ARC proposal looks quite promising. But 
there's no running code around yet (maybe there is within the big ESPs?) 
and do we know how ARC will behave in the real world on an Internet 
scale (big ESPs + the other half of the Internet)? For example, what 
about resource consumption in case of long chains of intermediaries, 
what about header size in relation to some MTAs and AS systems imposing 
header length limits etc.? Meanwhile, the announcement that Gmail will 
move to p=reject has already been made, so I hope ARC is the way to go 
to solve the problems mentioned in the Interoperability draft and it 
will be in time to implement it for the mailing lists I run.


Is there a list where ARC is being discussed? Are there any (test) 
reports on the use of ARC available?


/rolf

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

[Roland Turner via dmarc-discuss]

ARC provides a standardised, software-implementable, means for trustworthy 
forwarders to implement chain-of-custody records and therefore for receivers to 
reliably and simply automate assessments about messages received through 
trustworthy paths that are currently both generally too complicated to make 
other than by hand and - for longer forwarding chains than 
author->list->recipient - depend upon trusting untrustworthy data from several 
hops upstream.

The decisions about who to trust remain more-or-less those which receivers 
already make, ARC extends the distance that that trust can be algorithmically 
extended. An untrusted bad guy gains nothing, except against a naive receiver 
who imagines that ARC is magic. See also naive receivers assuming that SPF 
passing meant that a message was not spam. Likewise DKIM passing. Likewise 
DMARC passing. The important change here is that, in addition to incorporating 
an assessment of the trustworthiness of the author and/or the last hop, 
assessments of the trustworthiness of forwarders enter the picture.

- Roland


Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com




From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 04:44
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] A bit quiet?

On October 22, 2015 1:19:51 PM EDT, 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/
>

How does that actually help? At least as I read the draft, anyone can make up a 
'bad' message and an associated made up DKIM signature and then add their ARC 
stamp claiming the signature was valid when the message arrived?

Scott K

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

[Scott Kitterman via dmarc-discuss]

Okay. If I implement ARC as a receiver, then I ignore p=reject from Senders I 
trust not to lie to me if it passes ARC?

Scott K

On October 22, 2015 10:15:24 PM EDT, Roland Turner via dmarc-discuss 
 wrote:
>ARC provides a standardised, software-implementable, means for
>trustworthy forwarders to implement chain-of-custody records and
>therefore for receivers to reliably and simply automate assessments
>about messages received through trustworthy paths that are currently
>both generally too complicated to make other than by hand and - for
>longer forwarding chains than author->list->recipient - depend upon
>trusting untrustworthy data from several hops upstream.
>
>The decisions about who to trust remain more-or-less those which
>receivers already make, ARC extends the distance that that trust can be
>algorithmically extended. An untrusted bad guy gains nothing, except
>against a naive receiver who imagines that ARC is magic. See also naive
>receivers assuming that SPF passing meant that a message was not spam.
>Likewise DKIM passing. Likewise DMARC passing. The important change
>here is that, in addition to incorporating an assessment of the
>trustworthiness of the author and/or the last hop, assessments of the
>trustworthiness of forwarders enter the picture.
>
>- Roland
>
>
>Roland Turner | Labs Director
>Singapore | M: +65 96700022
>roland.tur...@trustsphere.com
>
>
>
>
>From: dmarc-discuss  on behalf of
>Scott Kitterman via dmarc-discuss 
>Sent: Friday, 23 October 2015 04:44
>To: dmarc-discuss@dmarc.org
>Subject: Re: [dmarc-discuss] A bit quiet?
>
>On October 22, 2015 1:19:51 PM EDT, 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/
>>
>
>How does that actually help? At least as I read the draft, anyone can
>make up a 'bad' message and an associated made up DKIM signature and
>then add their ARC stamp claiming the signature was valid when the
>message arrived?
>
>Scott K
>
>___
>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)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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?

[Roland Turner via dmarc-discuss]

Broadly, yes. You'd need to trust the entire chain of ARC-signing forwarders of 
course.


- Roland



[http://www.trustsphere.com/images/signatures/trustsphere.png]<https://www.trustsphere.com>
 Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com<mailto:roland.tur...@trustsphere.com>





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 10:42
To: DMARC Discussion List
Subject: Re: [dmarc-discuss] A bit quiet?

Okay. If I implement ARC as a receiver, then I ignore p=reject from Senders I 
trust not to lie to me if it passes ARC?

Scott K

On October 22, 2015 10:15:24 PM EDT, Roland Turner via dmarc-discuss 
 wrote:

ARC provides a standardised, software-implementable, means for trustworthy 
forwarders to implement chain-of-custody records and therefore for receivers to 
reliably and simply automate assessments about messages received through 
trustworthy paths that are currently both generally too complicated to make 
other than by hand and - for longer forwarding chains than 
author->list->recipient - depend upon trusting untrustworthy data from several 
hops upstream.

The decisions about who to trust remain more-or-less those which receivers 
already make, ARC extends the distance that that trust can be algorithmically 
extended. An untrusted bad guy gains nothing, except against a naive receiver 
who imagines that ARC is magic. See also naive receivers assuming that SPF 
passing meant that a message was not spam. Likewise DKIM passing. Likewise 
DMARC passing. The important change here is that, in addition to incorporating 
an assessment of the trustworthines!
 s of the
author and/or the last hop, assessments of the trustworthiness of forwarders 
enter the picture.

- Roland


Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 04:44
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] A bit quiet?

On October 22, 2015 1:19:51 PM EDT, 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/


How does that actually help? At least as I read the draft, anyone can make up a 
'bad' message and an associated made up DKIM signature and then add their ARC 
stamp claiming the signature was valid when the message arrived?

Scott K



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)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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?

[Jacob Evans via dmarc-discuss]

Maybe I misread something but I thought the purpose of ARC was to allow senders 
to relay these types of messages to list groups, and allow each receiver to 
independently evaluate the source in addition to the list system. 





So this email is evaluated by the list server, and if my message passes it is 
sent down to those subscribed to this list. 




Those subscribed to this list evaluate the list email AND the origination email 
that I sent as ARC would include the required information to make these 
'background checks' 




Since SPF will never survive, but DKIM could survive depending on settings, ARC 
is another layer especially for lists. 




But I could be way off on this concept too. 




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

[Scott Kitterman via dmarc-discuss]

If I trust the sender enough to override DMARC policy results, what more does 
ARC add?  

I thought we'd already discussed the idea of the non-scalability of whitelists 
to death.  Absent a trusted sender whitelist, what can you do with ARC?

Scott K

On October 22, 2015 11:03:59 PM EDT, Roland Turner via dmarc-discuss 
 wrote:
>Broadly, yes. You'd need to trust the entire chain of ARC-signing
>forwarders of course.
>
>
>- Roland
>
>
>
>[http://www.trustsphere.com/images/signatures/trustsphere.png]<https://www.trustsphere.com>
>Roland Turner | Labs Director
>Singapore | M: +65 96700022
>roland.tur...@trustsphere.com<mailto:roland.tur...@trustsphere.com>
>
>
>
>
>
>From: dmarc-discuss  on behalf of
>Scott Kitterman via dmarc-discuss 
>Sent: Friday, 23 October 2015 10:42
>To: DMARC Discussion List
>Subject: Re: [dmarc-discuss] A bit quiet?
>
>Okay. If I implement ARC as a receiver, then I ignore p=reject from
>Senders I trust not to lie to me if it passes ARC?
>
>Scott K
>
>On October 22, 2015 10:15:24 PM EDT, Roland Turner via dmarc-discuss
> wrote:
>
>ARC provides a standardised, software-implementable, means for
>trustworthy forwarders to implement chain-of-custody records and
>therefore for receivers to reliably and simply automate assessments
>about messages received through trustworthy paths that are currently
>both generally too complicated to make other than by hand and - for
>longer forwarding chains than author->list->recipient - depend upon
>trusting untrustworthy data from several hops upstream.
>
>The decisions about who to trust remain more-or-less those which
>receivers already make, ARC extends the distance that that trust can be
>algorithmically extended. An untrusted bad guy gains nothing, except
>against a naive receiver who imagines that ARC is magic. See also naive
>receivers assuming that SPF passing meant that a message was not spam.
>Likewise DKIM passing. Likewise DMARC passing. The important change
>here is that, in addition to incorporating an assessment of the
>trustworthines!
> s of the
>author and/or the last hop, assessments of the trustworthiness of
>forwarders enter the picture.
>
>- Roland
>
>
>Roland Turner | Labs Director
>Singapore | M: +65 96700022
>roland.tur...@trustsphere.com
>
>
>
>____
>
>From: dmarc-discuss  on behalf of
>Scott Kitterman via dmarc-discuss 
>Sent: Friday, 23 October 2015 04:44
>To: dmarc-discuss@dmarc.org
>Subject: Re: [dmarc-discuss] A bit quiet?
>
>On October 22, 2015 1:19:51 PM EDT, 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/
>
>
>How does that actually help? At least as I read the draft, anyone can
>make up a 'bad' message and an associated made up DKIM signature and
>then add their ARC stamp claiming the signature was valid when the
>message arrived?
>
>Scott K
>
>
>
>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)
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>
>
>___
>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)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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?

[Roland Turner via dmarc-discuss]

The question is not who you trust - ARC doesn't directly change that - but how 
you reliably automate determining whether the message was forwarded only by 
people that you trust. At present, you have to dig through Received: headers, 
infer per-forwarder internal structure and behaviour and, frequently, guess. 
ARC addresses that problem, not the one you're asking about.


The amount of discussion to date about specific historical whitelist proposals 
is neither here nor there. The question is whether ARC's degree of support for 
reliable automatic chain-of-custody assessment provides a material improvement 
for a group of receivers interoperating with a group of forwarders. So long as 
the answer to that question is yes, then this is progress. I'd suggest that:

  *   large receivers are generally keen to implement things that materially 
improve their ability to separate wheat from chaff (ARC does this if it's 
implemented by any significant subset of mailing-list operators), and
  *   at least some of the mailing-list operators whose discomfort with DMARC 
interoperation is the need to disrupt long-traditional norms (leaving From: 
unchanged but tagging Subject:, stripping multiparts, adding footers, ...) will 
be willing to perform ARC processing on messages on the way in, in order to 
interoperate without giving up traditional mailing-list operations.

If these are both true, then ARC is a clear benefit.


- Roland




[http://www.trustsphere.com/images/signatures/trustsphere.png]<https://www.trustsphere.com>
 Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com<mailto:roland.tur...@trustsphere.com>





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 12:31
To: DMARC Discussion List
Subject: Re: [dmarc-discuss] A bit quiet?

If I trust the sender enough to override DMARC policy results, what more does 
ARC add?

I thought we'd already discussed the idea of the non-scalability of whitelists 
to death. Absent a trusted sender whitelist, what can you do with ARC?

Scott K

On October 22, 2015 11:03:59 PM EDT, Roland Turner via dmarc-discuss 
 wrote:

Broadly, yes. You'd need to trust the entire chain of ARC-signing forwarders of 
course.


- Roland



[http://www.trustsphere.com/images/signatures/trustsphere.png]<https://www.trustsphere.com>
 Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com<mailto:roland.tur...@trustsphere.com>





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 10:42
To: DMARC Discussion List
Subject: Re: [dmarc-discuss] A bit quiet?

Okay. If I implement ARC as a receiver, then I ignore p=reject from Senders I 
trust not to lie to me if it passes ARC?

Scott K

On October 22, 2015 10:15:24 PM EDT, Roland Turner via dmarc-discuss 
 wrote:

ARC provides a standardised, software-implementable, means for trustworthy 
forwarders to implement chain-of-custody records and therefore for receivers to 
reliably and simply automate assessments about messages received through 
trustworthy paths that are currently both generally too complicated to make 
other than by hand and - for longer forwarding chains than 
author->list->recipient - depend upon trusting untrustworthy data from several 
hops upstream.

The decisions about who to trust remain more-or-less those which receivers 
already make, ARC extends the distance that that trust can be algorithmically 
extended. An untrusted bad guy gains nothing, except against a naive receiver 
who imagines that ARC is magic. See also naive receivers assuming that SPF 
passing meant that a message was not spam. Likewise DKIM passing. Likewise 
DMARC passing. The important change here is that, in addition to incorporating 
an assessment of the trustworthines!
 s of the
author and/or the last hop, assessments of the trustworthiness of forwarders 
enter the picture.

- Roland


Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Friday, 23 October 2015 04:44
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] A bit quiet?

On October 22, 2015 1:19:51 PM EDT, 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/


How does that actually help? At least as I read the draft, anyone can make up a 
'bad' message and an associated made up DKIM signature and then add their ARC 
stamp claiming the signature was valid when the message arrived?

Scott K



dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NO

Re: [dmarc-discuss] A bit quiet?

[Andrew Beverley via dmarc-discuss]

On Thu, 2015-10-22 at 12:42 -0700, Franck Martin wrote:
> > Let's hope ARC delivers.
> > 
> Hopefully you can help achieve this goal with the resources at your
> disposition.

Certainly happy to sponsor the development of open source libraries (and
assist with testing), if anyone is interested in being on the receiving
end (or also contributing)?

As Rolf has already asked: is there anywhere else where ARC is being
discussed? I am surprised that this is the first I have seen it
mentioned on this email list.

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)

Re: [dmarc-discuss] A bit quiet?

[Andrew Beverley via dmarc-discuss]

On Thu, 2015-10-22 at 20:16 +, Terry Zink via dmarc-discuss wrote:
> > 
> > Sad to see that Gmail plan to move to p=reject
> 
> Why do you say this?

Because I thought Google "got it", and the announcement seems a little
premature.

>  Because it will disrupt mailing lists

The reasons have already been discussed extensively, and generally boil
down to cost vs benefit.

> If ARC solves the problem of mailing lists, then it means anyone with 
> a domain with p=reject can join a mailing list (which is great, no 
> hacky workarounds needed) and helps drive email authentication 
> forward.

Of course, if everything works out fine (and in time) then great. It
will have been a long journey getting there though - let's hope it's
worth the cost.

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)

Re: [dmarc-discuss] A bit quiet?

[Rolf E. Sonneveld via dmarc-discuss]

Hi, Andy,

On 23-10-15 12:52, Andrew Beverley via dmarc-discuss wrote:

On Thu, 2015-10-22 at 12:42 -0700, Franck Martin wrote:

Let's hope ARC delivers.


Hopefully you can help achieve this goal with the resources at your
disposition.

Certainly happy to sponsor the development of open source libraries (and
assist with testing), if anyone is interested in being on the receiving
end (or also contributing)?

As Rolf has already asked: is there anywhere else where ARC is being
discussed?


I found out yesterday: http://lists.dmarc.org/mailman/listinfo/arc-discuss

/rolf

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

[Scott Kitterman via dmarc-discuss]

On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss 
 wrote:
>The question is not who you trust - ARC doesn't directly change that -
>but how you reliably automate determining whether the message was
>forwarded only by people that you trust. At present, you have to dig
>through Received: headers, infer per-forwarder internal structure and
>behaviour and, frequently, guess. ARC addresses that problem, not the
>one you're asking about.

I don't see why the signing domain of the DKIM signature that could be added by 
the most recent sender doesn't already give an identifier  to use to evaluate 
trust in the sender.

I can see that ARC gives a way to communicate information about the upstream 
senders, but I don't see how that's related to DMARC.

>From a DMARC perspective, if you know the sender is trustworthy, you do a 
>local override.  ARC doesn't seem to be needed for that.
>
>The amount of discussion to date about specific historical whitelist
>proposals is neither here nor there. The question is whether ARC's
>degree of support for reliable automatic chain-of-custody assessment
>provides a material improvement for a group of receivers interoperating
>with a group of forwarders. So long as the answer to that question is
>yes, then this is progress. I'd suggest that:
>
>*   large receivers are generally keen to implement things that
>materially improve their ability to separate wheat from chaff (ARC does
>this if it's implemented by any significant subset of mailing-list
>operators), and
>*   at least some of the mailing-list operators whose discomfort with
>DMARC interoperation is the need to disrupt long-traditional norms
>(leaving From: unchanged but tagging Subject:, stripping multiparts,
>adding footers, ...) will be willing to perform ARC processing on
>messages on the way in, in order to interoperate without giving up
>traditional mailing-list operations.
>
>If these are both true, then ARC is a clear benefit.

Only if ARC processing materially affects if receivers are willing to consider 
the mailing list as trusted.  As far as I can tell, ARC does nothing for 
determining this.  In fact, it seems that from a DMARC mailing list problem 
perspective, ARC is almost exactly backwards.

ARC appears to leverage knowledge of who are trusted senders to make it easier 
to trace a message path.  If there's a way to know which senders are trusted, 
then DMARC can already be overridden.

Maybe I am just failing to understand, but this reads to me like a solution to 
the DMARC mailing list problem that only works if there already exists another 
solution to the DMARC mailing list problem.  That or it's completely unrelated 
to DMARC.  I'm not sure which.

Scott K 
___
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?

[J. Gomez via dmarc-discuss]

On Friday, October 23, 2015 4:07 PM, Scott Kitterman via dmarc-discuss wrote:

> On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss
>  wrote: 
> > The question is not who you trust - ARC doesn't directly change
> > that - but how you reliably automate determining whether the
> > message was forwarded only by people that you trust. At present,
> > you have to dig through Received: headers, infer per-forwarder
> > internal structure and behaviour and, frequently, guess. ARC
> > addresses that problem, not the one you're asking about.
> 
> I don't see why the signing domain of the DKIM signature that could
> be added by the most recent sender doesn't already give an identifier
> to use to evaluate trust in the sender.  
> 
> I can see that ARC gives a way to communicate information about the
> upstream senders, but I don't see how that's related to DMARC. 
> 
> From a DMARC perspective, if you know the sender is trustworthy, you
> do a local override.  ARC doesn't seem to be needed for that.

How do you know the sender is trustworthy, if the email he sends 
is failing a DMARC check?

Is this ARC thing a mechanism to know when it is safe to ignore 
the sender's DMARC policy of "p=reject"? And if it is such, shouldn't 
it be part of the DMARC standard?

Regards,
J.Gomez


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

[Scott Kitterman via dmarc-discuss]

On October 23, 2015 2:10:26 PM EDT, "J. Gomez via dmarc-discuss" 
 wrote:
>On Friday, October 23, 2015 4:07 PM, Scott Kitterman via dmarc-discuss
>wrote:
>
>> On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss
>>  wrote: 
>> > The question is not who you trust - ARC doesn't directly change
>> > that - but how you reliably automate determining whether the
>> > message was forwarded only by people that you trust. At present,
>> > you have to dig through Received: headers, infer per-forwarder
>> > internal structure and behaviour and, frequently, guess. ARC
>> > addresses that problem, not the one you're asking about.
>> 
>> I don't see why the signing domain of the DKIM signature that could
>> be added by the most recent sender doesn't already give an identifier
>> to use to evaluate trust in the sender.  
>> 
>> I can see that ARC gives a way to communicate information about the
>> upstream senders, but I don't see how that's related to DMARC. 
>> 
>> From a DMARC perspective, if you know the sender is trustworthy, you
>> do a local override.  ARC doesn't seem to be needed for that.
>
>How do you know the sender is trustworthy, if the email he sends 
>is failing a DMARC check?
>
>Is this ARC thing a mechanism to know when it is safe to ignore 
>the sender's DMARC policy of "p=reject"? And if it is such, shouldn't 
>it be part of the DMARC standard?

It's not. It's only useful when provided by senders you trust.

Scott K
___
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?

[John Levine via dmarc-discuss]

>Why do you say this? Because it will disrupt mailing lists (as in, yahoo.com 
>refugees moved to gmail.com
>and now that will no longer available)?

Yes.

>If ARC solves the problem of mailing lists, then it means anyone with a domain 
>with p=reject can join a
>mailing list (which is great, no hacky workarounds needed) and helps drive 
>email authentication forward.

Too bad for the other stuff that DMARC broke.

Bull in a china shop and all that.

R's,
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?

[John Levine via dmarc-discuss]

>From a DMARC perspective, if you know the sender is trustworthy, you do a 
>local override.  ARC doesn't
>seem to be needed for that.

I have many of the same questions you do, but it is my impression that
a surprising number of lists behave fine for a long time, then some
bad guy starts pumping spam through it by impersonating one of the
subscribers.

ARC should be helpful in that perhaps non-exotic situation.

R's,
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?

[Scott Kitterman via dmarc-discuss]

On October 23, 2015 8:37:06 PM EDT, John Levine  wrote:
>>From a DMARC perspective, if you know the sender is trustworthy, you
>do a local override.  ARC doesn't
>>seem to be needed for that.
>
>I have many of the same questions you do, but it is my impression that
>a surprising number of lists behave fine for a long time, then some
>bad guy starts pumping spam through it by impersonating one of the
>subscribers.
>
>ARC should be helpful in that perhaps non-exotic situation.

Could be.  I certainly don't claim it's not potentially useful.  My concern is 
that it seems to be marketed as a solution to the DMARC mailing list problem 
and as far as I can tell, its potential utility is orthogonal to that.

Scott K
___
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?

[J. Gomez via dmarc-discuss]

On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman via 
dmarc-discuss wrote:

> On October 23, 2015 8:37:06 PM EDT, John Levine 
> wrote: 
> > > From a DMARC perspective, if you know the sender is trustworthy,
> > > you do a local override.  ARC doesn't
> > > seem to be needed for that.
> > 
> > I have many of the same questions you do, but it is my impression
> > that a surprising number of lists behave fine for a long time, then
> > some bad guy starts pumping spam through it by impersonating one of
> > the subscribers.
> > 
> > ARC should be helpful in that perhaps non-exotic situation.
> 
> Could be.  I certainly don't claim it's not potentially useful.  My
> concern is that it seems to be marketed as a solution to the DMARC
> mailing list problem and as far as I can tell, its potential utility
> is orthogonal to that.

Ok, you said "from a DMARC perspective, if you know the sender is trustworthy, 
you do a local override". But imagine big ESP "A" with hundreds of thousands of 
users who may subscribe to all kinds of mailing lists of which mailing lists 
you --as big ESP "B"-- had no previous knowledge and on which you have no 
a-priori trust.

In that scenario, when you as big ESP "B" receive email from such mailing lists 
addressed to your users, you don't know whether the sender (i.e., the mailing 
list) is trustworthy because you didn't know anything about him until now, so 
you cannot do a local override of DMARC in an automated and safe way.

But if the big ESP "A" user sent a DKIM signed message to that list, and that 
list added a ARC seal to the message when it forwarded said message to the 
list's subscribers, then you --as big ESP "B" and as recipient of said 
message-- could verify that it is true that said user from big ESP "A" indeed 
sent that original email addressed to the list, and if the ARC chain is 
verifiable and goes back to someone you trust then you could begin to put some 
trust also in the other end of the ARC chain (on its latest iteration), and 
therefore do a local override of DMARC in an automated and safe way even with 
email received from senders your didn't know were trustworthy.

Am I too off base?

Regards,
J.Gomez


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

[Franck Martin via dmarc-discuss]

I think ARC is making it clear it does not provide a chain of trust but a
custodial chain.

Assessing the trust of this custodial chain is left as an exercise to the
implementer :P

Seriously, a very simple system, is to extract all the domains in the chain
and see if any is on a blocklist (including newly observed domains).

On Sat, Oct 24, 2015 at 3:42 AM, J. Gomez via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman via
> dmarc-discuss wrote:
>
> > On October 23, 2015 8:37:06 PM EDT, John Levine 
> > wrote:
> > > > From a DMARC perspective, if you know the sender is trustworthy,
> > > > you do a local override.  ARC doesn't
> > > > seem to be needed for that.
> > >
> > > I have many of the same questions you do, but it is my impression
> > > that a surprising number of lists behave fine for a long time, then
> > > some bad guy starts pumping spam through it by impersonating one of
> > > the subscribers.
> > >
> > > ARC should be helpful in that perhaps non-exotic situation.
> >
> > Could be.  I certainly don't claim it's not potentially useful.  My
> > concern is that it seems to be marketed as a solution to the DMARC
> > mailing list problem and as far as I can tell, its potential utility
> > is orthogonal to that.
>
> Ok, you said "from a DMARC perspective, if you know the sender is
> trustworthy, you do a local override". But imagine big ESP "A" with
> hundreds of thousands of users who may subscribe to all kinds of mailing
> lists of which mailing lists you --as big ESP "B"-- had no previous
> knowledge and on which you have no a-priori trust.
>
> In that scenario, when you as big ESP "B" receive email from such mailing
> lists addressed to your users, you don't know whether the sender (i.e., the
> mailing list) is trustworthy because you didn't know anything about him
> until now, so you cannot do a local override of DMARC in an automated and
> safe way.
>
> But if the big ESP "A" user sent a DKIM signed message to that list, and
> that list added a ARC seal to the message when it forwarded said message to
> the list's subscribers, then you --as big ESP "B" and as recipient of said
> message-- could verify that it is true that said user from big ESP "A"
> indeed sent that original email addressed to the list, and if the ARC chain
> is verifiable and goes back to someone you trust then you could begin to
> put some trust also in the other end of the ARC chain (on its latest
> iteration), and therefore do a local override of DMARC in an automated and
> safe way even with email received from senders your didn't know were
> trustworthy.
>
> Am I too off base?
>
> Regards,
> J.Gomez
>
>
> ___
> 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?

[Scott Kitterman via dmarc-discuss]

On October 24, 2015 6:42:46 AM EDT, "J. Gomez via dmarc-discuss" 
 wrote:
>On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman via
>dmarc-discuss wrote:
>
>> On October 23, 2015 8:37:06 PM EDT, John Levine 
>> wrote: 
>> > > From a DMARC perspective, if you know the sender is trustworthy,
>> > > you do a local override.  ARC doesn't
>> > > seem to be needed for that.
>> > 
>> > I have many of the same questions you do, but it is my impression
>> > that a surprising number of lists behave fine for a long time, then
>> > some bad guy starts pumping spam through it by impersonating one of
>> > the subscribers.
>> > 
>> > ARC should be helpful in that perhaps non-exotic situation.
>> 
>> Could be.  I certainly don't claim it's not potentially useful.  My
>> concern is that it seems to be marketed as a solution to the DMARC
>> mailing list problem and as far as I can tell, its potential utility
>> is orthogonal to that.
>
>Ok, you said "from a DMARC perspective, if you know the sender is
>trustworthy, you do a local override". But imagine big ESP "A" with
>hundreds of thousands of users who may subscribe to all kinds of
>mailing lists of which mailing lists you --as big ESP "B"-- had no
>previous knowledge and on which you have no a-priori trust.
>
>In that scenario, when you as big ESP "B" receive email from such
>mailing lists addressed to your users, you don't know whether the
>sender (i.e., the mailing list) is trustworthy because you didn't know
>anything about him until now, so you cannot do a local override of
>DMARC in an automated and safe way.
>
>But if the big ESP "A" user sent a DKIM signed message to that list,
>and that list added a ARC seal to the message when it forwarded said
>message to the list's subscribers, then you --as big ESP "B" and as
>recipient of said message-- could verify that it is true that said user
>from big ESP "A" indeed sent that original email addressed to the list,
>and if the ARC chain is verifiable and goes back to someone you trust
>then you could begin to put some trust also in the other end of the ARC
>chain (on its latest iteration), and therefore do a local override of
>DMARC in an automated and safe way even with email received from
>senders your didn't know were trustworthy.
>
>Am I too off base?

As described in the drafts, the ARC stamp is applied by the intermediary, not 
the originator, so I don't think that works.

Even if it did, it's still just another variant of whitelisting, which is 
unlikely to scale very well.  Also, it could really only work for big domains. 
Us little guys don't generate enough traffic to register in the big guys 
reputation systems.

Scott K
___
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?

[Franck Martin via dmarc-discuss]

On Sun, Oct 25, 2015 at 7:39 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> On October 24, 2015 6:42:46 AM EDT, "J. Gomez via dmarc-discuss" <
> dmarc-discuss@dmarc.org> wrote:
> >On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman via
> >dmarc-discuss wrote:
> >
> >> On October 23, 2015 8:37:06 PM EDT, John Levine 
> >> wrote:
> >> > > From a DMARC perspective, if you know the sender is trustworthy,
> >> > > you do a local override.  ARC doesn't
> >> > > seem to be needed for that.
> >> >
> >> > I have many of the same questions you do, but it is my impression
> >> > that a surprising number of lists behave fine for a long time, then
> >> > some bad guy starts pumping spam through it by impersonating one of
> >> > the subscribers.
> >> >
> >> > ARC should be helpful in that perhaps non-exotic situation.
> >>
> >> Could be.  I certainly don't claim it's not potentially useful.  My
> >> concern is that it seems to be marketed as a solution to the DMARC
> >> mailing list problem and as far as I can tell, its potential utility
> >> is orthogonal to that.
> >
> >Ok, you said "from a DMARC perspective, if you know the sender is
> >trustworthy, you do a local override". But imagine big ESP "A" with
> >hundreds of thousands of users who may subscribe to all kinds of
> >mailing lists of which mailing lists you --as big ESP "B"-- had no
> >previous knowledge and on which you have no a-priori trust.
> >
> >In that scenario, when you as big ESP "B" receive email from such
> >mailing lists addressed to your users, you don't know whether the
> >sender (i.e., the mailing list) is trustworthy because you didn't know
> >anything about him until now, so you cannot do a local override of
> >DMARC in an automated and safe way.
> >
> >But if the big ESP "A" user sent a DKIM signed message to that list,
> >and that list added a ARC seal to the message when it forwarded said
> >message to the list's subscribers, then you --as big ESP "B" and as
> >recipient of said message-- could verify that it is true that said user
> >from big ESP "A" indeed sent that original email addressed to the list,
> >and if the ARC chain is verifiable and goes back to someone you trust
> >then you could begin to put some trust also in the other end of the ARC
> >chain (on its latest iteration), and therefore do a local override of
> >DMARC in an automated and safe way even with email received from
> >senders your didn't know were trustworthy.
> >
> >Am I too off base?
>
> As described in the drafts, the ARC stamp is applied by the intermediary,
> not the originator, so I don't think that works.
>
> Even if it did, it's still just another variant of whitelisting, which is
> unlikely to scale very well.  Also, it could really only work for big
> domains. Us little guys don't generate enough traffic to register in the
> big guys reputation systems.
>
> And this is fine too, you don't need a reputation, you just need to not
have a negative reputation.
___
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?

[Al Iverson via dmarc-discuss]

On Fri, Oct 23, 2015 at 9:54 PM, Scott Kitterman via dmarc-discuss
 wrote:

>>ARC should be helpful in that perhaps non-exotic situation.
>
> Could be.  I certainly don't claim it's not potentially useful.  My concern 
> is that it seems to be marketed as a solution to the DMARC mailing list 
> problem and as far as I can tell, its potential utility is orthogonal to that.

The authors of ARC think it more directly applies to the issue of list
mail. Let's start from assuming that they might have a point and we'll
see how the first implementations of this work. But, if it doesn't
really address the issue, it's pretty easy to ignore. Most MLM tools
that want to keep working have already implemented DMARC workarounds
-- I can't see those going away unless ARC provides a better
alternative. And maybe not even then, who knows.

>From my own perspective, I'm unclear on how well this will work. I
assume the chain process is based on addressing anything thrown at at
it; mailing list posts going through mail forwarding; ARC on both
would in theory keep authentication intact and prevent p=reject policy
rejections. But we're talking the 1% of the 1% (of the 1%?), it feels
like the use cases might get more and more far out.

Regards,
Al Iverson

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com
___
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?

[Scott Kitterman via dmarc-discuss]

On October 25, 2015 4:48:03 PM EDT, Franck Martin  wrote:
>On Sun, Oct 25, 2015 at 7:39 AM, Scott Kitterman via dmarc-discuss <
>dmarc-discuss@dmarc.org> wrote:
>
>>
>>
>> On October 24, 2015 6:42:46 AM EDT, "J. Gomez via dmarc-discuss" <
>> dmarc-discuss@dmarc.org> wrote:
>> >On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman
>via
>> >dmarc-discuss wrote:
>> >
>> >> On October 23, 2015 8:37:06 PM EDT, John Levine 
>> >> wrote:
>> >> > > From a DMARC perspective, if you know the sender is
>trustworthy,
>> >> > > you do a local override.  ARC doesn't
>> >> > > seem to be needed for that.
>> >> >
>> >> > I have many of the same questions you do, but it is my
>impression
>> >> > that a surprising number of lists behave fine for a long time,
>then
>> >> > some bad guy starts pumping spam through it by impersonating one
>of
>> >> > the subscribers.
>> >> >
>> >> > ARC should be helpful in that perhaps non-exotic situation.
>> >>
>> >> Could be.  I certainly don't claim it's not potentially useful. 
>My
>> >> concern is that it seems to be marketed as a solution to the DMARC
>> >> mailing list problem and as far as I can tell, its potential
>utility
>> >> is orthogonal to that.
>> >
>> >Ok, you said "from a DMARC perspective, if you know the sender is
>> >trustworthy, you do a local override". But imagine big ESP "A" with
>> >hundreds of thousands of users who may subscribe to all kinds of
>> >mailing lists of which mailing lists you --as big ESP "B"-- had no
>> >previous knowledge and on which you have no a-priori trust.
>> >
>> >In that scenario, when you as big ESP "B" receive email from such
>> >mailing lists addressed to your users, you don't know whether the
>> >sender (i.e., the mailing list) is trustworthy because you didn't
>know
>> >anything about him until now, so you cannot do a local override of
>> >DMARC in an automated and safe way.
>> >
>> >But if the big ESP "A" user sent a DKIM signed message to that list,
>> >and that list added a ARC seal to the message when it forwarded said
>> >message to the list's subscribers, then you --as big ESP "B" and as
>> >recipient of said message-- could verify that it is true that said
>user
>> >from big ESP "A" indeed sent that original email addressed to the
>list,
>> >and if the ARC chain is verifiable and goes back to someone you
>trust
>> >then you could begin to put some trust also in the other end of the
>ARC
>> >chain (on its latest iteration), and therefore do a local override
>of
>> >DMARC in an automated and safe way even with email received from
>> >senders your didn't know were trustworthy.
>> >
>> >Am I too off base?
>>
>> As described in the drafts, the ARC stamp is applied by the
>intermediary,
>> not the originator, so I don't think that works.
>>
>> Even if it did, it's still just another variant of whitelisting,
>which is
>> unlikely to scale very well.  Also, it could really only work for big
>> domains. Us little guys don't generate enough traffic to register in
>the
>> big guys reputation systems.
>>
> And this is fine too, you don't need a reputation, you just need to
> not have a negative reputation.

So the idea is that arbitrary data added from an untrusted sender (unknown 
reputation) is sufficient to override DMARC p=reject?

Scott K
___
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?

[Shal Farley via dmarc-discuss]

J.Gomez,

> Is this ARC thing a mechanism to know when it is safe to ignore 
> the sender's DMARC policy of "p=reject"? 

It helps in judging that, but isn't complete by itself (you still need a 
reputation system for the intermediaries).

> And if it is such, shouldn't it be part of the DMARC standard?

I think it is separate because DMARC is directed to solving a problem for email 
originators, whereas ARC is directed to mail list operators to help mitigate 
the consequences of DMARC for them. 

Of course both impose mechanisms on email destinations; but the goal is that 
these additional mechanisms can improve the quality of the classification 
results (spam versus ham) applied to their user's inboxes.

-- Shal

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

[Shal Farley via dmarc-discuss]

Scott,

> So the idea is that arbitrary data added from an untrusted sender 
> (unknown reputation) is sufficient to override DMARC p=reject?

No, that isn't the idea at all.

It is up to the receiving service to decide how to handle the ARC information, 
but the guidance is not to simply accept it carte-blanche in that way. 
Particularly in the case of a null reputation the disposition of the message 
would most likely rest on whatever evaluation the receiver would have made had 
there been no ARC info.[1]

A quick read of the draft specification and/or recommended usage document is a 
worthwhile investment of your time if you want to understand the proposal.
http://arc-spec.org/

-- Shal
[1] 3.6 What if none of the intermediaries have been seen previously?
https://tools.ietf.org/html/draft-jones-arc-usage-00

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

[Shal Farley via dmarc-discuss]

Scott,

> As described in the drafts, the ARC stamp is applied by the 
> intermediary, not the originator, so I don't think that works.

Yes, but the intermediaries had to sign their ARC seal, and thereby identify 
themselves in a non-forgeable way.

> Even if it did, it's still just another variant of whitelisting, which 
> is unlikely to scale very well.

ARC itself isn't whitelisting, nor a reputation system, but it allows the 
recipient to build such a system based on solid identities - which is a big 
step up over trying to deduce the intermediaries from the chain of (forgeable) 
Received: headers.

> Also, it could really only work for big domains. Us little guys don't 
> generate enough traffic to register in the big guys reputation systems.

I think here's the key point. 

By allowing greater automation and accuracy in identifying intermediaries ARC 
may benefit the little guys the most - you won't as likely be lost in the noise 
because the receivers will be more likely to track the reputation of each and 
every ARC participant they receive from.

So when your list is the only intermediary on a message between BigSend and 
BigReceive, your reputation and only your reputation will be considered in 
rating the ARC results you provide. There will always be the "first time" 
problem of having no reputation for the first message you forward to 
BigReceive, but after that your reputation at BigReceive can be based far more 
on the quality of the messages you forward than on the sheer number of them.

-- Shal

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

[Shal Farley via dmarc-discuss]

Scott,

> If I trust the sender enough to override DMARC policy results, what more 
> does ARC add? 

A subtle, but important thing it adds is the identity of the bad actor. That 
is, in order to forge an ARC result the intermediary had to be in the DNS 
system with the relevant ARC information provided. 

So if you are maintaining a reputation system it becomes harder for the bad 
actors to escape a bad reputation. And much harder for bad actors to give good 
actors a bad reputation by using a good actor's name.

> I thought we'd already discussed the idea of the non-scalability of 
> whitelists to death. Absent a trusted sender whitelist, what can you do 
> with ARC?

The recommended usage document addresses some of this.
http://arc-spec.org/

But the bottom line is: not magic, just chain of custody. When a message fails 
DMARC you can use ARC to feed your own classifier for whether to obey a 
p=reject.

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

[Roland Turner via dmarc-discuss]

Al Iverson wrote:

> From my own perspective, I'm unclear on how well this will work. I
> assume the chain process is based on addressing anything thrown at at
> it; mailing list posts going through mail forwarding; ARC on both
> would in theory keep authentication intact and prevent p=reject policy
> rejections. But we're talking the 1% of the 1% (of the 1%?), it feels
> like the use cases might get more and more far out.

I'd suggest that what ARC solves - if it works - is the entirety of the 
problems for forwarders who are willing to cooperate but nonetheless wish to 
modify messages sufficiently to break DKIM, which remains the largest class of 
inadequately solved problems with DMARC. (Note that the current low fraction of 
p=reject mail is not hugely important; as the DMARC breakage cases disappear, a 
growing fraction of email can and will be subject to p=reject.)

There remains one unsolved significant case, that of independent origination 
("share this link") which, I suspect, will be permanently beyond reach for 
interoperable protocol standardisation (it depends entirely upon trust by 
receivers and not at all upon protocol mechanisms).

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

Shal wrote:

> By allowing greater automation and accuracy in identifying
> intermediaries ARC may benefit the little guys the most - you
> won't as likely be lost in the noise because the receivers will
> be more likely to track the reputation of each and every ARC
> participant they receive from.

+1

I stated earlier that ARC doesn't *directly* change who a receiver might trust. 
This is an important example of indirect/side-effect changes that are likely to 
arise as the system strengthens. It is not sufficient to justify doing it in 
the first place though.

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

> Okay. If I implement ARC as a receiver, then I ignore p=reject
> from Senders I trust not to lie to me if it passes ARC?

p=reject is asserted by Domain Owners, whether or not they're senders. This is 
orthogonal to ARC's interest in forwarders.

The situation in which to ignore a p=reject is that where you trust the *each* 
member of the custodial chain.

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

> On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss 
>  wrote:
>>The question is not who you trust - ARC doesn't directly change that -
>>but how you reliably automate determining whether the message was
>>forwarded only by people that you trust. At present, you have to dig
>>through Received: headers, infer per-forwarder internal structure and
>>behaviour and, frequently, guess. ARC addresses that problem, not the
>>one you're asking about.
>
> I don't see why the signing domain of the DKIM signature that could be
> added by the most recent sender doesn't already give an identifier  to use
> to evaluate trust in the sender.

It does, but that only allows you to identify - and apply your trust assessment 
to - the most recent sender. ARC provides a means to automatically assess the 
chain *upstream* of the most recent sender.

It might be worth pointing out that trust is this context is not absolute, and 
should not be transitive, because:

- trusting the integrity (good intention) of the forwarder is not the same as 
trusting the competence of the forwarder, and

- there are different competences that you may or may not be willing to trust 
(ability of a forwarder to ARC/DKIM sign correctly and maintain secrecy of keys 
is a *far* lower bar than ability of a forwarder to make exactly the same 
decisions about what abuse to exclude as those that you as receiver would make, 
particularly when you make local, secret decisions as part of doing so; this 
distinction gets increasingly acute as receivers get larger).

> I can see that ARC gives a way to communicate information about
> the upstream senders, but I don't see how that's related to DMARC.

Many receivers implementing DMARC wish to be able to make decisions about when 
to ignore p=reject on a more fine-grained basis than all-or-nothing trust of 
the most recent sender. ARC is built to facilitate this and, therefore, is 
directly relevant to DMARC.

> From a DMARC perspective, if you know the sender is trustworthy, you do a
> local override.  ARC doesn't seem to be needed for that.

You keep talking about "the sender" as if there were only one. In your message 
to which I am replying, there are 7 Received: headers in various formats from 
3, 4 or 5 ADMDs, interspersed with various information about authentication 
assessments. This is tough for me to assess as a human with considerable 
expertise in this area. For software to do it reliably would be both difficult 
and fragile. If you don't get why being able to perform this assessment 
automatically and reliably is valuable then ARC is never going to make sense to 
you, no matter how many detail questions you ask. I'd suggest that this may 
simply mean that ARC is not relevant to you and that, therefore, it may be the 
case that you can safely ignore it while those for whom the problem is relevant 
move forward to run the experiment.

>>The amount of discussion to date about specific historical whitelist
>>proposals is neither here nor there. The question is whether ARC's
>>degree of support for reliable automatic chain-of-custody assessment
>>provides a material improvement for a group of receivers interoperating
>>with a group of forwarders. So long as the answer to that question is
>>yes, then this is progress. I'd suggest that:
>>
>>*   large receivers are generally keen to implement things that
>>materially improve their ability to separate wheat from chaff (ARC does
>>this if it's implemented by any significant subset of mailing-list
>>operators), and
>>*   at least some of the mailing-list operators whose discomfort with
>>DMARC interoperation is the need to disrupt long-traditional norms
>>(leaving From: unchanged but tagging Subject:, stripping multiparts,
>>adding footers, ...) will be willing to perform ARC processing on
>>messages on the way in, in order to interoperate without giving up
>>traditional mailing-list operations.
>>
>>If these are both true, then ARC is a clear benefit.
>
> Only if ARC processing materially affects if receivers are willing to
> consider the mailing list as trusted.

No, as with *ALL* protocol specifications, decisions about who to trust are out 
of scope. Operators will always make their own decisions about who to trust, 
protocol specifications can't usefully take over this function.

> ARC appears to leverage knowledge of who are trusted senders
> to make it easier to trace a message path.

Yes.

> If there's a way to know which senders are trusted, then
> DMARC can already be overridden.

No, for the reasons outlined above, it's not currently possible - in general - 
to work out whether the sender named in a particular Received: header actually 
handled the message. Your argument is a little like claiming that DKIM is not 
necessary because if you trust the domain named in the From: header and also 
the most recent sender then you don't need to perform your own signature 
validation. The need for DKIM arises specifi

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

J. Gomez wrote:

> How do you know the sender is trustworthy, if the email
> he sends is failing a DMARC check?

This question is an operational one that is out of scope for a protocol 
specification whose purpose is to facilitate interoperation of mechanisms 
(software). Operators will always make their own decisions about who to trust.

>Is this ARC thing a mechanism to know when it is safe to ignore
> the sender's DMARC policy of "p=reject"? And if it is such, shouldn't
> it be part of the DMARC standard?

ARC is still an experiment, working out whether it should pass through IETF as 
part of DMARC or as a separate specification is probably a little premature at 
this moment. I'd suggest that there are arguments both for and against doing so.

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

Re: [dmarc-discuss] A bit quiet?

[Shal Farley via dmarc-discuss]

Roland Turner wrote:

> I'd suggest that what ARC solves - if it works - is the entirety of the 
> problems for forwarders who are willing to cooperate but nonetheless 
> wish to modify messages sufficiently to break DKIM, ...

Although I think ARC is a step forward, I think it still leaves list managers 
with a bit of a conundrum, at least in the near and moderate term: at what 
point does it make sense for the list service to invest the effort in 
implementing ARC processing? 

I'm a user (not an employee) of an independent mailing list system[1], and that 
system follows the fairly typical practice of inserting a list tag in the 
subject line, and appending a standard footer to each message. Thus breaking 
the original DKIM signature.

The service has adapted to DMARC in the following way: if the domain of the 
sender publishes p=reject then the list "takes ownership" of the message by 
modifying the From: address to be the domain of the list, and providing both 
SPF and DKIM information which should pass DMARC. Otherwise the list passes the 
sender's From address unmodified (and its SPF records are moot, for DMARC 
purposes, as is its DKIM signature due to the domain mismatch).

The conundrum I foresee is that the service can't know which receiving domains 
have implemented ARC processing - and so can't know whether ARC processing will 
be effective at getting their messages delivered, that is, effective as 
compared to taking ownership.

Now it is also true that the service can't know which receiving domains 
implement DMARC processing, except by way of public announcements or user 
complaints of non-delivery. But taking ownership based on the sender moots that 
question. 

So I think ARC is a solution for list managers only if its adoption rate 
approaches 100% among mail receivers who implement DMARC processing. Maybe that 
will rapidly be the case, I don't know. It would make sense that any receiver 
that went to the effort of implementing DMARC processing would go for ARC as 
well, but until that is true in practice the conundrum remains.

-- Shal
[1] https://groups.io/

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

[Roland Turner via dmarc-discuss]

Shal wrote:

> Although I think ARC is a step forward, I think it still leaves list
> managers with a bit of a conundrum, at least in the near and moderate
> term: at what point does it make sense for the list service to invest
> the effort in implementing ARC processing?

There are multiple answers:

- The earliest adopters are likely to be the large forwarders who are creating 
problems for large receivers, in many cases these are the same organisations. 
These people are presumably already talking to each other. (Jmail's postmaster 
notices that 30% of his probably-OK DMARC forwarding failures are passing 
through KMail; Jmail's postmaster contacts Kmail's postmaster...) 

- Another group of likely early adopters are list operators who decided that 
DMARC just wasn't their problem and therefore pushed their Yahoo! users to move 
to Gmail. As this strategy is about to stop working abruptly, at least some of 
these list operators are likely to have reason to explore ARC signing.

- Forwarders who are large enough to be monitoring deliverability can trivially 
determine whether their ARC-signing is being successfully validated and/or when 
receivers trust them enough to accept messages despite failing DMARC.

There may be other groups that I've missed, but everybody else should probably 
keep their workarounds in place until the experiment has progressed to the 
point where the large receivers are publicly announcing that the water is fine. 
This is separate from the question of when to start ARC signing, that's 
probably worth doing sooner rather than later in order to shake out any bugs.

> The conundrum I foresee is that the service can't know which receiving domains
> have implemented ARC processing - and so can't know whether ARC processing 
> will
> be effective at getting their messages delivered, that is, effective as 
> compared
> to taking ownership.

I don't know anything about groups.io, but:

- Authentication-Results: headers are likely to show ARC results fairly 
promptly in receivers that implement it, meaning that it will be apparent 
whether or not signatures are validating.

- Hopefully groups.io is already monitoring deliverability. If not, then they 
should probably keep their workarounds in place for the foreseeable future.

> Now it is also true that the service can't know which receiving domains 
> implement
> DMARC processing, except by way of public announcements or user complaints of
> non-delivery.

This is not entirely correct. DMARC aggregate reports and 
Authentication-Results: headers both make clear whether (a) a receiver is 
implementing DMARC and (b) validation is succeeding. Receivers who are doing 
neither of these things should be treated pessimistically (treated as not 
implementing DMARC if you are a Domain Owner, or as implementing DMARC if 
you're a DKIM-breaking forwarder). In ARC's case, Authentication-Results: 
headers will pretty quickly make clear which [large] receivers are implementing 
ARC and whether signatures are validating. Deliverability monitoring will be 
required to determine whether trust is being extended.

> So I think ARC is a solution for list managers only if its adoption rate 
> approaches
> 100% among mail receivers who implement DMARC processing.

It's not a binary question, adoption happens in phases (e.g. the early adopters 
identified above will tend to go first) and even within an adopter happens in 
steps (implement ARC signing first, drop DMARC workarounds for test lists and 
monitor the results, etc.). No-one should be looking at ARC as plug-and-play, 
any more than they should at DMARC as plug-and-play.

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

Re: [dmarc-discuss] A bit quiet?

[Shal Farley via dmarc-discuss]

Roland wrote:

> - Forwarders who are large enough to be monitoring deliverability can 
> trivially determine whether their ARC-signing is being successfully 
> validated and/or when receivers trust them enough to accept messages 
> despite failing DMARC.

I see how that is possible when the forwarder has taken "ownership" of the 
message by putting their own domain in the From, but if they do ARC signing 
without taking ownership how do they know anything about the receiver's 
authentication results? I missed any reference to the intermediaries getting 
reports.

> - Hopefully groups.io is already monitoring deliverability. If not, then 
> they should probably keep their workarounds in place for the foreseeable 
> future.

Alas, that's beyond my level of knowledge. As evident from the preceding 
question.

>> Now it is also true that the service can't know which receiving domains 
>> implement
>> DMARC processing, except by way of public announcements or user complaints of
>> non-delivery.
>
> This is not entirely correct. DMARC aggregate reports and 
> Authentication-Results: headers both make clear whether (a) a receiver 
> is implementing DMARC and (b) validation is succeeding.

Yes, but those reports go to an address specified by originator's DNS records, 
as I understand it. Not to the intermediary, unless the intermediary becomes 
the originator by putting their own domain in the From: of the message. 

-- Shal

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

[Roland Turner via dmarc-discuss]

Shal wrote:

> Roland wrote:
>
>> - Forwarders who are large enough to be monitoring deliverability can
>> trivially determine whether their ARC-signing is being successfully
>> validated and/or when receivers trust them enough to accept messages
>> despite failing DMARC.
>
> I see how that is possible when the forwarder has taken "ownership"
> of the message by putting their own domain in the From, but if they do
> ARC signing without taking ownership how do they know anything about
> the receiver's authentication results? I missed any reference to the
> intermediaries getting reports.

DMARC feedback only tells Domain Owners about authentication results, it tells 
them nothing about deliverability and tells forwarders nothing at all. 
Assessing deliverability to a receiver requires monitored mailboxes on the 
receiver in question. The same mechanism will give access to 
Authentication-Results: headers. Per the above, it's generally only larger 
forwarders (or originators) who will be doing this.

>>> Now it is also true that the service can't know which receiving domains 
>>> implement
>>> DMARC processing, except by way of public announcements or user complaints 
>>> of
>>> non-delivery.
>>
>> This is not entirely correct. DMARC aggregate reports and
>> Authentication-Results: headers both make clear whether (a) a receiver
>> is implementing DMARC and (b) validation is succeeding.
>
> Yes, but those reports go to an address specified by originator's
> DNS records, as I understand it. Not to the intermediary, unless
> the intermediary becomes the originator by putting their own domain
> in the From: of the message.

Apologies, I missed "the service" in your comment so, no DMARC aggregate 
feedback would not be available. As above, Authentication-Results: access would 
also require monitored mailboxes in the receivers in question which, as above, 
is generally only relevant for larger forwarders/originators. Smaller 
forwarders shouldn't be dropping their workarounds just yet.

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

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote:
> Scott Kitterman wrote:
> > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss 
 wrote:
> >>The question is not who you trust - ARC doesn't directly change that -
> >>but how you reliably automate determining whether the message was
> >>forwarded only by people that you trust. At present, you have to dig
> >>through Received: headers, infer per-forwarder internal structure and
> >>behaviour and, frequently, guess. ARC addresses that problem, not the
> >>one you're asking about.
> >>
> > I don't see why the signing domain of the DKIM signature that could be
> > added by the most recent sender doesn't already give an identifier  to use
> > to evaluate trust in the sender.
> 
> It does, but that only allows you to identify - and apply your trust
> assessment to - the most recent sender. ARC provides a means to
> automatically assess the chain *upstream* of the most recent sender.

Only if you already have a high degree of trust in the most recent sender.

> It might be worth pointing out that trust is this context is not absolute,
> and should not be transitive, because:
> 
> - trusting the integrity (good intention) of the forwarder is not the same
> as trusting the competence of the forwarder, and
> 
> - there are different competences that you may or may not be willing to
> trust (ability of a forwarder to ARC/DKIM sign correctly and maintain
> secrecy of keys is a *far* lower bar than ability of a forwarder to make
> exactly the same decisions about what abuse to exclude as those that you as
> receiver would make, particularly when you make local, secret decisions as
> part of doing so; this distinction gets increasingly acute as receivers get
> larger).

Since the most recent sender can claim in an ARC stamp whatever arbitrary 
upstream senders they care to, it seems to me that placing any value at all on 
an ARC stamp from anything other than a highly trusted sender opens an abuse 
vector.

> > I can see that ARC gives a way to communicate information about
> > the upstream senders, but I don't see how that's related to DMARC.
> 
> Many receivers implementing DMARC wish to be able to make decisions about
> when to ignore p=reject on a more fine-grained basis than all-or-nothing
> trust of the most recent sender. ARC is built to facilitate this and,
> therefore, is directly relevant to DMARC.

It would already require a high level of trust in the most recent sender not 
to engage in ARC stamp forgery to do this.  Since DMARC is about 
authentication of an identity (5322.From), if you trust the most recent sender 
not to have forged the ARC stamp, I'm still not seeing the value of them 
adding the stamp.

> > From a DMARC perspective, if you know the sender is trustworthy, you do a
> > local override.  ARC doesn't seem to be needed for that.
> 
> You keep talking about "the sender" as if there were only one. In your
> message to which I am replying, there are 7 Received: headers in various
> formats from 3, 4 or 5 ADMDs, interspersed with various information about
> authentication assessments. This is tough for me to assess as a human with
> considerable expertise in this area. For software to do it reliably would
> be both difficult and fragile. If you don't get why being able to perform
> this assessment automatically and reliably is valuable then ARC is never
> going to make sense to you, no matter how many detail questions you ask.
> I'd suggest that this may simply mean that ARC is not relevant to you and
> that, therefore, it may be the case that you can safely ignore it while
> those for whom the problem is relevant move forward to run the experiment.

When I'm receiving a message, I'm receiving it from a single sender.  The 
message may have a history before that, but from my perspective, it's only got 
one at the moment.

I've never said ARC doesn't have value.  I've said I didn't see the value for 
solving the the issue that DMARC has with mailing lists that perform 
transformations that break DKIM signatures (like this one).   This is the 
DMARC list, not the ARC list.

I'm trying to understand why people seem to be claiming ARC is somehow helpful 
to DMARC.  I don't dispute it may be independently useful, but those uses 
would be off topic here.

> >>The amount of discussion to date about specific historical whitelist
> >>proposals is neither here nor there. The question is whether ARC's
> >>degree of support for reliable automatic chain-of-custody assessment
> >>provides a material improvement for a group of receivers interoperating
> >>with a group of forwarders. So long as the answer to that question is
> >>yes, then this is progress. I'd suggest that:
> >>
> >>*   large receivers are generally keen to implement things that
> >>materially improve their ability to separate wheat from chaff (ARC does
> >>this if it's implemented by any significant subset of mailing-list
> >>operators), and
> >>*  

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

> On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote:
>> Scott Kitterman wrote:
>> > I don't see why the signing domain of the DKIM signature that could be
>> > added by the most recent sender doesn't already give an identifier  to use
>> > to evaluate trust in the sender.
>>
>> It does, but that only allows you to identify - and apply your trust
>> assessment to - the most recent sender. ARC provides a means to
>> automatically assess the chain *upstream* of the most recent sender.
>
> Only if you already have a high degree of trust in the most recent sender.

No, see my earlier comments (that you quoted) immediately below.

>> It might be worth pointing out that trust is this context is not absolute,
>> and should not be transitive, because:
>>
>> - trusting the integrity (good intention) of the forwarder is not the same
>> as trusting the competence of the forwarder, and
>>
>> - there are different competences that you may or may not be willing to
>> trust (ability of a forwarder to ARC/DKIM sign correctly and maintain
>> secrecy of keys is a *far* lower bar than ability of a forwarder to make
>> exactly the same decisions about what abuse to exclude as those that you as
>> receiver would make, particularly when you make local, secret decisions as
>> part of doing so; this distinction gets increasingly acute as receivers get
>> larger).
>
> Since the most recent sender can claim in an ARC stamp whatever arbitrary
> upstream senders they care to, it seems to me that placing any value at all on
> an ARC stamp from anything other than a highly trusted sender opens an abuse
> vector.

Not just the most recent sender, all senders. Yes, you should only trust
ARC signatures by senders whose integrity you trust, obviously.

>> > I can see that ARC gives a way to communicate information about
>> > the upstream senders, but I don't see how that's related to DMARC.
>>
>> Many receivers implementing DMARC wish to be able to make decisions about
>> when to ignore p=reject on a more fine-grained basis than all-or-nothing
>> trust of the most recent sender. ARC is built to facilitate this and,
>> therefore, is directly relevant to DMARC.
>
> It would already require a high level of trust in the most recent sender not
> to engage in ARC stamp forgery to do this.  Since DMARC is about
> authentication of an identity (5322.From), if you trust the most recent sender
> not to have forged the ARC stamp, I'm still not seeing the value of them
> adding the stamp.

You would only see value in them adding the stamp if you assumed that they were
not trustworthy? I've re-read your paragraph above three times and really don't
understand your argument. I do wonder whether you're confusing trust of 
integrity
with trust of ability to exclude abuse.

Care to re-phrase?

>> > From a DMARC perspective, if you know the sender is trustworthy, you do a
>> > local override.  ARC doesn't seem to be needed for that.
>>
>> You keep talking about "the sender" as if there were only one. In your
>> message to which I am replying, there are 7 Received: headers in various
>> formats from 3, 4 or 5 ADMDs, interspersed with various information about
>> authentication assessments. This is tough for me to assess as a human with
>> considerable expertise in this area. For software to do it reliably would
>> be both difficult and fragile. If you don't get why being able to perform
>> this assessment automatically and reliably is valuable then ARC is never
>> going to make sense to you, no matter how many detail questions you ask.
>> I'd suggest that this may simply mean that ARC is not relevant to you and
>> that, therefore, it may be the case that you can safely ignore it while
>> those for whom the problem is relevant move forward to run the experiment.
>
> When I'm receiving a message, I'm receiving it from a single sender.  The
> message may have a history before that, but from my perspective, it's only got
> one at the moment.

In the sense that the SMTP connection came from a specific IP address, sure, but
that's a little beside the point. Many receivers implementing DMARC care about
the trustworthiness of each link in the chain, not merely the last one.

> I've never said ARC doesn't have value.  I've said I didn't see the value for
> solving the the issue that DMARC has with mailing lists that perform
> transformations that break DKIM signatures (like this one).   This is the
> DMARC list, not the ARC list.

I have assumed that it was self-evident that the context was DMARC.

> I'm trying to understand why people seem to be claiming ARC is somehow helpful
> to DMARC.  I don't dispute it may be independently useful, but those uses
> would be off topic here.

I am only discussing uses in a DMARC context.

>> >>If these are both true, then ARC is a clear benefit.
>> >>
>> > Only if ARC processing materially affects if receivers are willing to
>> > consider the mailing list as trusted.
>>
>> No, as 

Re: [dmarc-discuss] A bit quiet?

[MH Michael Hammer (5304) via dmarc-discuss]

> -Original Message-
> From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf
> Of Scott Kitterman via dmarc-discuss
> Sent: Monday, October 26, 2015 8:04 AM
> To: dmarc-discuss@dmarc.org
> Subject: Re: [dmarc-discuss] A bit quiet?
> 
> On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss
> wrote:
> > Scott Kitterman wrote:
> > > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss
>  wrote:
> > >>The question is not who you trust - ARC doesn't directly change that
> > >>- but how you reliably automate determining whether the message was
> > >>forwarded only by people that you trust. At present, you have to dig
> > >>through Received: headers, infer per-forwarder internal structure
> > >>and behaviour and, frequently, guess. ARC addresses that problem,
> > >>not the one you're asking about.
> > >>
> > > I don't see why the signing domain of the DKIM signature that could
> > > be added by the most recent sender doesn't already give an
> > > identifier  to use to evaluate trust in the sender.
> >
> > It does, but that only allows you to identify - and apply your trust
> > assessment to - the most recent sender. ARC provides a means to
> > automatically assess the chain *upstream* of the most recent sender.
> 
> Only if you already have a high degree of trust in the most recent sender.
> 

ARC provides additional visibility into the chain of message handlers, not just 
the most recent sender/handler. This may be useful to ultimate receivers in 
implementing local policy decisions, both in a DMARC context as well as absent 
a DMARC context.

> > It might be worth pointing out that trust is this context is not
> > absolute, and should not be transitive, because:
> >
> > - trusting the integrity (good intention) of the forwarder is not the
> > same as trusting the competence of the forwarder, and
> >
> > - there are different competences that you may or may not be willing
> > to trust (ability of a forwarder to ARC/DKIM sign correctly and
> > maintain secrecy of keys is a *far* lower bar than ability of a
> > forwarder to make exactly the same decisions about what abuse to
> > exclude as those that you as receiver would make, particularly when
> > you make local, secret decisions as part of doing so; this distinction
> > gets increasingly acute as receivers get larger).
> 
> Since the most recent sender can claim in an ARC stamp whatever arbitrary
> upstream senders they care to, it seems to me that placing any value at all on
> an ARC stamp from anything other than a highly trusted sender opens an
> abuse vector.
> 

As much as I believe the use of reputation is ultimately limited (I believe 
that reputation ultimately is "What have you done to me lately"), if the most 
recent (arbitrary) sender is making false claims in an ARC stamp, it should 
become apparent fairly quickly.

> > > I can see that ARC gives a way to communicate information about the
> > > upstream senders, but I don't see how that's related to DMARC.
> >
> > Many receivers implementing DMARC wish to be able to make decisions
> > about when to ignore p=reject on a more fine-grained basis than
> > all-or-nothing trust of the most recent sender. ARC is built to
> > facilitate this and, therefore, is directly relevant to DMARC.
> 
> It would already require a high level of trust in the most recent sender not 
> to
> engage in ARC stamp forgery to do this.  Since DMARC is about
> authentication of an identity (5322.From), if you trust the most recent sender
> not to have forged the ARC stamp, I'm still not seeing the value of them
> adding the stamp.
> 
> > > From a DMARC perspective, if you know the sender is trustworthy, you
> > > do a local override.  ARC doesn't seem to be needed for that.
> >
> > You keep talking about "the sender" as if there were only one. In your
> > message to which I am replying, there are 7 Received: headers in
> > various formats from 3, 4 or 5 ADMDs, interspersed with various
> > information about authentication assessments. This is tough for me to
> > assess as a human with considerable expertise in this area. For
> > software to do it reliably would be both difficult and fragile. If you
> > don't get why being able to perform this assessment automatically and
> > reliably is valuable then ARC is never going to make sense to you, no matter
> how many detail questions you ask.
> > I'd suggest that this may simply mean that ARC is not relevant to you
> > 

Re: [dmarc-discuss] A bit quiet?

[Al Iverson via dmarc-discuss]

On Mon, Oct 26, 2015 at 12:45 AM, Roland Turner via dmarc-discuss
 wrote:
> Al Iverson wrote:
>
>> From my own perspective, I'm unclear on how well this will work. I
>> assume the chain process is based on addressing anything thrown at at
>> it; mailing list posts going through mail forwarding; ARC on both
>> would in theory keep authentication intact and prevent p=reject policy
>> rejections. But we're talking the 1% of the 1% (of the 1%?), it feels
>> like the use cases might get more and more far out.
>
> I'd suggest that what ARC solves - if it works - is the entirety of the 
> problems for forwarders who are willing to cooperate but nonetheless wish to 
> modify messages sufficiently to break DKIM, which remains the largest class 
> of inadequately solved problems with DMARC. (Note that the current low 
> fraction of p=reject mail is not hugely important; as the DMARC breakage 
> cases disappear, a growing fraction of email can and will be subject to 
> p=reject.)
>
> There remains one unsolved significant case, that of independent origination 
> ("share this link") which, I suspect, will be permanently beyond reach for 
> interoperable protocol standardisation (it depends entirely upon trust by 
> receivers and not at all upon protocol mechanisms).

You get a gold star for thinking of a use case I had not considered!

"Share this link" AKA forward to a friend/FTAF/F2F. Yeah, potentially
an issue, but was already kind of an attractive nuisance when a
marketer tries to incentivize it (and thus really, really wants to
track it). If you don't care so much about tracking conversions/sales
that come after, you could probably just replace links to
"shareit.cgi" to
"mailto:friend@friend.example?subject=widget&body=check_out_this_widget.";
Then the mail starts from the initiator's MUA instead of from third
party infrastructure.

Cheers,
Al Iverson

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com

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

[J. Gomez via dmarc-discuss]

On Monday, October 26, 2015 7:52 AM [GMT+1=CET], Roland Turner via 
dmarc-discuss wrote:

> J. Gomez wrote:
> 
> > How do you know the sender is trustworthy, if the email
> > he sends is failing a DMARC check?
> 
> This question is an operational one that is out of scope for a
> protocol specification whose purpose is to facilitate interoperation
> of mechanisms (software). Operators will always make their own
> decisions about who to trust.   
> 
> > Is this ARC thing a mechanism to know when it is safe to ignore
> > the sender's DMARC policy of "p=reject"? And if it is such,
> > shouldn't it be part of the DMARC standard?
> 
> ARC is still an experiment, working out whether it should pass
> through IETF as part of DMARC or as a separate specification is
> probably a little premature at this moment. I'd suggest that there
> are arguments both for and against doing so.

Thanks for your answers.

You seem knowledgeable about ARC, so please bear with me...

Let's consider this scenario of a mail flow:

us...@yahoo.com --> list-of-pon...@maybe-we-are-evil.com --> 
us...@i-host-email.com

Where both us...@yahoo.com and us...@i-host-email.com are subscribers to the 
mailing list "List of Ponies".

And let's agree on the axiom that if a user has subscribed to a mailing list, 
then that user wants the messages from that mailing list to land on his Inbox.

If the postmaster at i-host-email.com is checking DMARC in incoming email, and 
if yahoo.com is publishing p=reject, that postmaster now has the problem of how 
to make sure that messages which us...@yahoo.com has sent to 
list-of-pon...@maybe-we-are-evil.com arrive successfully to the Inbox of 
us...@i-host-email.com, in a safe and automated way. I.e., that postmaster now 
has the problem of how to override DMARC in a safe and automated way.

And now, lets agree on a second axiom: if that postmaster would normally accept 
direct messages from us...@yahoo.com to us...@i-host-email.com, the idea would 
be that he would also accept messages from list-of-pon...@maybe-we-are-evil.com 
to us...@i-host-email.com if a positive verification could be made about 
whether said messages had really originated from us...@yahoo.com.

The question I have is: Can ARC help that postmaster with doing such a 
verification? (Yes/No)

Regards,
J.Gomez


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

[Scott Kitterman via dmarc-discuss]

On October 26, 2015 9:12:17 AM EDT, Roland Turner via dmarc-discuss 
 wrote:
>Scott Kitterman wrote:
...
snipped down to one bit as we seem to mostly be going around in circles
...
>> As a domain owner, I can control what sources of mail are able to
>> generate mail that passes SPF or has a valid DKIM signature with d=
>my
>> domain.  Anyone, anywhere can generate an ARC stamp with my domain in
>it,
>> so it's completely different.
>
>No, they can't.
>
>(More accurately, like a DKIM signature, anyone can create one, but it
>won't validate unless they've also gotten their hands on one of your
>private keys.)

Who adds the ARC stamp? Perhaps I read it wrong, but I read it as being added 
by the intermediary and not the originator (previous hop).

If I read it right, anyone can create an ARC stamp claiming to have received 
authenticate (e.g. DKIM signed) mail from my domain.  Am I reading it wrong?

Scott K
___
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?

[Shal Farley via dmarc-discuss]

Scott Kitterman wrote:

> Who adds the ARC stamp? Perhaps I read it wrong, but I read it as being 
> added by the intermediary and not the originator (previous hop).

That's correct.

> If I read it right, anyone can create an ARC stamp claiming to have 
> received authenticate (e.g. DKIM signed) mail from my domain.  

Correct, but unlike a received header, that bad actor has identified themselves 
by way of their signature on the claim. Having this stronger identification of 
the intermediaries is a key feature of ARC. 

By itself though the identification is not enough - it doesn't tell the 
receiver that the claim is false; the receiver must independently assess the 
trustworthiness of each ARC intermediary, by way of a reputation system or 
otherwise. The hope is that having a strong and automated way to identify the 
intermediaries will make creation and maintenance of the reputation system 
simpler, and increase its accuracy.

So in the end the receiver is holding a message, which by content analysis or 
otherwise it classifies for delivery. If the content classification is strongly 
negative not even passing DMARC is intended to override the classification (and 
certainly ARC results on a failing DMARC shouldn't). But that negative 
classification can drive the reputation engine. With a weak content 
classification result the ARC chain evaluation MAY be used to guide the local 
decision, leading to an override of the p=reject or not.

-- Shal

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

[Roland Turner via dmarc-discuss]

J. Gomez wrote:

> You seem knowledgeable about ARC, so please bear with me...

More about the problem being solved (I had reason to attempt this with 
Received: headers years ago) than about ARC specifically but, yes, I've read 
the draft and it makes sense to me.

> us...@yahoo.com --> list-of-pon...@maybe-we-are-evil.com --> 
> us...@i-host-email.com

> the idea would be that he would also accept messages from
> list-of-pon...@maybe-we-are-evil.com to us...@i-host-email.com
> if a positive verification could be made about whether said messages
> had really originated from us...@yahoo.com.
>
> The question I have is: Can ARC help that postmaster with doing such a 
> verification? (Yes/No)

Not quite as you've worded it: ARC processing doesn't provide verification of 
where a message really originated from (yahoo.com in this case), instead it 
potentially[1] allows a receiver to determine with reasonable certainty who 
modified it (maybe-we-are-evil.com in this case). With that information the 
receiver is in a position to make a local decision about whether to ignore the 
p=reject failure based upon reputation data accumulated by the receiver about 
the modifying party.

- Roland

1: So long as the modifying party performed ARC signing correctly.
___
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?

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

>> On October 26, 2015 9:12:17 AM EDT, Roland Turner via dmarc-discuss 
>>  wrote:
>>Scott Kitterman wrote:
> ...
> snipped down to one bit as we seem to mostly be going around in circles
> ...
>>> As a domain owner, I can control what sources of mail are able to
>>> generate mail that passes SPF or has a valid DKIM signature with d=
>>my
>>> domain.  Anyone, anywhere can generate an ARC stamp with my domain in
>>it,
>>> so it's completely different.
>>
>>No, they can't.
>>
>>(More accurately, like a DKIM signature, anyone can create one, but it
>>won't validate unless they've also gotten their hands on one of your
>>private keys.)
>
> Who adds the ARC stamp? Perhaps I read it wrong, but I read it as
> being added by the intermediary and not the originator (previous hop).

Any participating forwarder can add an ARC signature. Of necessity they sign
it with their own domain (as for DKIM, the rule for locating the public key 
remains
to query the DNS for a TXT record at {s}._domainkey.{d}) and, therefore, take
responsibility for the change. (You stated "generate an ARC stamp with my
domain in it", which is what I was rebutting.)

Note also that:

- The originator is at the beginning of the first hop, not necessarily
the immediately previous hop.

- Situations also arise in which multiple modifying forwarders are involved,
for example someone has a list subscription pointing to a long-term email
address that in turn forwards elsewhere but adds a footer while doing so.
A surprising fraction of my own posts to mailing lists experience this (not
only does DMARC fail, but e.g. the DKIM signature attached by Google Groups
fails too).

> If I read it right, anyone can create an ARC stamp claiming to have received
> authenticate (e.g. DKIM signed) mail from my domain.  Am I reading it wrong?

Indeed, anyone can claim anything. Forwarders making false claims of this type
aren't going to be trusted for very long.

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

Re: [dmarc-discuss] A bit quiet?

[Andrew Sullivan via dmarc-discuss]

On Mon, Oct 26, 2015 at 09:22:46PM -0700, Shal Farley via dmarc-discuss wro> 
> By itself though the identification is not enough - it doesn't tell the 
> receiver that the claim is false; the receiver must independently assess the 
> trustworthiness of each ARC intermediary, by way of a reputation system or 
> otherwise. The hope is that having a strong and automated way to identify the 
> intermediaries will make creation and maintenance of the reputation system 
> simpler, and increase its accuracy.
> 

Nothin' for nothin', but this seems like an awful lot of mechanism for
a pretty low-value piece of data, and if I'm reading you right the
people who have to implement this (at least mailing list operators)
need to do this so that someone _else's_ use of DMARC works, right?
It seems that the wrong party needs to do some work in this model.

A

-- 
Andrew Sullivan
Dyn
asulli...@dyn.com
___
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?

[Shal Farley via dmarc-discuss]

Andrew,

> Nothin' for nothin', but this seems like an awful lot of mechanism for
> a pretty low-value piece of data, and if I'm reading you right the
> people who have to implement this (at least mailing list operators)
> need to do this so that someone _else's_ use of DMARC works, right?

I think from the receiving mail system's point of view, a solid identification 
the intermediaries is _not_ low value. They are faced with customer 
dissatisfaction if they mis-classify messages in either direction, but 
especially if they put valued messages in quarantine.

 From the list manager's point of view the value proposition is similar, I 
think. They too are faced with customer dissatisfaction when list messages 
aren't delivered (and many list members seem prone to blame the list first, 
before looking in their "junk" folder). And in some sense the list managers 
have less work to do as it is all mechanism - no reputation system and 
associated database to maintain. Ideally the list manager need only plug in an 
implementation that someone else developed (or close to it).

Of course, in both those cases the value is predicated on the assumption that 
the mechanism will prove effective. Hopefully the early adopters will prove 
that out quickly.

> It seems that the wrong party needs to do some work in this model.

I've always felt that DMARC was putting the burden on the wrong parties, at 
least when applied to end-user email services like Yahoo Mail or Gmail. With 
commercial email, the bank notices and other customer communications which 
wouldn't normally be routed into a list service anyway, DMARC stands fine on 
its own, and p=reject has real meaning with no need for a reputation system to 
decide if local policy should override it. Scarcely any need even to care about 
content evaluation in those cases, since the bad is entirely on the known 
originator. 

But it got complicated real fast when someone thought that DMARC might apply to 
email service delivery as well. 

-- Shal

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

[Dave Warren via dmarc-discuss]

On 2015-10-27 00:30, Andrew Sullivan via dmarc-discuss wrote:

On Mon, Oct 26, 2015 at 09:22:46PM -0700, Shal Farley via dmarc-discuss wro>

By itself though the identification is not enough - it doesn't tell the 
receiver that the claim is false; the receiver must independently assess the 
trustworthiness of each ARC intermediary, by way of a reputation system or 
otherwise. The hope is that having a strong and automated way to identify the 
intermediaries will make creation and maintenance of the reputation system 
simpler, and increase its accuracy.


Nothin' for nothin', but this seems like an awful lot of mechanism for
a pretty low-value piece of data, and if I'm reading you right the
people who have to implement this (at least mailing list operators)
need to do this so that someone _else's_ use of DMARC works, right?
It seems that the wrong party needs to do some work in this model.


I look at it a little differently, it's the people (mailing list 
operators) who want to /modify/ my message that need to take steps to 
not break my DMARC in the process. If a mailing list passes a message 
without modification (allowing for additional List- headers, and other 
normal headers), my DMARC signature is still valid.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


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

[Shal Farley via dmarc-discuss]

Dave,

> I look at it a little differently, it's the people (mailing list 
> operators) who want to /modify/ my message that need to take steps to 
> not break my DMARC in the process. 

I look at it a little differently. 

As an end-user of email services I don't really care about your DMARC[1], but I 
do want my messages delivered to fellow list-members, and I want theirs 
delivered to me. If you've done something to your service (such as p=reject) 
which impedes delivery of the mail I want to exchange then you are not serving 
me (your customer) well. It is incumbent on /you/ to figure out how to send and 
receive messages on my behalf, even when I participate in email lists.

If ARC makes it easier for email services to fulfill the mission I ask of them, 
then I'll be satisfied with that. If DMARC+ARC results in improved 
classification results such that I see fewer unwanted messages so much the 
better.

I share your regret (expressed elsewhere) that some major email services 
adopted p=reject before they had developed and proved a workable solution for 
common mailing list practice.

> If a mailing list passes a message without modification (allowing for 
> additional List- headers, and other normal headers), my DMARC signature 
> is still valid.

Maybe. But if they do that they dissatisfy me, their customer. I want the 
Subject tags that email lists insert - they help me recognize and organize list 
messages. I want the footer they append to messages - they help me interact 
with the list service when needed.

-- Shal
1: In this case I'm assuming "you" are such a service. As I've said elsewhere, 
if you only originate and/or receive messages on behalf of your organization 
then I'm not your customer and I have no concern with how you use DMARC.

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

[Murray S. Kucherawy via dmarc-discuss]

On Fri, Oct 23, 2015 at 3:52 AM, Andrew Beverley via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Certainly happy to sponsor the development of open source libraries (and
> assist with testing), if anyone is interested in being on the receiving
> end (or also contributing)?
>

TDP will be adding experimental support for this to either OpenDKIM or
OpenDMARC.  I'm heading to IETF this weekend and will be taking the drafts
along to help kill the plane ride, and planning our implementation.

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

[Povl Hessellund Pedersen via dmarc-discuss]

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)

Re: [dmarc-discuss] A bit quiet?

[Alessandro Vesely via dmarc-discuss]

On Tue 20/Sep/2016 08:44:00 +0200 Povl Hessellund Pedersen wrote:


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;


Just curious how that resulted from the ungarbled form, which I guess was:

Authentication-Results: dsg.dk;
 spf=pass (sender IP is 209.85.214.50) smtp.mailfrom=my.test.dk;
 dkim=pass (signature was verified) header.d=my.test.dk;
 dmarc=pass action=none header.from=my.test.dk;
 dkim=pass (signature was verified) header.d=my.test.dk;

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

[Povl Hessellund Pedersen via dmarc-discuss]

I actually read the 2 dkim headers as the first being a validation of the SMTP 
from the 2nd as a validation of the body-from.
I would rather have the dkim on the body-from (visible to user) than on the 
SMTP from.

-Oprindelig meddelelse-
Fra: Terry Zink [mailto:tz...@exchange.microsoft.com] 
Sendt: 21. september 2016 20:01
Til: Alessandro Vesely ; Povl Hessellund Pedersen 

Emne: RE: [dmarc-discuss] A bit quiet?

That's an Office 365 stamp. The second "dkim=pass" is redundant (it's a bug I 
am trying to have fixed). The ungarbled form below is correct (minus the second 
DKIM result).

-Original Message-
From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of 
Alessandro Vesely via dmarc-discuss
Sent: Wednesday, September 21, 2016 12:48 AM
To: Povl Hessellund Pedersen 
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] A bit quiet?

On Tue 20/Sep/2016 08:44:00 +0200 Povl Hessellund Pedersen wrote:
>
> 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;

Just curious how that resulted from the ungarbled form, which I guess was:

Authentication-Results: dsg.dk;
  spf=pass (sender IP is 209.85.214.50) smtp.mailfrom=my.test.dk;
  dkim=pass (signature was verified) header.d=my.test.dk;
  dmarc=pass action=none header.from=my.test.dk;
  dkim=pass (signature was verified) header.d=my.test.dk;

Ale
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fmailman%2flistinfo%2fdmarc-discuss&data=02%7c01%7ctzink%40exchange.microsoft.com%7c0dba28d0105b40f688ca08d3e1f46bbf%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636100412304871716&sdata=zTd294kX4%2fldnZXoGzHDBgl%2fk0JKevWVBTJldVNeYuI%3d

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.dmarc.org%2fnote_well.html&data=02%7c01%7ctzink%40exchange.microsoft.com%7c0dba28d0105b40f688ca08d3e1f46bbf%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636100412304871716&sdata=026Ary8v%2bu4ikcPDcTIZnbxeVAuy0CsSiTjMkkeCbY0%3d)

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

[Franck Martin via dmarc-discuss]

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

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

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  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)
>
___
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://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 
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/
>>
>> 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?

[Franck Martin via dmarc-discuss]

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

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.

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

Re: [dmarc-discuss] A bit quiet?

[Paul Rock via dmarc-discuss]

I'll second what Franck has said -

Once we we figured out all of the 3rd parties we needed to talk to,
virtually everyone was happy to work with us to find a solution. The
biggest problem we've had, by far, was internals who couldn't be bothered
to figure out how mail works, and then suddenly their big email push
explodes and it's all MY fault.

On Mon, Sep 26, 2016 at 4:34 PM, Franck Martin via dmarc-discuss <
dmarc-discuss@dmarc.org> 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).
>
> 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.
>
> 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 <
>> dmarc-discuss@dmarc.org> 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 <
>>> 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
>>> mon

Re: [dmarc-discuss] A bit quiet?

[Terry Zink via dmarc-discuss]

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

--Terry

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

[Franck Martin via dmarc-discuss]

Couple of points...

1) https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L804
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.

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

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

4) GApps DKIM signs all the emails with .gappssmtp.com
until said customer DKIM signs with its own domain (because they want all
emails to be authenticated).



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

>
> > On Sep 27, 2016, at 12:23 PM, Terry Zink via dmarc-discuss <
> 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/
>
> 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  Pass
> 237
>
> 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
> 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 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
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
 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/

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

[Roland Turner via dmarc-discuss]

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?

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

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?

[Roland Turner via dmarc-discuss]

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

[Brandon Long via dmarc-discuss]

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   DKIM domain SPF AuthDKIM Auth
> Total
> akamai.com  kohls.com   kohls-com.20150623.gappssmtp.com
&g

Re: [dmarc-discuss] A bit quiet?

[Franck Martin via dmarc-discuss]

On Wed, Oct 26, 2016 at 8:47 AM, Payne, John  wrote:

>
>
> On Oct 26, 2016, at 11:36 AM, Franck Martin  wrote:
>
>
>
> 4) GApps DKIM signs all the emails with .gappssmtp.com
> 
> 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?
>
>
DMARC reports will contain all the valid and invalid DKIM signatures it
found in the email...
___
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?

[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 tho

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

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.

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

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.

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

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?

[Roland Turner via dmarc-discuss]

John Payne wrote:


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

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

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

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)

Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

I'll take a look.

On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
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)

Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

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  wrote:

> I'll take a look.
>
> On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
> 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)

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)