Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 19 Jul 2020 21:51:36 -0400

Ultimately,  this becomes a question of power.   Do domain owners have the right, with the help of their correspondents, to prohibit spoofing (unauthorized use) of their digital identity?Or since they are technically leaseholders, not owners, are their rights conditional?  Specificslly, do Internet insiders have the right to declare their spoofing control efforts to be based on foolish premises, both unnecessary and inconvenient, and therefore not allowed?<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Dave Crocker <[email-masked]> </div><div>Date: 7/19/20  8:53 PM  (GMT-05:00) </div><div>To: "Murray S. Kucherawy" <[email-masked]> </div><div>Cc: IETF DMARC WG <[email-masked]> </div><div>Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations </div><div>
</div>On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The track record is that people are unreliable at this.
>
>     There is quite a bit of distance between 'unreliable' and 'blindly
>     open and read absolutely everything'.
>
> Is there?

Yes.

> If there's no part of the From field that can be considered reliable, 
> then by opening even this email am I not exhibiting nearly-blind faith 
> that the indicators I can see (in this case the string "Dave Crocker 
> (gmail.com <http://gmail.com>)") have not been falsely generated?  How 
> is this message, in terms of its trustworthiness, different from any 
> other?

It's an act of curiosity, not faith.  You know that mail can be 
spoofed.  You might even suspect that I'm capable of lying. (Silly, I 
know, but...) Or that I might be wrong. (Truly a foolish thought.)  So 
the process of deciding on the validity and worth of my message is 
incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex. Except 
when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning, 
which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making 
assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler 
and more useful.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Mon, 20 Jul 2020 11:43:58 +0200

"Douglas E. Foster" <[email-masked]> writes:

> Ultimately, this becomes a question of power.  Do domain owners have
> the right, with the help of their correspondents, to prohibit spoofing
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the
case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.

> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=reject on your domains. Many mail servers will keep
using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
body, so it appears there are better venues for you.

---

From: Dotzero <[email-masked]>
Date: Mon, 20 Jul 2020 08:31:51 -0400

> would assert to make the suit successful.
DMARC clearly recognizes and documents local policy.

> one, is stopping you from doing whichever spoofing control efforts you

One might point to the fact that DMARC was just such an effort before it
was publicly published. While there was much criticism of this when it was
submitted to the IETF - "You just want us to rubber stamp this" -  there
was no such intent. It had worked well within the group of senders and
receivers implementing it through private peering that the effort was made
so that any domain of any size, both senders and receivers, could
implement it if so desired. I think the adoption rate in the wild speaks
for itself (volume of mail covered by DMARC).

> body, so it appears there are better venues for you.

You have left out one significant way of convincing receiver domains and
their admins. We used to have our CSRs (customer service) tell people who
received spoof emails (resulting in phishing, malware compromise, etc.)
from emails claiming to be from our domains that they should contact their
mail provider or email admin because the problem could have been avoided if
DMARC were being checked. We would even provide them with the details and a
form with all the information in non-technical terms. It is amazing how
quickly a provider pays attention when their customers/users are
complaining to them that the provider could have prevented the heartache
and grief but chose not to. Again, this was for domains sending
transactional mail with only a limited number (intentionally) of role and
support accounts.

While IETF is not a lawmaking body, it has an impact on the decisions of
lawmaking bodies just as the decisions of lawmaking bodies can impact the
implementation of standards. One need only look at the "great firewall of
China" as one example.

Michael Hammer

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Mon, 20 Jul 2020 14:49:54 +0200

Dotzero <[email-masked]> writes:

> One might point to the fact that DMARC was just such an effort before
> it was publicly published. While there was much criticism of this when
> it was submitted to the IETF - "You just want us to rubber stamp this"
> - there was no such intent. It had worked well within the group of
> senders and receivers implementing it through private peering that the
> effort was made so that any domain of any size, both senders and
> receivers, could implement it if so desired. I think the adoption rate
> in the wild speaks for itself (volume of mail covered by DMARC).

Volume of mail covered by DMARC seems to be rather unimpressive unless
you count p=none as covered.

> You have left out one significant way of convincing receiver domains
> and their admins. We used to have our CSRs (customer service) tell
> people who received spoof emails (resulting in phishing, malware
> compromise, etc.) from emails claiming to be from our domains that
> they should contact their mail provider or email admin because the
> problem could have been avoided if DMARC were being checked. We would
> even provide them with the details and a form with all the information
> in non-technical terms. It is amazing how quickly a provider pays
> attention when their customers/users are complaining to them that the
> provider could have prevented the heartache and grief but chose not
> to. Again, this was for domains sending transactional mail with only a
> limited number (intentionally) of role and support accounts.

You can obviously do all that, but that is not what Douglas E. Foster
advocated.

> While IETF is not a lawmaking body, it has an impact on the decisions
> of lawmaking bodies just as the decisions of lawmaking bodies can
> impact the implementation of standards.

Using the IETF as a way to get laws passed favouring ones business seems
at best underhanded.

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 20 Jul 2020 12:55:50 GMT

The court system is a poor substitute for prior deterrence or attack disruption.   DMARC seems to do both.   

The Internet limits the utility of legal remedies because of the difficulty of attribution, a problem which also DMARC helps to solve.   Litigation is also hampered by jurisdictional boundaries that create little risk of consequences for the perpetrators of crime.

This forum was proposed for upgrading DMARC from informational status to standard status.   Instead, it has become a conspiracy to demolish it.    The MLM problem will only be :"solved" if DMARC is completely abandoned, so that spoofing is once again uninhibited.   Therefore, moving from normal IETF "suggestion" mode to "enforced" mode will be necessary to achieve what MLM proponents want.   It is not what I am advocating; quite the reverse.   I am advocating for MLMs to stop spoofing and make their peace with DMARC.

DF

----------------------------------------
From: Benny Lyne Amorsen <[email-masked]>
Sent: 7/20/20 5:44 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 21 Jul 2020 10:48:10 -0500

On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) should never send as a domain they do not directly own unless it's authorized to send aligned mail as that domain.  (I say this as I have a distinguished PhD (not of CS) complaining to me that when he sends spoofed email from his Gmail account the messages go into spam because of DMARC.  Why do these ESPs even allow it in the first place, putting the domain owner's decision to adopt DMARC as the boogieman?)

The DMARC conditional rewriting logic that the MLM providers implement inhibits larger DMARC adoption because it segregates people into two camps, based solely on their domain owner's stance towards DMARC.  If a large enough group of stakeholders fall into the camp of "this domain I'm using to subscribe to lists isn't and should never be subjected to DMARC rewriting", they will push back on the domain owner's attempts to publish DMARC.

Maybe this ties back into the DMARCbis discussion about pct=0.  We use pct=0 specifically to reduce end-user confusion about MLM rewriting behavior.  Could the behavior induced by pct=0 be the default, somehow, rather than p=none?

Jesse

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Jul 2020 08:51:53 -0700

> Maybe the recommendation should be that MLMs (or any ESP, for that matter) should never send as a domain they do not directly own unless it's authorized to send aligned mail as that domain.  (I say…

This being a technical forum, we need to be careful and precise about 
terminology and history and, well, quite a bit more.

The mail is not spoofed.  Consider the definition of the word. Then 
consider that the MLM is authorized by the user with the address in the 
original From field.

Also then consider that the existing MLM behavior has existed and been 
useful for roughly 45 years.

The problem, here, is DMARC's imposing a change in email semantics.

d/

--

---

From: Dotzero <[email-masked]>
Date: Tue, 21 Jul 2020 13:58:11 -0400

On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker <[email-masked]> wrote:

> > Maybe the recommendation should be that MLMs (or any ESP, for that
> matter) should never send as a domain they do not directly own unless it's
> authorized to send aligned mail as that domain.  (I say this as I have a
> distinguished PhD (not of CS) complaining to me that when he sends spoofed
> email from his Gmail account the messages go into spam because of DMARC.
> Why do these ESPs even allow it in the first place, putting the domain
> owner's decision to adopt DMARC as the boogieman?)
>
>
> This is an interesting statement and raises a question.. Does a user have
the authority to authorize (some) use of a domain in a manner contravening
the express statement (p=reject) of the domain owner/administrator? I'm
going to have to say no.

> Slavery existed for a long time (still does in some places) and was useful
(for some) for a long time. Things change and evolve.

> The problem, here, is DMARC's imposing a change in email semantics.

If that is the problem, why did you participate in the original DMARC
effort? The issue was clear even back then.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Jul 2020 11:05:45 -0700

On 7/21/2020 10:58 AM, Dotzero wrote:
> 
> 
> On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> This is an interesting statement and raises a question.. Does a user 
> have the authority to authorize (some) use of a domain in a manner 
> contravening the express statement (p=reject) of the domain 
> owner/administrator? I'm going to have to say no.

The user is authorized to use that address.  The problem here is not 
'spoofing' but rather an internal personnel problem, with the user not 
adhering to the policies of the organization that authorized the user.

For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

> Slavery existed for a long time (still does in some places) and was 
> useful (for some) for a long time. Things change and evolve.
> 

The original DMARC effort was, in fact, to detect actual cases of 
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 21 Jul 2020 14:07:49 -0400

> The problem, here, is DMARC's imposing a change in email semantics.

Dave, there are different ways of looking at this. I've work with and 
developed MLM/MLS for as many years, and there are "mail engineering 
ethics" here to consider.

The first is Mail Tampering, which is part of 1986 US ECPA guidelines, 
   Mail Tampering was an exception, not a rule, with the MLM/MLS to 
allow for body changes. This was not a normal expectation except to 
allow a very basic overhead level with headers/footers. Absolutely no 
tampering with the context, the "gist" of the copyrighted messages, is 
never expected to be altered. It was never expected for the Author 
field to be changed unless you had a digest or something like it where 
clearly the mail was not coming from you.  In general, it would have 
been a US ECPA violation.  It was not something you often seen done, 
if ever.  The Newspaper Publisher industry is the only industry where 
legal concept of "Print To Fit" was acceptable for 100+ years.  But if 
a MLM/MLS is considered a publisher, would it be exempt?  Even then, 
the From is not changed in your letter to the editor.

Second, DMARC is imposing a new security protocol based on the premise 
the "From" is not expected to be changed. How will the MLM/MLS fit?

It can:

1) Supports the security protocol and the problem is solved. 
Exclusive domains made a published policy statement for exclusive 
signing.  The Exclusive Domains does not expect its users to be using 
their domains outside the work place. The policy is honored.

2) Unintentionally ignorant of the security protocol, does nothing. 
This is your true legacy system.

3) Intentionally ignorant of security protocol while continue to 
resign mail. This is not a legacy system if it has adapted to resign 
mail and chose to neglect and ignore the security protocol.

4) Same as #3 but also rewrites From field.

#1 and #4 will resolve the problem.  The proper protocol engineering 
fit is with #1. While #4 resolves the issue, it is perpetuating an 
undesirable design that can have serious mail engineering consequences 
simply by watering down the value of persistent 5322.From.  The #2 and 
#3 MLM/MLS will be remain as problems until they change or the user is 
made aware he can't use his exclusive domain on a public forum.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Joseph Brennan <[email-masked]>
Date: Tue, 21 Jul 2020 15:29:51 -0400

On Tue, Jul 21, 2020 at 2:08 PM Hector Santos
<hsantos=[email-masked]> wrote:

> their domains outside the work place. The policy is honored.

My understanding of DMARC's purpose was to protect transactional
messages from sources like banks, credit card issuers, online shopping
venues, and the like. It supposed that those messages should pass only
directly from the source to the end point, and that that was so
important to security that transport through any intermediary should
be rejected as possible forgery. For example my bank statements come
from a different domain than mail from a person at the bank.

What blew it away was Yahoo's implementation of DMARC on end user
personal mail. It was at first believed by many that Yahoo would have
to roll it back when their users could not contribute to mailing lists
or send mail to people who had old-school forwarding. Instead the
industry started developing ways to get around DMARC by changing RFC
822 From headers and RFC 821 MAIL commands... which pretty much un-did
the DMARC concept of authorization.

It has been demonstrated that #1 is not happening, and it's because
sheer deliverability of legitimate email is the priority.

-- 
Joseph Brennan
Lead, Email and Systems Applications

---

From: Dotzero <[email-masked]>
Date: Tue, 21 Jul 2020 15:32:08 -0400

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <[email-masked]> wrote:

> Please note that I did noy use either the word "spoof" or "spoofing".  You
wrote "MLM is authorized by the user". Someone without authority cannot
authorize. In this case the user externalized the problem, not DMARC.

> spoofing, namely unauthorized use of a domain name by outside actors.

Actually, part of the effort was to enable Sending domains to identify
their own mail that was being sent without aligned DKIM signing or from
places not authorized through SPF - in other words, not properly authorized
but legitimate, hence feedback loops.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Jul 2020 12:45:12 -0700

On 7/21/2020 12:32 PM, Dotzero wrote:
>
>
> On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Please note that I did noy use either the word "spoof" or "spoofing".  
> You wrote "MLM is authorized by the user". Someone without authority 
> cannot authorize. In this case the user externalized the problem, not 
> DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline 
purchases while running errands for me.  You take the car on a 
cross-country joyride, running the cc charges for gasoline up.  The 
stations that  charged the gas to the card did nothing wrong.  The 
problem is internal, between you and me.

The MLM's did not do any spoofing.  They acted appropriately, as they 
have for 45 years.

If the domain owner has a problem with the user's behavior, that's 
internal, between the domain owner and the user.

Using language that casts the MLM as doing something wrong is a 
fundamental misrepresentation of the situation.

> their own mail that was being sent without aligned DKIM signing or 
> from places not authorized through SPF - in other words, not properly 
> authorized but legitimate, hence feedback loops.
>
This was a point of significant confusing during the initial effort.

It is not reasonable to impose a substantial and permanent cost on the 
external internet, for an organization's inability to monitor and 
regulate behavior within the organization.

Whereas it is entirely reasonable to have a standard that facilitates 
detecting externally-generated traffic that has unauthorized use of a 
domain name.

d/

---

From: Brandon Long <[email-masked]>
Date: Tue, 21 Jul 2020 13:42:47 -0700

On Tue, Jul 21, 2020 at 12:45 PM Dave Crocker <[email-masked]> wrote:

> You wrote "MLM is authorized by the user". Someone without authority cannot
> stations that  charged the gas to the card did nothing wrong.  The problem
> is internal, between you and me.
>
> The MLM's did not do any spoofing.  They acted appropriately, as they have
> for 45 years.
>

Yahoo Groups, at least at the time I worked on it, allowed moderators to
edit the message before approval.  The full scope of that
certainly allowed the moderators to effectively spoof the poster.

That said, sure, we're not talking about spoofing.  We're talking about
message changes that prevent strict signature verification.
There is nothing in what MLM does that prevent much stronger changes than
would be considered expected by the MLM.

Stricter validation is not an uncommon addition to protocols over the last
45 years.

I'd be curious when MLMs modifying the mail going through them became a
thing, I guess I assume it wasn't 45 years ago, but I know it's irrelevant.

Brandon

---

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 21 Jul 2020 20:42:57 GMT

Your credit card scenario is one legitimate way of viewing the problem.   I have also been thinking about a credit card scenario, but coming to a different conclusion:

For many years, Bill Smith has been using the credit card of his sister-in-law, Tracy Jones.   This is an informal arrangement because Bill does not want a card of his own.    He faithfully pays Tracy for all of his charges.   No cashier has ever asked Bill for any ID other than his credit card.

Suddenly, the bank reissues all cards with photos, in an attempt to reduce card fraud.   Cashiers begin looking at the photos and will not let Bill use Tracy's credit car anymore.   Bill cries foul because he has the cardholder's permission.    Bill has the trust of Tracy, but he does not have the trust of the bank, and as a result, he does not have the trust of the retail clerk.

Should the bank remove those photos to accommodate Bill?

DF

----------------------------------------
From: Dave Crocker <[email-masked]>
Sent: 7/21/20 3:45 PM
To: Dotzero <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/21/2020 12:32 PM, Dotzero wrote:

Please note that I did noy use either the word "spoof" or "spoofing".  You wrote "MLM is authorized by the user". Someone without authority cannot authorize. In this case the user externalized the problem, not DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline purchases while running errands for me.  You take the car on a cross-country joyride, running the cc charges for gasoline up.  The stations that  charged the gas to the card did nothing wrong.  The problem is internal, between you and me.

The MLM's did not do any spoofing.  They acted appropriately, as they have for 45 years.

If the domain owner has a problem with the user's behavior, that's internal, between the domain owner and the user. 

Using language that casts the MLM as doing something wrong is a fundamental misrepresentation of the situation.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.

It is not reasonable to impose a substantial and permanent cost on the external internet, for an organization's inability to monitor and regulate behavior within the organization.

Whereas it is entirely reasonable to have a standard that facilitates detecting externally-generated traffic that has unauthorized use of a domain name.

d/

--  Dave Crocker Brandenburg InternetWorking bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Jul 2020 14:14:16 -0700

On 7/21/2020 1:42 PM, Brandon Long wrote:
> I'd be curious when MLMs modifying the mail going through them became 
> a thing, I guess I assume it wasn't 45 years ago, but I know it's 
> irrelevant.

When I said 45 years, I wasn't not kidding...

The Subject line and the To: field were modified, here:

> Date: 7 JUN 1975 1432-PDT
> Sender: FARBER at USC-ISI
> Subject: MSGGROUP# 001 TCTALK
> From: FARBER at USC-ISI
> To: MessageGroup:
> Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER>
>
>
> There is a distributed network teleconferencing facility oriented
> to networks experimentally  avilable  called  TCTALK.  It was the
> result of a thesis of Jim  Calvin  at  BBN. It can be accessed at
> the ISIA site via  <network-help>TCTALK. questions relative to it
> can be answered by Calvin  or  Geoff at SRI-AI. I would recommend
> that you try it if you have not. Improvements are being made on a
> time available basis by Calvin.
>
> The full discription of TCTALK is available via the net and is in
> essense Calvins CASE thesis. Contact CAlvin for that.
>
> Dave

---

From: Jim Fenton <[email-masked]>
Date: Wed, 22 Jul 2020 15:55:06 -0700

This:

> from a different domain than mail from a person at the bank.

and:

On 7/21/20 1:17 AM, Laura Atkins wrote:
> But I would argue that much of the marketing and justification around
> DMARC has been around end users and improving their trust in brands
> and protecting them from phishing. 
> [...]
>
> That is not how I’ve seen DMARC being sold. Most of the marketing I’ve
> seen about DMARC is all about user experience and the user being able
> to trust mail is “from who it claims to be from.” And now people are
> explicitly layering on another protocol that is all about what the
> user sees in the MUA.

and also:

> limited number (intentionally) of role and support accounts.

These get to the heart of the problem: DMARC policy was designed for
official mail that is about business transactions. If that was the way
it is actually used, we wouldn't be having this problem. But it was
oversold, and it is being used in use cases (like on domains that have
mailing list users) that were not intended. I'm not convinced that this
is a problem that has a satisfactory technical solution.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 06:42:10 -0700

> authorized but legitimate, hence feedback loops.

As I recall, this was /not/ part of the original purpose of DMARC, which 
was discussed strictly in terms of mail from bulk senders.

What you describe was,  rather, the basis for the later use, which is 
what then started causing problems for mail going through Mediators.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 06:49:51 -0700

On 7/21/2020 1:42 PM, Brandon Long wrote:
> Stricter validation is not an uncommon addition to protocols over the 
> last 45 years.

If there are examples of adding stricter validation in a way that 
essentially requires changing the semantics of the payload, in order for 
the payload to survive, I can't think of any. Not TLS, not DNSSec, not 
S/MIME or PGP.

DMARC essentially enforces a semantic on the From: field as a handling 
identifier, rather than an author identifier.

When activity that has a long history of semantic validity and a 
continued desire for operation is forced to break the denotational 
source of authoring information, in order to get the mail delivered, 
then we are in new territory.

d/

---

From: Jim Fenton <[email-masked]>
Date: Sun, 26 Jul 2020 10:10:48 -0700

On 7/26/20 6:42 AM, Dave Crocker wrote:

>> Actually, part of the effort was to enable Sending domains to
>> identify their own mail that was being sent without aligned DKIM
>> signing or from places not authorized through SPF - in other words,
>> not properly authorized but legitimate, hence feedback loops.
>
>
> As I recall, this was /not/ part of the original purpose of DMARC,
> which was discussed strictly in terms of mail from bulk senders.
>

Just identifying their own mail their own email that was sent...: Yes,
that's always been part of the original purpose of DMARC, and is the
purpose of the reporting mechanisms. Yes, the reports will contain
information on many mediators, but that's just noise in the reports. It
also contains information when, for example, the product XYZ marketing
department decided to use a new mail sending partner without telling
anyone. That's useful.

It's the policy mechanism (or more specifically its use by other than
transactional domains) that's causing the problem here.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 10:49:03 -0700

On 7/26/2020 10:10 AM, Jim Fenton wrote:
> purpose of the reporting mechanisms. Yes,
>

Looking over the original I-D posted for DMARC -- which was written 
after DMARC was already functioning, from work outside the IETF -- I'm 
unclear where this goal of "identify[ing] their own mail that was being 
sent without aligned DKIM signing" is clearly explained.(*)

Rather, note:

> 2.  Introduction
...
>     This memo defines Domain-based Message Authentication, Reporting and
>     Compliance (DMARC), a mechanism by which email operators leverage
>     existing authentication and policy advertisement technologies to
>     enable both message-stream feedback and enforcement of policies
>     against unauthenticated email.

and

> 3.1.  High-Level Requirements
>
>     At a high level, DMARC is designed to satisfy the following
>     requirements:
>
>     o  Minimize false positives.
...
>     o  Reduce the amount of successfully delivered phish.

(Caveat: None of the text I've excised explicity supports this claimed 
use.  To the extent someone thinks it or any other text in this draft 
does demonstrate that intended use, please explain how that 
interpretation is clear from the text in the draft.)

d/

(*) 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/00/?include_text=1

---

From: Dotzero <[email-masked]>
Date: Sun, 26 Jul 2020 19:44:48 -0400

On Sun, Jul 26, 2020 at 9:42 AM Dave Crocker <[email-masked]> wrote:

> What you describe was,  rather, the basis for the later use, which is what
> then started causing problems for mail going through Mediators.
>

Notice I didn't use the word "users" Many of the sending domains in the
original effort had/have a complex number of mail streams for transactional
mail from multiple domains (in some cases thousands), including through
multiple 3rd parties. This is what I was referring to.

Michael Hammer.

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 28 Jul 2020 11:37:35 -0500

On 7/22/20 5:55 PM, Jim Fenton wrote:
> mailing list users) that were not intended. 

Yes.  The cybersecurity IT community (at least, in Hi-Ed) largely don't know much about email's technical nuances.  But they they know that email phishing is a problem, and CISOs demand a solution.  They have their information sharing communities (ISACs), where email specialists are generally not included, to share knowledge and continue grasping for solutions to phishing.  Enter DMARC marketing: phishing is a spoofing problem and you're vulnerable unless you protect your domain with DMARC.  Cybersecurity IT tend to see things like DMARC as a checkbox towards compliance.  Once that box is checked (varying definitions) == job complete (email specialists are left to clean up the mess).  Since DMARC was ostensibly invented by the email community, there's not much room for local email specialists to convey that it's not a complete solution for phishing, and may not be worth implementing on domains used by end-users.  Momentum suggests that it's easier to just join the bandwagon, move forward with DMARC for every domain (to take advantage of the benefits it offers), and hope that Intermediaries can find a solution.

> I'm not convinced that this is a problem that has a satisfactory technical solution.

I think there may be technical and non-technical techniques that can be pieced together to arrive at a satisfactory solution, depending on the individual/evolving circumstances.  What's lacking is clear guidance for Intermediaries; both for people who provide software/platforms, and for those installing and configuring them.  What is the best avenue for providing guidance?

I mean, this isn't just a problem for MLMs.  Office 365 utterly fails at mailbox-level forwarding in a DMARC friendly fashion.  Their latest announcement to tenant admins suggest that they're more likely to coerce their customers' end-users users to stop forwarding via SMTP altogether.  Maybe that's the only generic solution for that type of Intermediary (whereby ARC might be an alternative solution to forwarding between trusted institutions).  Is it satisfactory?  Not to end-users who want to forward their email.  

Maybe the conclusion is that SMTP isn't even appropriate for many types of forwarding anymore, but rather pull-based OAuth solutions are more sustainable.  This solution is increasingly compatible with the mailbox hosting platforms, but isn't widely implemented by the receiving end of the equation.  Is there any point in recommending something like that as a solution as a way to move the industry in that direction?  

Or does something like this just tend to sort itself out?

Jesse