Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>It would be worthwhile for everyone in the group to read through
>https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
>as they analyze implementation flaws that allow attacks against DMARC in
>existing implementations.

They found some interesting and unlikely implementation bugs but I
didn't see anything that looked like a design problem.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton  wrote:

> On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
>
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:
>
>>
>>  Is this an interoperability problem that is solved by IETF standards or
>> is it an organizational problem that requires an organizational solution?
>> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>>
>
> I think that it might be out of the DMARC-WG's charter, but such an RFC
> would be eminently quotable along with 2549 and other such work.
>
> We already have a number of such RFCs:
>
>
> https://datatracker.ietf.org/doc/search?name=considered+harmful==on=on=group=
>
> -Jim
>
Maybe we should write _Implementing Email Security Without Understanding
What You Are Doing Is Considered Harmful_ - that could fall within our
remit.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Fri, Aug 14, 2020 at 11:15 AM Dotzero  wrote:

>
>
> On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz 
> wrote:
>
>>
>>
>> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) 
>> wrote:
>>
>>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>>>

 I've been involved in setting up DMARC with a policy of p=reject for
 somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
 in getting buy-in across the organization that it is a worthwhile effort,
 getting control of your organization's mail flows and ensuring policies and
 procedures are communicated and followed. For complex environments there
 may need to be some automation required for creating and maintaining
 private/public key pairs and DNS records but that is much more
 straightforward than the aforementioned heavy lifting.

>>>
>>> Also note that said "heavy lifting" is not a one time expenditure of
>>> effort. Having hoisted the weight bar above your head, it requires
>>> organizational will and ongoing knowledge to stick to the higher bar week
>>> in and week out. Entropy is never your friend in an organizational security
>>> context. Neither are acquisitions :-)
>>>
>>> Yes, and that's why I use DMARC mostly as a tool for reporting. My
>>> clients are typically small businesses who are worried about selling
>>> widgets not about email so even if I help them set up email perfectly, they
>>> could make a change a year from now without updating their SPF record or
>>> deploying DKIM. I just changed my policy to reject (just for fun) assuming
>>> this email will get through because of DMARC's OR logic.
>>>
>>
> Which brings us back to the question of organizational implementation
> issues vs  interoperability issues. Can a technical standards body solve
> the problem of organizations shooting themselves in the foot because they
> are worried about selling widgits and not about email? Why do I have a
> feeling they start caring about email when it no longer works for them?
> They have created a self induced personal interoperability issue. If they
> changed their MX to use a random port other than port 25 to receive SMTP
> connections would you suggest that the RFC should be written to
> accommodate that?
>
> No, it probably can't solve that sort of problem and maybe there's not
really a problem. DMARC does work as advertised, though adoption's low.

 Under 50% of companies have any DMARC record. Of those who deploy DMARC,
about ~2% have p=quarantine and ~5% p=reject, though some industries such
as finance it looks like it's closer to 15% p=reject. I'm sure these
numbers aren't perfect but what you have likely isn't radically different.

Why is adoption low? Is that a big problem? Why so few aggressive policies?
Is that a big problem?

Can a standards body do anything about any of it? Should they? I have no
idea.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security

[Jim Fenton]

On 8/14/20 12:16 PM, Dotzero wrote:
>
>
> On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b)  > wrote:
>
> It would be worthwhile for everyone in the group to read
> through 
> https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
> as they analyze implementation flaws that allow attacks against
> DMARC in existing implementations.
>
> The paper should be publicly accessible now since the conference
> is in progress. There's also a slide deck with a summarized set of
> results from their study.
>
> --Kurt
>
>
> Did a first look at the slide deck. Some interesting stuff. Some is
> clearly interoperability and should be considered by the working
> group. Some is DMARC/DKIM/SPF implementation issues and some like the
> display name is intractable. As someone suggested to me today, it
> would be incredibly useful to disambiguate the Display Name from the
> From email address for anti-abuse purposes but my feeling is a) that
> is something for the email core group (not this group) and b) there
> would be incredible pushback against such an effort.
>
Agreed. I watched the presentation this morning and he points out a
number of likely implementation issues that are worth evaluating.
Haven't had a chance to read the paper in detail yet.

But he doesn't seem to have considered primarily cases where the From
email address is presented to and evaluated by the user. He largely
ignores MUAs that show only the friendly name and research showing that
even if displayed, it is frequently ignored.

-Jim

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Jim Fenton]

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero  > wrote:
>
>
>  Is this an interoperability problem that is solved by IETF
> standards or is it an organizational problem that requires an
> organizational solution? Perhaps we need to generate an RFC
> entitled "Don't Do Stupid Things". ;-)
>
>
> I think that it might be out of the DMARC-WG's charter, but such an
> RFC would be eminently quotable along with 2549 and other such work.

We already have a number of such RFCs:

https://datatracker.ietf.org/doc/search?name=considered+harmful==on=on=group=

-Jim

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

Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security

[Dotzero]

On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b)  wrote:

> It would be worthwhile for everyone in the group to read through
> https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
> as they analyze implementation flaws that allow attacks against DMARC in
> existing implementations.
>
> The paper should be publicly accessible now since the conference is in
> progress. There's also a slide deck with a summarized set of results from
> their study.
>
> --Kurt
>

Did a first look at the slide deck. Some interesting stuff. Some is clearly
interoperability and should be considered by the working group. Some is
DMARC/DKIM/SPF implementation issues and some like the display name is
intractable. As someone suggested to me today, it would be incredibly
useful to disambiguate the Display Name from the From email address for
anti-abuse purposes but my feeling is a) that is something for the email
core group (not this group) and b) there would be incredible pushback
against such an effort.

Michael Hammer
___
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/10/20 12:04 PM, Tim Wicinski wrote:
>
> During IETF 108, the chairs realized that there was interest in Dave's
> RFC5322.Sender draft.  
>
> This starts a Call for Adoption for draft-crocker-dmarc-sender

I do not support adoption of this draft as a working group document for
different reasons than I have seen expressed by others on the list.

If the Sender header field is to be used by DMARC in the manner
described in this draft, it should be an integral part of the DMARCbis
specification rather than a separate extension to it. In other words,
this should be an issue on the DMARC WG issue tracker rather than a
working group draft (and presumably eventual RFC). There are enough
different combinations of originators and receivers that might use
Sender (which the chart in Section 2 begins to describe) that we don't
need the ongoing ambiguity of whether the receiver does or does not
implement this as an extension.

I have other comments on the proposal, but will stop here as they are
not directly germane to the question of adoption.

-Jim

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:

>
>  Is this an interoperability problem that is solved by IETF standards or
> is it an organizational problem that requires an organizational solution?
> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>

I think that it might be out of the DMARC-WG's charter, but such an RFC
would be eminently quotable along with 2549 and other such work.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz 
wrote:

>
>
> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) 
> wrote:
>
>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>>
>>>
>>> I've been involved in setting up DMARC with a policy of p=reject for
>>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>>> in getting buy-in across the organization that it is a worthwhile effort,
>>> getting control of your organization's mail flows and ensuring policies and
>>> procedures are communicated and followed. For complex environments there
>>> may need to be some automation required for creating and maintaining
>>> private/public key pairs and DNS records but that is much more
>>> straightforward than the aforementioned heavy lifting.
>>>
>>
>> Also note that said "heavy lifting" is not a one time expenditure of
>> effort. Having hoisted the weight bar above your head, it requires
>> organizational will and ongoing knowledge to stick to the higher bar week
>> in and week out. Entropy is never your friend in an organizational security
>> context. Neither are acquisitions :-)
>>
>> Yes, and that's why I use DMARC mostly as a tool for reporting. My
>> clients are typically small businesses who are worried about selling
>> widgets not about email so even if I help them set up email perfectly, they
>> could make a change a year from now without updating their SPF record or
>> deploying DKIM. I just changed my policy to reject (just for fun) assuming
>> this email will get through because of DMARC's OR logic.
>>
>
Which brings us back to the question of organizational implementation
issues vs  interoperability issues. Can a technical standards body solve
the problem of organizations shooting themselves in the foot because they
are worried about selling widgits and not about email? Why do I have a
feeling they start caring about email when it no longer works for them?
They have created a self induced personal interoperability issue. If they
changed their MX to use a random port other than port 25 to receive SMTP
connections would you suggest that the RFC should be written to
accommodate that?

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b)  wrote:

> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>
>>
>> I've been involved in setting up DMARC with a policy of p=reject for
>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>> in getting buy-in across the organization that it is a worthwhile effort,
>> getting control of your organization's mail flows and ensuring policies and
>> procedures are communicated and followed. For complex environments there
>> may need to be some automation required for creating and maintaining
>> private/public key pairs and DNS records but that is much more
>> straightforward than the aforementioned heavy lifting.
>>
>
> Also note that said "heavy lifting" is not a one time expenditure of
> effort. Having hoisted the weight bar above your head, it requires
> organizational will and ongoing knowledge to stick to the higher bar week
> in and week out. Entropy is never your friend in an organizational security
> context. Neither are acquisitions :-)
>
> Yes, and that's why I use DMARC mostly as a tool for reporting. My clients
> are typically small businesses who are worried about selling widgets not
> about email so even if I help them set up email perfectly, they could make
> a change a year from now without updating their SPF record or deploying
> DKIM. I just changed my policy to reject (just for fun) assuming this email
> will get through because of DMARC's OR logic.
>
___
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

[Dotzero]

On Fri, Aug 14, 2020 at 12:42 PM John Levine  wrote:

> In article  g...@mail.gmail.com> you write:
> >policy of p=reject. Domains should not be able to externalize their
> >internal problems to others.
>
> Isn't that exactly the mailing list problem?
>

No, that is the domains publishing a policy externally but not telling
their users "Don't do that" problem.

>
> >> Only if you believe that the domain on the From: line is automatically
> >> more credible than the one on the Sender: line. The whole third party
> >> problem is that the people sending their mail through lists or
> >> whatever are in fact doing so legitimately, but for various reasons
> >> their organizations' DMARC policies lie and say they aren't.
> >>
> >
> >I think you are misusing the term "credible". Domains which are publishing
> >p=reject policies are making an assertion regarding mail purporting to be
> >authorized by their domain. It is not an assertion that their mail is
> >"good" or should be delivered to a recipient ...
>
> No, it's an assertion that mail that's unaligned is unauthorized, and
> a request to reject it. For mail that their users send through mailing
> lists, that assertion is false and the request clearly not what the
> organization and its users want. This is what I conclude from the
> number of unhappy people to whom I have had to explain that their mail
> is disappearing because their employer told recipient systems to do
> so.
>

 "clearly not what the organization and its users want."

Who am I going to believe, the organization and it's published policy or
you?

>
> > This is why I made the point above that lists should respect DMARC
> >policy and not accept submissions from domains with DMARC p=reject
> >policies.
>
> Lists have been around a lot longer than DMARC has. Perhaps you meant
> to say that domains whose users participate in mailing lists should
> not publish restrictive DMARC policies. If they don't want their users
> to send mail to lists, they should tell their users not to send mail
> to lists.
>

I meant what I wrote. Domains who actively want their users to participate
in mailing lists or even passively accept that their users participate in
mailing lists shouldn't publish p=reject for the domain their users are
sending from or should take steps to migrate the users to another
domain/subdomain, etc. Conversely, if a domain IS publishing p=reject then
yes, they should be taking steps internally but I also believe others
should consider that domain's published policy as intentional and act
accordingly. I've never heard of a DMARC policy getting published due to
inaction. Someone with administrative rights actively published that policy.

>
> There are lots of organizations that actively want their employees to
> participate in the IETF, to the extent that they give them paid time
> for IETF activities, yet publish p=reject policies to cripple that
> participation. I wish they would make up their minds.
>

Me too.

Michael Hammer
___
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

[John Levine]

In article 
 you 
write:
>policy of p=reject. Domains should not be able to externalize their
>internal problems to others.

Isn't that exactly the mailing list problem?

>> Only if you believe that the domain on the From: line is automatically
>> more credible than the one on the Sender: line. The whole third party
>> problem is that the people sending their mail through lists or
>> whatever are in fact doing so legitimately, but for various reasons
>> their organizations' DMARC policies lie and say they aren't.
>>
>
>I think you are misusing the term "credible". Domains which are publishing
>p=reject policies are making an assertion regarding mail purporting to be
>authorized by their domain. It is not an assertion that their mail is
>"good" or should be delivered to a recipient ...

No, it's an assertion that mail that's unaligned is unauthorized, and
a request to reject it. For mail that their users send through mailing
lists, that assertion is false and the request clearly not what the
organization and its users want. This is what I conclude from the
number of unhappy people to whom I have had to explain that their mail
is disappearing because their employer told recipient systems to do
so.

> This is why I made the point above that lists should respect DMARC
>policy and not accept submissions from domains with DMARC p=reject
>policies. 

Lists have been around a lot longer than DMARC has. Perhaps you meant
to say that domains whose users participate in mailing lists should
not publish restrictive DMARC policies. If they don't want their users
to send mail to lists, they should tell their users not to send mail
to lists.

There are lots of organizations that actively want their employees to
participate in the IETF, to the extent that they give them paid time
for IETF activities, yet publish p=reject policies to cripple that
participation. I wish they would make up their minds.

R's,
John

___
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

[Laura Atkins]

> On 14 Aug 2020, at 17:18, Dotzero  wrote:
> 
> 
> 
> On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins  > wrote:
> 
> 
>> On 14 Aug 2020, at 09:27, Dotzero > > wrote:
>> 
>>  Now I have come to the conclusion that they should reject list submissions 
>> from accounts at domains which publish a DMARC policy of p=reject. Domains 
>> should not be able to externalize their internal problems to others.
> 
> This effectively cuts off users at multiple ISPs from ever participating in 
> mailing lists. Which is exactly what we’re trying to fix with this proposal. 
> 
> Does the proposal actually fix the problem? Does the proposal actually fix 
> the problem without creating other problems? After reading an re-reading 
> Dave's draft, my conclusion is that the answer is no to both questions. 

And that’s why we’re having this discussion, to determine if it does or not. 

> 
> Just because a user has an address at a consumer mailbox provider that 
> publishes p=reject does not make them a second class citizen banned from 
> participating in any mailing list. 
> 
> You are conflating the provision of Internet connectivity  with the provision 
> of email services. That ship sailed a long time ago. There are a number of 
> ISPs which no longer provide email accounts/port 25 services. If a user with 
> an account at one of those domains wanted to use their login as an email 
> address are you suggesting that others should send responses to that "email 
> address" even though no MX is available for that account and mail will never 
> reach that user?

I was speaking of companies like Yahoo and AOL, companies that provide email 
services and not internet connectivity. They publish p=reject and any solution 
that is ‘well, they just don’t get to use mailing lists” seems to create a 
problem. At one point, gmail announced they will be publishing p=reject, which 
meant users of 2 of the 3 major consumer mailbox providers would be prohibited 
from joining mailing lists. 

> It is clear to me that a domain owner/admin has the right to determine how 
> that domain will or will not be used. The individual is not banned from ever 
> participating in a mailing list. They simply can't use an account from that 
> particular domain. There are plenty of other places they can get an email 
> account from. They also have the opportunity to tell their existing provider 
> they are unhappy with policy. Providers can and do change their policies. For 
> the longest time, the address block associated with Amazon Simple Mail 
> Service was a swamp of badness. Legitimate users and organizations started 
> deciding to not use other Amazon AWS services as a result of their mail being 
> blocked. Amazon got religion and started cleaning up their mess. So yes, even 
> large players can respond to market and community pressures.
> 
> I'm not the person who initially suggested MLMs reject users/email from 
> domains that publish p=reject. That was John Levine. Perhaps he was being 
> sarcastic, perhaps not. It is certainly a forcing mechanism. And that may 
> just be what is needed for domains to think carefully about how they 
> implement DMARC.

That is not how the quoting came through on my client. I was attempting to be 
succinct and trim the message. Here’s the full email I was responding to. In my 
client you appear to be the one saying MLMs should reject anyone using a domain 
with p=reject. If the quoting was incorrect, I apologize for the mistake. 

> On 14 Aug 2020, at 09:27, Dotzero  wrote:
> 
> 
> 
> On Thu, Aug 13, 2020 at 10:08 PM John Levine  > wrote:
> In article 
>  > you write:
> >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
> >from a similar problem as PRA in the SenderId draft. There is no way to
> >validate that the specific intermediary is authorized by the (From) domain
> >originating the email through it's generic signalling that it
> >authorizes intermediaries. This means that any source can emit a message
> >claiming to be a legitimate intermediary just as any source could game PR
> >to gain a neutral result.
> 
> That's a feature, not a bug. I want recipients to be able to assess
> the mail my lists send on its own merits.
> 
> And recipient domains do just that using local policy override. DMARC policy 
> is at best a request to the Validator/Receiving Domain. If a 
> Validator/Receiving Domain chooses to honor the published DMARC policy for a 
> domain such as p=reject, then they are in fact assessing the mail your lists 
> send based on the merits as they see them. The same goes if they decide to 
> not honor that published DMARC policy and accept mail from your lists. 
> Earlier in my DMARC journey I felt that MLMs should adjust and send list mail 
> as themselves. Now I have come to the conclusion that they should reject list 
> submissions from accounts at 

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Fri, Aug 14, 2020 at 11:13 AM Kurt Andersen (b)  wrote:

> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>
>>
>> I've been involved in setting up DMARC with a policy of p=reject for
>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>> in getting buy-in across the organization that it is a worthwhile effort,
>> getting control of your organization's mail flows and ensuring policies and
>> procedures are communicated and followed. For complex environments there
>> may need to be some automation required for creating and maintaining
>> private/public key pairs and DNS records but that is much more
>> straightforward than the aforementioned heavy lifting.
>>
>
> Also note that said "heavy lifting" is not a one time expenditure of
> effort. Having hoisted the weight bar above your head, it requires
> organizational will and ongoing knowledge to stick to the higher bar week
> in and week out. Entropy is never your friend in an organizational security
> context. Neither are acquisitions :-)
>
> --Kurt
>

I absolutely agree with you, Kurt. On the other hand this is true for many
things. I almost want to respond with "What's your point?" (sarcastically).
Is this an interoperability problem that is solved by IETF standards or is
it an organizational problem that requires an organizational solution?
Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)

Michael Hammer
___
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

[Dotzero]

On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins 
wrote:

>
>
> On 14 Aug 2020, at 09:27, Dotzero  wrote:
>
>  Now I have come to the conclusion that they should reject list
> submissions from accounts at domains which publish a DMARC policy of
> p=reject. Domains should not be able to externalize their internal problems
> to others.
>
>
> This effectively cuts off users at multiple ISPs from ever participating
> in mailing lists. Which is exactly what we’re trying to fix with this
> proposal.
>

Does the proposal actually fix the problem? Does the proposal actually fix
the problem without creating other problems? After reading an re-reading
Dave's draft, my conclusion is that the answer is no to both questions.



>
> Just because a user has an address at a consumer mailbox provider that
> publishes p=reject does not make them a second class citizen banned from
> participating in any mailing list.
>

You are conflating the provision of Internet connectivity  with the
provision of email services. That ship sailed a long time ago. There are a
number of ISPs which no longer provide email accounts/port 25 services. If
a user with an account at one of those domains wanted to use their login as
an email address are you suggesting that others should send responses to
that "email address" even though no MX is available for that account and
mail will never reach that user? It is clear to me that a domain
owner/admin has the right to determine how that domain will or will not be
used. The individual is not banned from ever participating in a mailing
list. They simply can't use an account from that particular domain. There
are plenty of other places they can get an email account from. They also
have the opportunity to tell their existing provider they are unhappy with
policy. Providers can and do change their policies. For the longest time,
the address block associated with Amazon Simple Mail Service was a swamp of
badness. Legitimate users and organizations started deciding to not use
other Amazon AWS services as a result of their mail being blocked. Amazon
got religion and started cleaning up their mess. So yes, even large players
can respond to market and community pressures.

I'm not the person who initially suggested MLMs reject users/email from
domains that publish p=reject. That was John Levine. Perhaps he was being
sarcastic, perhaps not. It is certainly a forcing mechanism. And that may
just be what is needed for domains to think carefully about how they
implement DMARC.

Michael Hammer

>
> laura
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> ___
> 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] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On 2020-08-14 4:12 p.m., Dotzero wrote:

On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely  wrote:

On 2020-08-10 7:24 p.m., John Levine wrote:

In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write:

Even an external reputation system requires recipient
participation.   That is why I suggested both a
send3="parameters" clause to indicate sender support for
third-party authorization and a verify3="parameters" clause to
indicate recipient support for third-party authentication. When
both are visible to the non-domain message source, that source
can have confidence that the message will be handled as
authorized.


We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.



We can either try and understand what was wrong in those schemes, or
abandon authorization schemes forever.

Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent
success.

PGP, GPG, and even personal CA certificates never became really
popular, so we could have concluded that digital signature aren't
worth considering for anti-spoof protocols.  Yet, someone thought
about DKIM...



There is a little bit of history behind the impetus for SPF and DKIM. In
2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on
Email Authentication and SPAM. It also let it be known that if the private
sector didn't come up with solutions it was willing to move forward with
regulation. This helped drive activity for SPF, the merger of DK and IIM
to create DKIM and Microsoft's push for SenderID. Private sector folks did
not want to risk what government regulation might look like. At that time
there were also folks pushing for PGP, GPG, Personal Certificate and
S/MIME as  paths forward. Even with that, it took a while for industry
efforts to gain some sense of clarity. Notice that the general path forward
was basically domain based and not individual user/client based. There was
a debate within the DKIM effort regarding i= vs d= to the extent that at
one industry event people were walking around with little stickers on their
badges to indicate which they supported. I believe that was courtesy of
Dave Crocker.



Thanks for that, I put a reference to your post on the wikipedia[*] 
(the original link to the FTC event expired sometimes in 2012).



Best
Ale
--

[*] https://en.wikipedia.org/wiki/Email_authentication#Rationale




































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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:

>
> I've been involved in setting up DMARC with a policy of p=reject for
> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
> in getting buy-in across the organization that it is a worthwhile effort,
> getting control of your organization's mail flows and ensuring policies and
> procedures are communicated and followed. For complex environments there
> may need to be some automation required for creating and maintaining
> private/public key pairs and DNS records but that is much more
> straightforward than the aforementioned heavy lifting.
>

Also note that said "heavy lifting" is not a one time expenditure of
effort. Having hoisted the weight bar above your head, it requires
organizational will and ongoing knowledge to stick to the higher bar week
in and week out. Entropy is never your friend in an organizational security
context. Neither are acquisitions :-)

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

[dmarc-ietf] Good paper analyzing inter-component flaws in email security

[Kurt Andersen (b)]

It would be worthwhile for everyone in the group to read through
https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
as they analyze implementation flaws that allow attacks against DMARC in
existing implementations.

The paper should be publicly accessible now since the conference is in
progress. There's also a slide deck with a summarized set of results from
their study.

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

[Laura Atkins]

> On 14 Aug 2020, at 09:27, Dotzero  wrote:
> 
>  Now I have come to the conclusion that they should reject list submissions 
> from accounts at domains which publish a DMARC policy of p=reject. Domains 
> should not be able to externalize their internal problems to others.

This effectively cuts off users at multiple ISPs from ever participating in 
mailing lists. Which is exactly what we’re trying to fix with this proposal. 

Just because a user has an address at a consumer mailbox provider that 
publishes p=reject does not make them a second class citizen banned from 
participating in any mailing list. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz 
wrote:

>
>
> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> If I followed Neil’s discussion of MajorCRM:
>>
>>
>>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF policy or
>> delegates a DKIM scope to them and they use it.
>>
>
> And client's domain is only in the Mail from uses the vendor's domain (
> somevendorxyz123.foo.com). It passes SPF in but it's not in alignment
> with the organizational domain name (example.com) that the client uses in
> the header from.
>
> This is super common and, as a practical matter, it works... except if you
> ever want to use DMARC's policy for anything other than reporting. The vast
> majority of people think that if you add include:bar.com (whatever vendor
> KB says) in the SPF that they are good to go.
>

"Vast majority of people"? Can you please provide data that supports this
assertion?


> So many businesses have several entries in their organizational domain's
> SPF record yet the RFC5321.from is the vendor's domain. The client
> sometimes goes over the 10 DNS lookups with includes that aren't doing
> anything for them. I'm not sure that 10 DNS lookup limit. There are some
> prominent services of various sorts for which the single include will do
> over 10 DNS lookups and hat's just one of many includes a client might have
> (I know this isn't about SPF per se).
>
> Yes, I can usually quickly set up a subdomain to use instead of
> somevendorxyz123.foo.com but this isn't always possible or it requires
> pushing to get it done.
>

So you are saying "Email authentication is hard. Let's go shopping"?

>
> This makes DMARC a sketchy tool to use for any policy above none which is
> in and of itself useful.
>

Not at all. It simply means that the people/organizations involved have
some problems. Please consider the following joke:

How many Psychiatrists does it take to change a light bulb? Only one but
the bulb has to want to change.

I've been involved in setting up DMARC with a policy of p=reject for
somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
in getting buy-in across the organization that it is a worthwhile effort,
getting control of your organization's mail flows and ensuring policies and
procedures are communicated and followed. For complex environments there
may need to be some automation required for creating and maintaining
private/public key pairs and DNS records but that is much more
straightforward than the aforementioned heavy lifting.

Michael Hammer.

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

[Dotzero]

On Fri, Aug 14, 2020 at 7:09 AM Douglas E. Foster  wrote:

> Michael Hammer / Dotzero writes:
>
> "Earlier in my DMARC journey I felt that MLMs should adjust and send list
> mail as themselves. Now I have come to the conclusion that they should
> reject list submissions from accounts at domains which publish a DMARC
> policy of p=reject. Domains should not be able to externalize their
> internal problems to others."
>
>
> My DMARC reports show no authorized transactions being rejected, but I do
> have two servers in Japan that are actively spoofing my organization's
> identity.  How is that an "internal" problem?
>
> DF
>

How is that relevant to the discussion thread? Are they MLMs or other
intermediaries which your users are sending messages to/through? If not
then it sounds like DMARC is working exactly as intended for you as long as
validators/receivers are respecting your DMARC policy assertions.

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

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

[Dotzero]

On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely  wrote:

> On 2020-08-10 7:24 p.m., John Levine wrote:
> > In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you
> write:
> >> Even an external reputation system requires recipient
> >> participation.   That is why I suggested both a
> >> send3="parameters" clause to indicate sender support for
> >> third-party authorization and a verify3="parameters" clause to
> >> indicate recipient support for third-party authentication. When
> >> both are visible to the non-domain message source, that source
> >> can have confidence that the message will be handled as
> >> authorized. >
> > We have had a lot of attempts at third-party authorization schemes
> > going back at least to vouch-by-reference in 2009 and ATPS in 2012,
> > and the Spamhaus Whitelist in 2010.  Every single one of them failed,
> > not due to technical problems, but because nobody was interested.
>
>
> We can either try and understand what was wrong in those schemes, or
> abandon authorization schemes forever.
>
> Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent
> success.
>
> PGP, GPG, and even personal CA certificates never became really
> popular, so we could have concluded that digital signature aren't
> worth considering for anti-spoof protocols.  Yet, someone thought
> about DKIM...
>

There is a little bit of history behind the impetus for SPF and DKIM. In
2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on
Email Authentication and SPAM. It also let it be known that if the private
sector didn't come up with solutions it was willing to move forward with
regulation. This helped drive activity for SPF, the merger of DK and IIM
to create DKIM and Microsoft's push for SenderID. Private sector folks did
not want to risk what government regulation might look like. At that time
there were also folks pushing for PGP, GPG, Personal Certificate and
S/MIME as  paths forward. Even with that, it took a while for industry
efforts to gain some sense of clarity. Notice that the general path forward
was basically domain based and not individual user/client based. There was
a debate within the DKIM effort regarding i= vs d= to the extent that at
one industry event people were walking around with little stickers on their
badges to indicate which they supported. I believe that was courtesy of
Dave Crocker.

Michael Hammer
___
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

[Douglas E. Foster]

Michael Hammer / Dotzero writes:

"Earlier in my DMARC journey I felt that MLMs should adjust and send list mail 
as themselves. Now I have come to the conclusion that they should reject list 
submissions from accounts at domains which publish a DMARC policy of p=reject. 
Domains should not be able to externalize their internal problems to others."

My DMARC reports show no authorized transactions being rejected, but I do have 
two servers in Japan that are actively spoofing my organization's identity.  
How is that an "internal" problem?

DF


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

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

[Alessandro Vesely]

On 2020-08-10 7:24 p.m., John Levine wrote:

In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write:

Even an external reputation system requires recipient
participation.   That is why I suggested both a
send3="parameters" clause to indicate sender support for
third-party authorization and a verify3="parameters" clause to
indicate recipient support for third-party authentication. When
both are visible to the non-domain message source, that source
can have confidence that the message will be handled as
authorized. >

We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.



We can either try and understand what was wrong in those schemes, or 
abandon authorization schemes forever.


Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent 
success.


PGP, GPG, and even personal CA certificates never became really 
popular, so we could have concluded that digital signature aren't 
worth considering for anti-spoof protocols.  Yet, someone thought 
about DKIM...



Best
Ale
--


























___
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

[Alessandro Vesely]

On 2020-08-14 10:27 a.m., Dotzero wrote:

On Thu, Aug 13, 2020 at 10:08 PM John Levine  wrote:

In article  
you write:

"DISCUSS" shouldn't really be a joke. [...]



Adopting the I-D should boost the discussion, not hamper it.  No 
reason to discuss about adoption...




That's a feature, not a bug. I want recipients to be able to assess
the mail my lists send on its own merits.



And recipient domains do just that using local policy override.
DMARC policy is at best a request to the Validator/Receiving
Domain. If a Validator/Receiving Domain chooses to honor the
published DMARC policy for a domain such as p=reject, then they are
in fact assessing the mail your lists send based on the merits as
they see them. The same goes if they decide to not honor that
published DMARC policy and accept mail from your lists.


Agreed.  However, local policy override based on unspecified external 
sources is not easy for medium-small domains.




Earlier in my DMARC journey I felt that MLMs should adjust and
send list mail as themselves. Now I have come to the conclusion
that they should reject list submissions from accounts at domains
which publish a DMARC policy of p=reject.



Oh, in case, users can get another freemail account, or use trash 
email addresses.  Should the email infrastructure depend on the 
existence of such operators?


IMHO, a myriad of medium-small domains is more robust and more 
reliable than a few gorillas managing the whole world communications.




Domains should not be able to externalize their internal problems
to others.


You're sticking to the original concept that DMARC protection shall 
only be granted to heavily abused domains which don't host users' 
mailboxes.  People's email must be spoofable.  Why?



Best
Ale
--


























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

Re: [dmarc-ietf] Firing the vendor

[Dotzero]

On Fri, Aug 14, 2020 at 2:01 AM Neil Anuskiewicz 
wrote:



>
> Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5
> years ago it was difficult to find vendors who were willing to deal with
> DKIM and able to do a good job in implementing. The common mantra was "how
> does this fit into my business model". These days I would consider it table
> stakes.
>
> I see your point but the vast majority of customers Of said vendors
>  aren’t aware there’s a problem until there is. But make authentication and
> alignment easy and part of setup as the best vendors do puts people on the
> right path without hassles, barriers and disincentives.
>

This is NOT an interoperability issue that needs to be solved by the IETF.
It's a personal problem between a client and their vendor.

>
> Fire the vendor isn’t always that easy if you’re locked in and you’ve got
> shit to do. We’re talking about stone masons, accountants, non profit
> organizations, home inspectors, SaaS companies, and all the other people
> who have stuff to get done.
>

Perhaps the IETF needs to come up with an RFC for people who are locked in
and have shit to do. On the other hand, thst may not fall into the realm of
technical problems that the IETF deals with.

>
> Yeah, I’ve helped clients fire plenty of vendors but I’m just saying it is
> not first on one’s to do list most days.
>

And that may be why clients who hire such vendors feel pain, not just with
email authentication but with a whole raft of other issues. A vendor
problem != something that the IETF is going to fix with an RFC.

Michael Hammer
___
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

[Dotzero]

On Thu, Aug 13, 2020 at 10:08 PM John Levine  wrote:

> In article  99yvu0dglz-z19i...@mail.gmail.com> you write:
> >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
> >from a similar problem as PRA in the SenderId draft. There is no way to
> >validate that the specific intermediary is authorized by the (From) domain
> >originating the email through it's generic signalling that it
> >authorizes intermediaries. This means that any source can emit a message
> >claiming to be a legitimate intermediary just as any source could game PR
> >to gain a neutral result.
>
> That's a feature, not a bug. I want recipients to be able to assess
> the mail my lists send on its own merits.
>

And recipient domains do just that using local policy override. DMARC
policy is at best a request to the Validator/Receiving Domain. If a
Validator/Receiving Domain chooses to honor the published DMARC policy for
a domain such as p=reject, then they are in fact assessing the mail your
lists send based on the merits as they see them. The same goes if they
decide to not honor that published DMARC policy and accept mail from your
lists. Earlier in my DMARC journey I felt that MLMs should adjust and send
list mail as themselves. Now I have come to the conclusion that they should
reject list submissions from accounts at domains which publish a DMARC
policy of p=reject. Domains should not be able to externalize their
internal problems to others.

>
> >One could achieve similar outcomes using
> >only reputation and local policy override of DMARC policy.
>
> Only if you believe that the domain on the From: line is automatically
> more credible than the one on the Sender: line. The whole third party
> problem is that the people sending their mail through lists or
> whatever are in fact doing so legitimately, but for various reasons
> their organizations' DMARC policies lie and say they aren't.
>

I think you are misusing the term "credible". Domains which are publishing
p=reject policies are making an assertion regarding mail purporting to be
authorized by their domain. It is not an assertion that their mail is
"good" or should be delivered to a recipient or even given preferential
treatment with regard to filters or policy. The assertion is simply that
mail purporting to be authorized by my domain must pass either SPF or DKIM
validation or else we request that in the event of neither of these
properly validating for a particular email message, please reject this
message. Don't think of it as being about "legitimate" or "not legitimate".
There is a certain (normally small) amount of mail that fails to validate
even when it passes directly from the outbound MTA to the recipient
domain's MTA. The sending domain is accepting that this otherwise valid
mail may (SHOULD?) be rejected by the receiving domain. The organizations
DMARC policies aren't lying. They are simply saying "If this then that."

This ultimately goes back to the elephant in the room. Does an individual
user's use of an account at a domain trump the organization's right to
define how an account at a domain may/should be used? I absolutely agree
that in an ideal world this issue should not be externalized yet here we
are. This is why I made the point above that lists should respect DMARC
policy and not accept submissions from domains with DMARC p=reject
policies. It becomes "Not your circus and not your monkey". and forces the
problem back to the domain and it's users. If an MLM isn't modifying the
message then the DKIM signature should survive and this discussion is
irrelevant. I think this covers the range of MLM use cases that have been a
topic of discussion. If the MLM admin really wants to poke those domains
publishing p=reject then they can respond to user subscribe attempts or
submissions that are rejected with an explanation that they need to go have
a meaningful discussion with their mail admin/IT staff/domain account
provider or whoever is responsible for publishing p=reject for tht domain
but still allowing users to sign up for MLMs or attempt to use other
intermediaries. popcorn is of course optional.

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

Re: [dmarc-ietf] Firing the vendor

[Neil Anuskiewicz]

> On Aug 13, 2020, at 3:09 PM, Douglas E. Foster 
>  wrote:
> 
> 
> Yours is the better answer!
> 
> DF
> 
> 
>  Original message 
> From: Dotzero 
> Date: 8/13/20 5:54 PM (GMT-05:00)
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
> 
> 
> 
>> On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b)  wrote:
>>> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 
>>>  wrote:
>> 
>>> The current DMARC architecture supports authorizing a vendor to mail on 
>>> behalf of their clients if the client includes them in their SPF policy or 
>>> delegates a DKIM scope to them and they use it..
>>> 
>>>  
>>> 
>>> I agree that SPF is too limiting (including hard limits on complexity), and 
>>> DKIM is too complex for an uncooperative vendor.
>>> 
>>>  
>>> 
>>> In most cases, a solution would be a controlled third-party signature 
>>> authorization along the lines of RFC 6541.
>>> 
>>> The client would configure the authorization in his own DNS and the and the 
>>> vendor would only need to sign with their own DKIM signature.   
>>> 
>> 
How would this resolve the alignment failures with regard to the RFC5321.from 
(SPF from) with the organizational domain? 

And I think the vendors motivation is not putting dev and support resources. 
Does this delegation scheme solve that problem? 

>> If "DKIM is too complex for [this] uncooperative vendor", why would having 
>> the "vendor...sign with...DKIM" be workable?
The vendors for whom it would would work already make getting DKIM signing set 
up easy so there’s no problem to be solved.

For the others there’s not much incentive to devote resources and not much risk 
to the vendor to mitigate. No incentive and little risk means not on radar 
unless you care about doing things right. Inbox providers could up the anti 
more and there’s been some movement in that area. 
> 
> Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years 
> ago it was difficult to find vendors who were willing to deal with DKIM and 
> able to do a good job in implementing. The common mantra was "how does this 
> fit into my business model". These days I would consider it table stakes.
I see your point but the vast majority of customers Of said vendors  aren’t 
aware there’s a problem until there is. But make authentication and alignment 
easy and part of setup as the best vendors do puts people on the right path 
without hassles, barriers and disincentives.

Fire the vendor isn’t always that easy if you’re locked in and you’ve got shit 
to do. We’re talking about stone masons, accountants, non profit organizations, 
home inspectors, SaaS companies, and all the other people who have stuff to get 
done. 

Yeah, I’ve helped clients fire plenty of vendors but I’m just saying it is not 
first on one’s to do list most days.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc