Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/21/20 4:05 PM, Brandon Long wrote:
> 
> 
> On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  > wrote:
> 
> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to 
> publish a restrictive DMARC policy and then see who comes out of the woodwork 
> sheepishly admitting that they've been ignoring us for years. 
> >
> > Normal people sending email (especially those who are working with an 
> ESP, most of which happily send email without any DMARC alignment) do not 
> comprehend the notion that they should be using a subdomain for their 
> transactional messages; even when we directly communicate this fact to them 
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
> 
> 
> One thing we've found useful in this case is controlling the organization 
> from spamming.
> 
> Which is to say that the org has a policy on approvals and what is allowed to 
> be sent marketing wise, in some parts of the world to comply with laws on 
> such topics,
> or to be sure the entire org follows the principles and someone new doesn't 
> just poison the pool for everyone else.
> 
> There are always people who route around restrictions or sometimes don't even 
> bother to look for anything, they'll just hire a third party ESP and spam 
> away.
> 
> DMARC helps in this case to reduce the success of that and force them back to 
> internal compliance, which relieves the legal burden as well as the negative 
> impacts
> on delivery and public perception.
> 
> For folks who just register a new domain name and spam anyways... yeah, well, 
> there are other consequences down the line and other anti-phishing 
> restrictions that
> kick in at least on our inbound systems..

Right.  

Moving past p=none puts somewhat of a backstop on the internal compliance 
problem, which would otherwise continue indefinitely.  I've put them into a 
state where they have to get a subdomain and learn about DMARC.  

DMARC [aggregate] reports don't tell us *who* in our organization is 
perpetuating the problem, especially if their volume is low or not visible to 
the few DMARC reporters.  At some point you need to acknowledge that you will 
never have complete visibility.

Jesse

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Brandon Long]

I think the DMARC RFC does a good job explaining why DMARC is better than
ADSP, even if the same mailing list issue is still there:
https://tools.ietf.org/html/rfc7489#appendix-A.5

And if you read the archives on the move to historic for adsp, there were
others then who objected to the reason put in the historic move as
likely as affecting the replacement .  Given the success of the
replacement, it stands to reason that the reasoning given in the move
to historic was not the full reason for the failure... and perhaps lends
credence to the thought that certain folks are more concerned about the
effects on mailing lists than the ecosystem as a whole is.

Brandon

On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton  wrote:

> On 8/15/20 3:53 PM, John Levine wrote:
>
> Not really. DKIM was deliberately designed not to be tied to any
> visible part of the message. ADSP was a poorly designed hack that was
> never implemented other than small experiments, and that I don't think
> many people understood. I got a lot of grief for making the most
> strict policy "discardable" even though that's obviously what it was.
>
>
> And even with the kinder-and-gentler term "discardable" for its most harsh
> policy option, ADSP was moved from Standards Track to Historic. From
> https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :
>
> There is, however, evidence of harm caused by incorrect configuration and by
> inappropriate use.  There have, for example, been real cases where a 
> high-value
> domain published an ADSP record of "discardable", but allowed users on their
> domain to subscribe to mailing lists.  When posts from those users were sent 
> to
> other domains that checked ADSP, those subscriber domains rejected the
> messages, resulting in forced unsubscribes from mailman (due to bounces) for
> the unsuspecting subscribers.
>
> Assurances that are provided by ADSP are generally obtained out of band in the
> real Internet, and not through ADSP.  Current deployment of ADSP is not
> recommended.
>
> Is that not exactly the same situation with DMARC, except that the policy
> in question now is "reject" rather than "discardable"? Yes, it's just a
> keyword, but it reflects the semantics of the expected action as well.
>
> -Jim
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Brandon Long]

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  wrote:

> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to
> publish a restrictive DMARC policy and then see who comes out of the
> woodwork sheepishly admitting that they've been ignoring us for years.
> >
> > Normal people sending email (especially those who are working with an
> ESP, most of which happily send email without any DMARC alignment) do not
> comprehend the notion that they should be using a subdomain for their
> transactional messages; even when we directly communicate this fact to them
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
>

One thing we've found useful in this case is controlling the organization
from spamming.

Which is to say that the org has a policy on approvals and what is allowed
to be sent marketing wise, in some parts of the world to comply with laws
on such topics,
or to be sure the entire org follows the principles and someone new doesn't
just poison the pool for everyone else.

There are always people who route around restrictions or sometimes don't
even bother to look for anything, they'll just hire a third party ESP and
spam away.

DMARC helps in this case to reduce the success of that and force them back
to internal compliance, which relieves the legal burden as well as the
negative impacts
on delivery and public perception.

For folks who just register a new domain name and spam anyways... yeah,
well, there are other consequences down the line and other anti-phishing
restrictions that
kick in at least on our inbound systems..

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC

[Todd Herr]

https://trac.ietf.org/trac/dmarc/ticket/66

When this issue was first raised on the list back in June, it seemed that
consensus might've landed on the idea that this should be written up in a
separate BCP, rather than be part of the DMARC bis effort itself. I'm
concerned, however, that there might not be enough there there to warrant a
separate BCP, and to that end I've taken a stab at modifying the base DMARC
document, specifically Section 8, Implementation, as follows:

-
8 .  Implementations

The characteristics of a DMARC implementation will vary for the different
roles in the messaging infrastructure.
8.1 Domain Owner Implementations

Section 6.5  describes
many of the provisions for implementing the DMARC mechanism as a Domain
Owner. This section will clarify those needed for minimal and full
implementations.
8.1.1 Minimal Domain Owner Implementation

The only action required for minimal implementation of the DMARC mechanism
by a Domain Owner is the creation of the DMARC policy record in DNS.
8.1.2 Full Domain Owner Implementation

Full implementation of the DMARC mechanism by a Domain Owner requires all
of the following characteristics:

   -

   Creation of the DMARC policy record in DNS which meets these criteria:
   -

  The policy record MUST express a Requested Mail Receiver policy of
  “quarantine” or “reject” for the Organizational Domain and all sub-domains
  -

  The Requested Mail Receiver policy MUST apply to a percentage of mail
  not less than 100
  -

   Establishment of an address to receive aggregate reports at least daily;
   other than in exceptional circumstances such as resource exhaustion, the
   address must support receiving reports up to at least ten megabytes in size.
   -

   Deployment of authentication technologies to ensure Identifier Alignment

8.2 Mail Receiver Implementations

This section will describe minimal and full implementations of the DMARC
mechanism for Mail Receivers.
8.2.1 Minimal Mail Receiver Implementation

Minimal implementation of the DMARC mechanism by a Mail Receiver means
fully implementing the provisions of Section 6.6

8.2.2 Full Mail Receiver Implementation

Full implementation of the DMARC mechanism by a Mail Receiver is defined by
the following characteristics:

   -

   Fully implementing the provisions of Section 6.6
   
   -

   Validation of any ARC header sets found in the message
   -

   Enforcement of discovered policies in a manner that is consistent
with Section
   6.7 
   -

   Send aggregate reports at least daily using “mailto” URIs; such
   aggregate reports MUST be no larger than ten megabytes in size.


8.3 Report Receiver Implementations

The following implementations are defined for operators that receive
reports about messages related to another operator. Implementations for
Domain Owners that receive reports about their own messages are described
in Section 8.1.
8.3.1 Full Report Receiver Implementation

Full implementation of the DMARC mechanism by a Report Receiver means
establishment of an address to receive aggregate reports at least daily;
other than in exceptional circumstances such as resource exhaustion, the
address must support receiving reports up to at least ten megabytes in size..
8.4 Intermediary Implementations

The term “Intermediary” is meant to encompass Mediators, Relays, and
Gateways as defined in [EMAIL-ARCH
]. This section will
describe minimal and full implementations for Intermediaries.
8.4.1 Minimal Intermediary Implementation

Minimal implementation of the DMARC mechanism by an Intermediary means
fully implementing the provisions of Section 6.6

8.4.2 Full Intermediary Implementation

Full implementation of the DMARC mechanism by an Intermediary is defined by
the following characteristics:

   -

   Fully implementing the provisions of Section 6.6
   
   -

   Attaching a complete and valid ARC Set of headers to the message
   -

   Enforcement of discovered policies in a manner that is consistent
with Section
   6.7 
   -

   Send aggregate reports at least daily using “mailto” URIs; such
   aggregate reports MUST be no larger than ten megabytes in size

-
Thank you for reading, and I look forward to any and all comments and
discussion.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 8/17/20 3:52 PM, Jesse Thompson wrote:
> With a complex organization the only way to get people to change is to 
> publish a restrictive DMARC policy and then see who comes out of the woodwork 
> sheepishly admitting that they've been ignoring us for years.  
>
> Normal people sending email (especially those who are working with an ESP, 
> most of which happily send email without any DMARC alignment) do not 
> comprehend the notion that they should be using a subdomain for their 
> transactional messages; even when we directly communicate this fact to them 
> repeatedly.  They just don't understand the nuances of email.
>
I thought the DMARC reporting mechanism was there to allow such
organizations to detect those behaviors and get them corrected without
actually causing the damage of a restrictive policy.

-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Jim Fenton]

On 8/15/20 3:53 PM, John Levine wrote:
> Not really. DKIM was deliberately designed not to be tied to any
> visible part of the message. ADSP was a poorly designed hack that was
> never implemented other than small experiments, and that I don't think
> many people understood. I got a lot of grief for making the most
> strict policy "discardable" even though that's obviously what it was.
>
And even with the kinder-and-gentler term "discardable" for its most
harsh policy option, ADSP was moved from Standards Track to Historic.
From
https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :

> There is, however, evidence of harm caused by incorrect configuration and by
> inappropriate use.  There have, for example, been real cases where a 
> high-value
> domain published an ADSP record of "discardable", but allowed users on their
> domain to subscribe to mailing lists.  When posts from those users were sent 
> to
> other domains that checked ADSP, those subscriber domains rejected the
> messages, resulting in forced unsubscribes from mailman (due to bounces) for
> the unsuspecting subscribers.
>
> Assurances that are provided by ADSP are generally obtained out of band in the
> real Internet, and not through ADSP.  Current deployment of ADSP is not
> recommended.
Is that not exactly the same situation with DMARC, except that the
policy in question now is "reject" rather than "discardable"? Yes, it's
just a keyword, but it reflects the semantics of the expected action as
well.

-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Instead of immediately deciding which ideas can and cannot work, I suggest that 
we create an extension mechanism for DMARC and then let the market decide.  
Perhaps someone will find traction for an idea that is useful to a subset of 
users even if it is not useful for every sender-receiver pair.

The extension mechanism could be as simple as an "add-ons=Y" clause in the 
DMARC record.

If a receiver has implemented ANY add-on method, this flag tells him to check 
all of the options that he supports.   Most likely this will require one or 
more additional DNS lookups to determine which add-on technique is supported by 
the sender.The result of those lookups will determine if the sender and the 
receiver support any of the same techniques.   When there is a match on 
supported techniques, the logic for that technique is invoked.But when the 
flag is absent, no resources are wasted on checking add-on methods that can 
only apply to a subset of all messages.

This approach separates the DMARC spec, which focuses on two specific 
authentication strategies, from add-on methods that invoke alternate 
authentication strategies, so that the DMARC specification can move forward.

It leaves room for all of the ideas mentioned so far, and for those that have 
not yet been suggested.   It also leaves room for a good-but-neglected idea to 
gain traction based on future events.

The details of those other implementations can be determined by private 
agreement or by RFC.

DF


From: Alessandro Vesely 
Sent: 8/21/20 4:58 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson  wrote:
>> On 8/20/20 4:00 PM, bl...@google.com wrote:
>>> Neither atps or spf include are really designed for large scale usage
>>
>> That's my conclusion, as well. I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch, even if I would
>> otherwise trust them (e.g. their purported ARC results).
>>
>> I *do* want to authorize our *own* MLM(s) to use our own domains for
>> *internal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?

Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a 
rhswl zone which can be outsourced.

>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now. From: rewriting is not 
going to stop on the next day. We must tune aggregate reports so that MLMs can 
tell if it's still necessary. It may take decades... still better than ∞.

>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of 
operators. And, in case, I'd adopt John's broad brush: If I went so far as to 
whitelist the MLM, why should I take the burden to scrutinize the way it 
applied policies? It seems more sound to allow my recipients to see the same 
messages as every other subscriber.

> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.

That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior. AIUI, the sender recognizes that one of 
the recipients is an allowed mailing list, and adds that tag to that copy of 
the message. It looks less outsourceable than an external whitelist.

Let me call weak signature this concept. As it is very similar to 
dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as 
weak signatures can all be adopted concurrently.

> I haven't seen enough favorable response to justify working on a detailed
> submission to the group. I'm not an IETF standards wonk.

I'd support weak signatures, in either embodiment. I don't think it needs to be 
linked to the Sender: field.

Best
Ale
--

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson  wrote:
>> On 8/20/20 4:00 PM, bl...@google.com wrote:
>>> Neither atps or spf include are really designed for large scale usage
>>
>> That's my conclusion, as well.  I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch, even if I would
>> otherwise trust them (e.g. their purported ARC results).
>>
>> I *do* want to authorize our *own* MLM(s) to use our own domains for
>> *internal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?


Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a 
rhswl zone which can be outsourced.


>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now.  From: rewriting is 
not going to stop on the next day.  We must tune aggregate reports so that MLMs 
can tell if it's still necessary.  It may take decades...  still better than ∞.


>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of 
operators.  And, in case, I'd adopt John's broad brush:  If I went so far as to 
whitelist the MLM, why should I take the burden to scrutinize the way it 
applied policies?  It seems more sound to allow my recipients to see the same 
messages as every other subscriber.


> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.


That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior.  AIUI, the sender recognizes that one of 
the recipients is an allowed mailing list, and adds that tag to that copy of 
the message.  It looks less outsourceable than an external whitelist.

Let me call weak signature this concept.  As it is very similar to 
dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as 
weak signatures can all be adopted concurrently.


> I haven't seen enough favorable response to justify working on a detailed
> submission to the group. I'm not an IETF standards wonk.


I'd support weak signatures, in either embodiment.  I don't think it needs to 
be linked to the Sender: field.


Best
Ale
-- 


























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc