Re: [dmarc-ietf] DMARC failure scenarios

[John Levine]

In article <0762f9ada48c4c9eaef06e16a49a2...@bayviewphysicians.com> you write:
>-=-=-=-=-=-
>
>Does this scenario correctly characterize how organizations may be unable to 
>move past p=none with breaking things?

As far as I can made sense of it, no.

>a) A vendor application detects an event, looks up in a database for sender 
>name (client contact) and recipient list.
>
>b) The application connects to a mail server via IMAP, and sends the message 
>using something like application@vendordomain
>for the SMTP from and cllentcontact@clientdomain as the Message from.The 
>client domain becomes especially important if
>the recipients are in a different domain than the client.   An example might 
>be an HVAC system operated by a vendor, on
>behalf of the building manager, which needs to communicate with the building 
>tenants. ...

Again, no. You're confusing submission with SMTP. I have a printer
that sends me e-mail when it's out of paper, which it does by sending
mail to my submission server, not directly to me.  If I were checking DMARC
on the messages, they would easily pass since the submission server adds
DKIM signatures.

>Then the client wants to implement DMARC
>--
>
>d) The client develops a list of all of its third-party mailers and tells the 
>third parties to begin applying the client's
>DKIM signature to their messages.   This adds a boatload of complexity to the 
>vendor's application, since he needs a
>different applied signature for each client.   It requires either major 
>changes to the application, a more sophisticated
>mail server, or a special box simply to sit in front of the mail server to 
>detect and apply the correct signature.  None of
>these seem like generic off-the-shelf solutions.   I would not know where to 
>buy that capability if I needed it today.

Again, no. I believe that devices that send mail do what they've
always done, send it to a submission server for further delivery. The
"special box" has been there all along.

R's,
John

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

[dmarc-ietf] DMARC failure scenarios

[Douglas E. Foster]

Does this scenario correctly characterize how organizations may be unable to 
move past p=none with breaking things?

Before DMARC


a) A vendor application detects an event, looks up in a database for sender 
name (client contact) and recipient list.

b) The application connects to a mail server via IMAP, and sends the message 
using something like application@vendordomain for the SMTP from and 
cllentcontact@clientdomain as the Message from.The client domain becomes 
especially important if the recipients are in a different domain than the 
client.   An example might be an HVAC system operated by a vendor, on behalf of 
the building manager, which needs to communicate with the building tenants..   
The message passes SPF based on the SMTP From address in the vendor domain.   
The client domain is not enforced.

All of this can be implemented with generic off-the-shelf technology.

Then the client wants to implement DMARC
--

d) The client develops a list of all of its third-party mailers and tells the 
third parties to begin applying the client's DKIM signature to their messages.  
 This adds a boatload of complexity to the vendor's application, since he needs 
a different applied signature for each client.   It requires either major 
changes to the application, a more sophisticated mail server, or a special box 
simply to sit in front of the mail server to detect and apply the correct 
signature.  None of these seem like generic off-the-shelf solutions.   I would 
not know where to buy that capability if I needed it today.

e) If the client attempts to comply, it may take a long time and add a lot of 
cost.   If the client cannot comply, switching vendors is also complex and time 
consuming.

So in the end, a hypothetical U.S. government agency may end up telling 
Homeland Security that it cannot meet the DMARC deadline because of an 
application that runs in Peoria Illinois which cannot implement DKIM delegation 
signing.   Of course, if that does not fly, the p=reject goes into effect 
anyway and the folks in Peoria hope that the intended recipients will implement 
an exception in their incoming gateway.

In sum, DMARC participation is not fully in the control of the organization 
that wants to implement it.We need to make DMARC participation a process 
where the participating organization has control over its own success and 
carries the costs of becoming compliant.   DKIM scope delegation does not get 
us there.

DF


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

Re: [dmarc-ietf] Time for a change

[Dotzero]

On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker  wrote:

>
>  DKIM was a synthesis within the IETF of two things (DomainKeys and IIM)
> that started outside.  It underwent significant evolution in the IETF --
> not once, but twice.
>
> Actually, it wasn't.
>
> The constituent parts were separately proposed, during the same initial
> IETF discussions, and the IETF said to go away and come back after
> reconciliation.  That work was done by an ad hoc industry team and there
> was a complete spec and initial implementations before the IETF was again
> approached.
>
> https://tools.ietf.org/html/draft-allman-dkim-base-00
>
> (and note that in the working group field on the title page, it says
> "pre-MASS"...)
>
> The work in the IETF was a refinement of a complete, integrated spec.
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> +1
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Dave Crocker]

 DKIM was a synthesis within the IETF of two things (DomainKeys and 
IIM) that started outside.  It underwent significant evolution in the 
IETF -- not once, but twice.


Actually, it wasn't.

The constituent parts were separately proposed, during the same initial 
IETF discussions, and the IETF said to go away and come back after 
reconciliation.  That work was done by an ad hoc industry team and there 
was a complete spec and initial implementations before the IETF was 
again approached.


https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says 
"pre-MASS"...)


The work in the IETF was a refinement of a complete, integrated spec.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Time for a change

[Murray S. Kucherawy]

On Mon, Aug 17, 2020 at 6:52 AM Dotzero  wrote:

> On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> The reality is that IETF has mostly provided followership, not
>> leadership, on matters of security.  This forum is replicating history.
>> As has been mentioned in the historical review, SPF, DKIM, and DMARC were
>> independently successful projects, as was SSL.  IETF provided
>> after-the-fact blessing.   It is time to follow the same model.
>>
>
> Doug, as someone who has been involved in this space for decades, I think
> you are sorely mistaken in your understanding of things. Many of the people
> involved in the email authentication space interact with each other in
> other places, both online and in person and have been doing so for a very
> long time.
> We don't always agree on the path forward but that is because we come from
> different perspectives. IETF did not provide "after-the-fact" blessing. SPF
> was experimental for a very long time. DMARC is still informational. One of
> the mantras for IETF is "running code and rough consensus". There is
> running code for DMARC but what we are lacking so far is rough consensus.
>

+1.  I would add that SPF and DMARC started outside of the IETF, but DKIM
was a synthesis within the IETF of two things (DomainKeys and IIM) that
started outside.  It underwent significant evolution in the IETF -- not
once, but twice.

This line of thinking also seems to ignore the troubled path that SPF took
to reach the standards track (as RFC 7208).

Or you could apply for M3AAWG membership where all of those constituencies
> participate already.
>

I was just going to say that.  And, at least the last time I went, most of
the same debates happened over there too.

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

[Murray S. Kucherawy]

Still as just me:

On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster  wrote:

> Based on the discussions here, it appears that the notion of From address
> validation was envisioned from the beginning Sender Authentication
> discussions.We have written evidence that Form address validation was
> anticipated in the DKIM and ATPS RFCs prior to DMARC.So we have more
> than a decade of warnings that From address validation was coming.   While
> not everybody has time to read every RFC, the Mailing List trade press must
> have should have been reporting on it as something to watch.
>
I don't follow the logic here.  DKIM, as I recall, expressly disavowed any
assertion that could've been taken as From address validation.  (I think it
was in there before RFC 4871, but we collectively decided to remove it.). I
don't know how one could have inferred imminence from that.

ATPS is an Experimental RFC.  It was meant to, in some ways, augment ADSP
when we'd already figured out the damage it could cause.  The purpose of
publishing it was to get everyone (for some value of "everyone") to agree
on a protocol to use to provide third-party signature authorizations and
see if it was a useful response.  The silence was deafening.

Even after DMARC was in use, it appears that nobody in the mailing list
> community felt inconvenienced until the AOL/Yahoo hack and their decision
> to implement DMARC with p=reject.   This was the moment of Unhappy
> Surprise.Bad guys had obtained many valid email addresses, so one of
> the concerns was how to prevent them from spoofing those users to send
> spam.   They could not use those address in the SMTP address because of
> SPF, but only DMARC could prevent those addresses from being misused in the
> Message From address. It was the obvious thing to do and it would have
> been reckless for them to do otherwise.   Can you at least admit that the
> mailing list community was surprised because they failed to prepare for
> this contingency?
>
I wouldn't characterize it as "failure".  If you agree that DMARC's
antecedent is ADSP, I believe it had already fallen into disfavor to the
point where nobody was really worried about it anymore.

But I would agree that nobody anticipated it, especially since DMARC itself
and RFC 6377 both warned against its use for this very reason.

[...]  As a result, mailing list operators really have no standing in this
> discussion, although they can certainly speak as unhappy individual users
> and on behalf of their unhappy users.
>
I suggest that's precisely what gives them standing.

Consequently, the real problem before us becomes the existence of users who
> are unhappy because the From address on some mail does not meet their
> preferences.I have to ask why that is a problem worthy of a standards
> body? I have about 8 different scenarios in my head where a user might
> be have unmet expectations with the format of the From address, or might
> experience mailing list deliverability problems because of the email
> filtering policy of its domain relative to the addressing practices of his
> mailing list.   If our requirement is to make every user happy, shall we
> head down the path of all 8 problems, not just this one?
>
If all eight problems have been raised and acknowledged by the chairs, then
I imagine the answer to your question is emphatically "yes".

Though published as an RFC, DMARC was not an IETF consensus document.  The
remit of this working group is to come to consensus on a set of changes
that qualify it for the standards track.  We do that by considering the
perspectives and issues raised during that process and coming to consensus
on their respective resolutions.


> This project was supposed to discuss moving DMARC from informational to
> standards track.   It has been hijacked by those who, to paraphrase
> Shakespeare, “have not come to praise DMARC, but to bury it.”   This has
> been abetted by the chair’s assertion that we must square a circle – meet
> the MLs requirement for them to impersonate without authorization while
> continuing to advance the DMARC requirement to prohibit impersonation
> without authorization.
> [...]
>
I have not yet seen any assertion that DMARC needs to be buried.  In fact,
revisiting its assumptions is a perfectly feasible way to come to consensus
on its goals and how they might be achieved.  If DMARC was founded on false
premises, that plainly needs to be considered and possibly fixed.  That can
only strengthen it.

None of this discussion seems invalid to me.

As part of that hijacking, we have been inundated by Mr. Crocker’s
> assertions that the message From Address does not matter.  All the years of
> theoretical analysis that preceded DMARC and all of the operational success
> from implementations of DMARC are just wrong, simply because he says so.
>
It's not simply because he says so.  At the time DMARC was on the drawing
board, the MUA game was different.  We talked about this a lot 

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

[Jesse Thompson]

On 8/7/20 9:32 PM, John Levine wrote:
>> We need spoofing protection for all of our domains without being told we're 
>> misdeploying.
>
> I would be interested to better undertstand the meaning of "need"
> here. It is my impression that most people vastly overestimate how
> much of a phish target they are. Paypal and big banks certainly are, 
> other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Need* would 
imply that domain-spoofing is more common than it is in reality.

Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with 
spoofing (even though most phishing is spoofing the display name and message 
bodies, not the domain) and conclude that they *need* DMARC without really 
understanding the nuances.  Given the opportunity that DMARC marketing 
promises, they definitely *want* inbound DMARC enforcement for domain-spoofing 
of inbound mail (they'll defer to the email-minded folk to figure out the local 
policy exemptions, ARC, etc), as well as *want* domain policies that prevent 
the potential domain spoofing scenarios of owned domains (again, the 
email-minded folk will figure out how to actually "misdeploy" DMARC).  To them, 
it's just a checkmark towards some "maturity" benchmark that they use to 
compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much practical 
application to phishing, like having the observability that DMARC provides, as 
well as the hammer that moving past p=none provides as a way to coerce their 
complex, decentralized institution into a more sustainable operation: 

* Departments sending transactional email - move them to dedicated subdomains 
(this is where really complex institutions would benefit from walking the 
domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated 
submission (preferably OAuth - since basic authentication is the reason why so 
many passwords are exposed)

The latter scenario is interesting because a single user sending from a random 
place doesn't really show up in DMARC aggregate reports.  It may show up in 
forensic reports, but it is easily lost in the noise.  (SPF macros might be 
another way to get fine-grained observability, but that's a privacy leakage 
IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did 
communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage every 
ounce of their political influence to resist.  (It's really fun when your own 
users threaten lawsuits against you - that doesn't happen in Corporate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regardless!

Jesse

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

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

[Murray S. Kucherawy]

On Sun, Aug 16, 2020 at 10:19 AM Hector Santos  wrote:

> I believe it would be prudent for the AD to look at the reasons why
> the IETF has failed with this DKIM Project.  If a cog is not for ADSP
> but for DMARC with the same problems, then what is that to say about
> this process?  It has not been a fair process to say the least. A lot
> of wasted time, money and energy.  It has been a long 15+ yrs and has
> become very tiring. :-(
>
> Despite the 3rd party authorization brush back, the concept has never
> gone away. It says a lot and it will never go away under the current
> DKIM POLICY model using the required hash bound Author Domain anchor
> as the forcing function for authorization.
>

Since this bit is directed at the AD, I finally have to put that hat on.

I don't agree that DKIM has been a failure.  I believe it succeeds at
exactly what it purports to provide, but not more.

The industry in general, and the IETF in particular, have chosen not to
pursue widespread use of any kind of standards-based third party domain
signature policy or reputation system.  That's the obvious consensus, and
in my opinion the reasons for that fact are sound.  Both ATPS (individual
submission, experimental, February 2012) and the REPUTE series of documents
(working group, standards track, late 2013) saw nearly zero adoption after
publication even when free reference implementations were provided.  They
differ from basic DKIM in that they require non-trivial upkeep, and that
appears to be a step function inhibiting adoption among operators.

As to your assertion that this process has not been fair, I'm curious as to
why you say that.  There's nothing I can think of here other than DMARC
that didn't go through a consensus process.  That means concerns about all
of these topics were heard and discussed.  People's opinions that were in
the rough still got aired; I don't recall that anyone was silenced just for
dissenting.  As I said before, I'm disappointed that things like ATPS and
REPUTE never got a serious attempt, but that's not because they were
oppressed or sabotaged.  That's just the reality we're in.

If you can point to a discussion thread on the old DKIM list or any list
since then where procedure wasn't followed, that might be interesting.

I still agree that if we could figure out a way to do this third party
thing, it would go a long way toward resolving this whole problem space.
But in many years of trying, we haven't found a way to do it that scales,
is resistant to attack, is easy to implement and reason about, and is
likely to achieve any real momentum.  That appears to be a taller order
than one might think at first blush, fair or not.  ARC is the only thing
that has achieved consensus and appears to have a chance at non-trivial
levels of adoption.

I think the IETF did fail here in certain ways -- for example, by not being
more helpful to the industry many years ago when the second derivative of
spam and phishing was particularly acute -- but that rant is for another
day.

-MSK, ART AD
___
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

[Jesse Thompson]

On 8/13/20 10:03 AM, John R Levine wrote:
>> -Admittedly, that's where my bias comes in. My job is working with 
>> organizations that have paid my employer for me to be that outside help, so 
>> it's rare for me to see how badly it can be done by people setting 
>> restrictive DMARC policies without knowing what they're doing.
> 
> If they all talked to you first, we'd be having a very different discussion.

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.

Similarly, it's only way to find all of the old DMARC-unaware MLMs, most of 
which haven't been security-patched for years.  Forcing them to upgrade to a 
MLM that can munge the From is a back-door way to get them to patch, or 
reassess their commitment to running the list in the first place.

Enterprise IT/cybersecurity actually want to get better manageability on the 
email their institution emit.  Misdeploying DMARC provides that.  Publishing 
restrictive DMARC on user domains is not always a clueless IT decision.

Jesse

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

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

[John Levine]

In article <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> you write:
>> Why is adoption low? Is that a big problem? Why so few aggressive 
>> policies? Is that a big problem?
>
>DMARC can be quite useful even with p=none. This use case provides 
>insight on what's going on and sometimes, that's all that is wanted. 
>Moving to more aggressive policies require a degree of control on the 
>mail flows that not all organizations are prepared to exercise, IMO.

Quite right. My system publishes DMARC policies for over 100 domains,
and they're all p=none execpt that four which don't send mail at all
have p=reject.

I collect and look at the reports which can be very interesting.

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

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

[Luis E. Muñoz]

On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote:
 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.


My numbers are inverted regarding quarantine vs reject, as I posted on 
this list:


On 30 Jul 2020, at 18:01, Luis E. Muñoz wrote:


I am currently observing ~215.5 million domain names. Out of those, 
~64  million have a seemingly _valid_ SPF record and ~113 million with 
at least one MX record.


This is a current breakdown of the (valid) DMARC records I am 
observing over the general domain population above. This amounts to an 
adoption rate of ~1.7%.


|p   |  count  |
| :- | --: |
| none   | 2715614 |
| quarantine |  238584 |
| reject |  726045 |


Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject 
to quarantine ratio across the board.


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

Is that a big problem?


DMARC can be quite useful even with p=none. This use case provides 
insight on what's going on and sometimes, that's all that is wanted. 
Moving to more aggressive policies require a degree of control on the 
mail flows that not all organizations are prepared to exercise, IMO.


Best regards

-lem

___
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

[Dave Crocker]

On 8/17/2020 11:53 AM, Dotzero wrote:

Apology accepted. ;-)


nein.  maaf.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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 Mon, Aug 17, 2020 at 2:28 PM Dave Crocker  wrote:

> On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote:
> >> Michael Hammer (Inaccurately referred to by you as Herr Hammer)
> >
> > Talking about precise language, Dave, I think you owe Michael an apology
> ;-)
>
>
> to mix languages, au contraire.  I was being formal, as well as precise...
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net


Apology accepted. ;-)

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

[Dave Crocker]

On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote:

Michael Hammer (Inaccurately referred to by you as Herr Hammer)


Talking about precise language, Dave, I think you owe Michael an apology ;-)



to mix languages, au contraire.  I was being formal, as well as precise...

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

[Rolf E. Sonneveld]

>> On 17 Aug 2020, at 16:47, Dotzero  wrote:
> 
> 
> 
>>> On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker  wrote:
> On 8/17/2020 7:33 AM, Dotzero wrote:
 DMARC fixes one thing and one thing only, direct domain abuse.
>>> 
>>> It does no such thing.  Domains can still be 'directly' abused in all sorts 
>>> of ways that DMARC does not affect.  
>>> 
>> 
>> Mea Culpa. You are correct that it only does so in the context of SPF and 
>> DKIM validation which protects rfc5322 From field domains and aligned 
>> rfc5321 Mail From domains (SPF).
>> 
>> 
>> A continuing and in my view fundamental problem with discussion in this 
>> space is the lack of careful and precise language when talking about actions 
>> and effects.
>> 
>> 
>> 
>> So...
>> 
>> DMARC fixes abuse of rfc5322.From field domains.  
>> 
>> THAT is the only thing it does.
>> 
> See above.. I was even more specific than you were in terms of what DMARC 
> does. 
>> And it does it at the expense of breaking some legitimate uses.
>> 
> Only when it is used in domains where there are individual user accounts and 
> not (only) transactional mail uses. If I use a hammer (no pun intended) to 
> pound in a screw, it doesn't make it the right tool for the job.
> 
> Michael Hammer (Inaccurately referred to by you as Herr Hammer)

Talking about precise language, Dave, I think you owe Michael an apology ;-)

/rolf___
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 Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote:
>> On 17 Aug 2020, at 14:18, Dotzero  wrote:
>>
>>
>> You raise an interesting point, Laura. Whatever "solutions" we put in place, 
>> the abusers/bad guys will evolve. One of the problems for the good guys (for 
>> some definition of good) is that standards work takes years (decades?)  
>> while the bad  guys change their tactics at will. Crime existed before the 
>> Internet and will continue long after we are all dead and buried.
> 
> Totally agreed. The issue here is that DMARC is a fundamentally flawed model 
> for preventing phishing. Phishers were adapting to mailbox provider filters 
> even before DMARC and there was a lot of cousin and non-look-alike domain 
> phishing even during the initial discussions. I know these issues were 
> brought up during discussion of the protocol. Unfortunately, they weren’t 
> sufficiently addressed and now we’re at a point where, to my mind, DMARC 
> doesn’t fix anything while also breaking a lot of ways folks use mail.
> 
> It’s a little late now to go back.


That's what I meant by being stuck midstream.  Neither forward nor backward...


> I think this is an opportunity to think about the underlying technical 
> problems as well as a chance to revisit the assumptions about how email is 
> used. Discussing things like Dave’s drafts will give us a chance to talk 
> about how people actually use email to communicate with one another. And how 
> we can allow brands what they want without breaking email too much for the 
> rest of us.


We have to fix the defects that cause DMARC collateral damage, if I may so 
roughly summarize our charter.  We have two ways to do that:

Forward:  Solve each specific problem.  For example, apply dkim-transform to 
MLM messages.

Backward:  Kill DMARC expansion.  For example, reaffirm that domains which host 
personal mailboxes must not publish strict policies.


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 Mon 17/Aug/2020 14:48:31 +0200 Dotzero wrote:

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely  wrote:


Gmail has a visual perspective that allows them to know each and every
email domain worldwide, and employs a number of people who help
continuously upgrading domain reputation.  In order to enjoy such
technology, medium-small domains can get a G Suite account.  That's
oligopoly.  If the technology were simpler and clearer, running one's
own mail server could be a valid alternative.



Setting aside DMARC, running email servers has always had a bit of
complexity that is beyond the ability of the average person. I'm not sure
what your point here is.



Having very many autonomous MTAs is better than oligopoly, from a 
dynamic social stability point of view.  As spam elimination is the 
most prominent complexity that cause giving up private MTAs, global 
DMARC adoption might have the potential to stabilize communications.



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

[Dotzero]

On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker  wrote:

> On 8/17/2020 7:33 AM, Dotzero wrote:
>
> DMARC fixes one thing and one thing only, direct domain abuse.
>
>
> It does no such thing.  Domains can still be 'directly' abused in all
> sorts of ways that DMARC does not affect.
>

Mea Culpa. You are correct that it only does so in the context of SPF and
DKIM validation which protects rfc5322 From field domains and aligned
rfc5321 Mail From domains (SPF).

> 
>
> A continuing and in my view fundamental problem with discussion in this
> space is the lack of careful and precise language when talking about
> actions and effects.
>
> 
>
> So...
>
> DMARC fixes abuse of rfc5322.From field domains.
>
> THAT is the only thing it does.
>
See above. I was even more specific than you were in terms of what DMARC
does.

> And it does it at the expense of breaking some legitimate uses.
>
Only when it is used in domains where there are individual user accounts
and not (only) transactional mail uses. If I use a hammer (no pun intended)
to pound in a screw, it doesn't make it the right tool for the job.

Michael Hammer (Inaccurately referred to by you as Herr 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 Mon, Aug 17, 2020 at 10:27 AM Dave Crocker  wrote:

> On 8/17/2020 7:00 AM, Laura Atkins wrote:
>
> I think the most
>  useful thing we can say about the FTC workshops is that they were a
> forcing mechanism that instigated a lot of effort and innovation in the
> space. Some of those efforts fell by the wayside and some still persist.
>
>
> You think? I’m not sure I’d agree. I saw the workshop as mostly a
> political (and educating the politicians) exercise. The effort and
> innovation were already there and being done by a lot of people who weren’t
> there. I’m kinda bemused by the importance folks have assigned to it in
> relation to the vastly different email ecosystem we have today.
>
>
> This might be quibbling, but I think it kicked a bit more energy into the
> anti-abuse industry.  So, as a moment to mark in time, it I think it was
> useful.  But no, not fundamentally for the creation and development of
> email anti-abuse work.
>
> d/
>

Exactly. +1

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

[Dave Crocker]

On 8/17/2020 7:33 AM, Dotzero wrote:

DMARC fixes one thing and one thing only, direct domain abuse.



It does no such thing.  Domains can still be 'directly' abused in all 
sorts of ways that DMARC does not affect.




   A continuing and in my view fundamental problem with discussion in
   this space is the lack of careful and precise language when talking
   about actions and effects.



So...

DMARC fixes abuse of rfc5322.From field domains.

THAT is the only thing it does.

And it does it at the expense of breaking some legitimate uses.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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 Mon, Aug 17, 2020 at 10:01 AM Laura Atkins 
wrote:

>
>
> On 17 Aug 2020, at 14:18, Dotzero  wrote:
>
>>
>> And, 17 years on, we know that domain level authentication doesn’t
>> actually help filter spam nor does it provide law enforcement with a potent
>> tool for locating and identifying spammers. It was promising, it didn’t
>> live up to the promise.
>>
>> There were a lot of thrown at the wall during those 3 days of talks. One
>> of them was domain level opt-out. Another was a global opt-out list similar
>> to the postal opt-outs run by the DMA. Another was a technology called
>> TEOS. HashCash. The list of things we discussed as promising solutions was
>> extensive. Just because we discussed a particular kind of solution does not
>> mean that anything was decided. It also doesn’t mean that any particular
>> solution mentioned was workable.
>>
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>> 
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>>
>>
>>
>> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>>
>>It doesn't require that one day everyone turns it on and we begin
>>to drop the rest of the e-mail and break e-mail.  If a domain
>>decides to turn it on, then they've prevented forgery for their
>>domain and they're protected.  For persons that have not turned it
>>on, then their e-mail still flows but they are not able to
>>stop people from forging messages from their domain.  So, I think
>>it's something useful and can be deployed incrementally.
>>
>>
>> We know, now, that turning on domain level protection does not stop
>> phishing attacks against that company. It stops direct spoofing of the
>> domain, but the phishers simply use a completely different domain. Just
>> this weekend I got a PayPal phish. PayPal who helped invent DMARC are still
>> getting spoofed and phished. Sure, the phishers aren’t using the
>> paypal.com domain, but that doesn’t seem to have any effect on their
>> success at stealing money from people.
>>
>
> You raise an interesting point, Laura. Whatever "solutions" we put in
> place, the abusers/bad guys will evolve. One of the problems for the good
> guys (for some definition of good) is that standards work takes years
> (decades?)  while the bad  guys change their tactics at will. Crime existed
> before the Internet and will continue long after we are all dead and buried.
>
>
> Totally agreed. The issue here is that DMARC is a fundamentally flawed
> model for preventing phishing. Phishers were adapting to mailbox provider
> filters even before DMARC and there was a lot of cousin and non-look-alike
> domain phishing even during the initial discussions. I know these issues
> were brought up during discussion of the protocol. Unfortunately, they
> weren’t sufficiently addressed and now we’re at a point where, to my mind,
> DMARC doesn’t fix anything while also breaking a lot of ways folks use mail.
>
>
DMARC fixes one thing and one thing only, direct domain abuse. Not cousin
domains, not homoglyphs and not a whole bunch of other things. It
was successful in achieving its intended purpose. It was initially
developed and deployed privately as a "private club". The intent in making
it a public standard was to enable any domain, regardless of size or
connections to be able to participate if that domain needed to fight direct
domain abuse, noting the caveats regarding individual user accounts vs
transactional email.

It’s a little late now to go back. I think this is an opportunity to think
> about the underlying technical problems as well as a chance to revisit the
> assumptions about how email is used. Discussing things like Dave’s drafts
> will give us a chance to talk about how people actually use email to
> communicate with one another. And how we can allow brands what they want
> without breaking email too much for the rest of us.
>
> It seems we're still stuck midstream...
>>
>>
>> Stuck at what? Many of the people who were at that conference are still
>> working in the field and understand both the purpose and what came out of
>> the forum. I’d also say that most of what happened there is a nice bit of
>> history but is also irrelevant to addressing the spam problem as it is now.
>> Email has evolved significantly in the last 5 years, much less the last 15.
>> We can use the discussion as history to say “we looked at this and it
>> didn’t work” but I don’t really see a lot of value in saying “let’s retread
>> things from a decade and a half ago that didn’t work.”
>>
>
> I think the most
>  useful thing we can say about the FTC workshops is that they were a
> forcing mechanism that instigated a lot of effort

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

[Dave Crocker]

On 8/17/2020 7:00 AM, Laura Atkins wrote:

I think the most
 useful thing we can say about the FTC workshops is that they were a 
forcing mechanism that instigated a lot of effort and innovation in 
the space. Some of those efforts fell by the wayside and some still 
persist.


You think? I’m not sure I’d agree. I saw the workshop as mostly a 
political (and educating the politicians) exercise. The effort and 
innovation were already there and being done by a lot of people who 
weren’t there. I’m kinda bemused by the importance folks have assigned 
to it in relation to the vastly different email ecosystem we have today.




This might be quibbling, but I think it kicked a bit more energy into 
the anti-abuse industry.  So, as a moment to mark in time, it I think it 
was useful.  But no, not fundamentally for the creation and development 
of email anti-abuse work.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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 17 Aug 2020, at 14:18, Dotzero  wrote:
> 
> And, 17 years on, we know that domain level authentication doesn’t actually 
> help filter spam nor does it provide law enforcement with a potent tool for 
> locating and identifying spammers. It was promising, it didn’t live up to the 
> promise. 
> 
> There were a lot of thrown at the wall during those 3 days of talks. One of 
> them was domain level opt-out. Another was a global opt-out list similar to 
> the postal opt-outs run by the DMA. Another was a technology called TEOS. 
> HashCash. The list of things we discussed as promising solutions was 
> extensive. Just because we discussed a particular kind of solution does not 
> mean that anything was decided. It also doesn’t mean that any particular 
> solution mentioned was workable. 
> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>>>  
>>> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>>>  
>>> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>>>  
>>> 
>> 
>> 
>> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>> 
>>It doesn't require that one day everyone turns it on and we begin
>>to drop the rest of the e-mail and break e-mail.  If a domain
>>decides to turn it on, then they've prevented forgery for their
>>domain and they're protected.  For persons that have not turned it
>>on, then their e-mail still flows but they are not able to
>>stop people from forging messages from their domain.  So, I think
>>it's something useful and can be deployed incrementally.
> 
> We know, now, that turning on domain level protection does not stop phishing 
> attacks against that company. It stops direct spoofing of the domain, but the 
> phishers simply use a completely different domain. Just this weekend I got a 
> PayPal phish. PayPal who helped invent DMARC are still getting spoofed and 
> phished. Sure, the phishers aren’t using the paypal.com  
> domain, but that doesn’t seem to have any effect on their success at stealing 
> money from people. 
> 
> You raise an interesting point, Laura. Whatever "solutions" we put in place, 
> the abusers/bad guys will evolve. One of the problems for the good guys (for 
> some definition of good) is that standards work takes years (decades?)  while 
> the bad  guys change their tactics at will. Crime existed before the Internet 
> and will continue long after we are all dead and buried.

Totally agreed. The issue here is that DMARC is a fundamentally flawed model 
for preventing phishing. Phishers were adapting to mailbox provider filters 
even before DMARC and there was a lot of cousin and non-look-alike domain 
phishing even during the initial discussions. I know these issues were brought 
up during discussion of the protocol. Unfortunately, they weren’t sufficiently 
addressed and now we’re at a point where, to my mind, DMARC doesn’t fix 
anything while also breaking a lot of ways folks use mail.

It’s a little late now to go back. I think this is an opportunity to think 
about the underlying technical problems as well as a chance to revisit the 
assumptions about how email is used. Discussing things like Dave’s drafts will 
give us a chance to talk about how people actually use email to communicate 
with one another. And how we can allow brands what they want without breaking 
email too much for the rest of us. 

>> It seems we're still stuck midstream...
> 
> Stuck at what? Many of the people who were at that conference are still 
> working in the field and understand both the purpose and what came out of the 
> forum. I’d also say that most of what happened there is a nice bit of history 
> but is also irrelevant to addressing the spam problem as it is now. Email has 
> evolved significantly in the last 5 years, much less the last 15. We can use 
> the discussion as history to say “we looked at this and it didn’t work” but I 
> don’t really see a lot of value in saying “let’s retread things from a decade 
> and a half ago that didn’t work.”
> 
> I think the most 
>  useful thing we can say about the FTC workshops is that they were a forcing 
> mechanism that instigated a lot of effort and innovation in the space. Some 
> of those efforts fell by the wayside and some still persist.

You think? I’m not sure I’d agree. I saw the workshop as mostly a political 
(and educating the politicians) exercise. The effort and innovation were 
already there and being done by a lot of people who weren’t there. I’m kinda 
bemused by the importance fol

Re: [dmarc-ietf] Time for a change

[Dotzero]

On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster  wrote:

>
> The reality is that IETF has mostly provided followership, not leadership,
> on matters of security.  This forum is replicating history.   As has been
> mentioned in the historical review, SPF, DKIM, and DMARC were independently
> successful projects, as was SSL.  IETF provided after-the-fact blessing.
> It is time to follow the same model.
>

Doug, as someone who has been involved in this space for decades, I think
you are sorely mistaken in your understanding of things. Many of the people
involved in the email authentication space interact with each other in
other places, both online and in person and have been doing so for a very
long time.
We don't always agree on the path forward but that is because we come from
different perspectives. IETF did not provide "after-the-fact" blessing. SPF
was experimental for a very long time. DMARC is still informational. One of
the mantras for IETF is "running code and rough consensus". There is
running code for DMARC but what we are lacking so far is rough consensus.

If there is an opportunity to accelerate DMARC adoption, I think it is in
> the area of third-party authentication, presumably based on ATSP.   To move
> the possibility forward, we need to move off this list.  The target
> audience for this capability will be organizations that are non-DMARC or
> DMARC p=none specifically because DKIM delegation is an obstacle.I have
> no idea whether that category is a trivial or non-trivial group, so we
> would need to find out.  Major ESPs are successfully implementing DKIM
> scope delegation to comply with DMARC, so maybe it is not the issue.   DKIM
> delegation creates complexity which becomes an obstacle to new entrants, so
> big ESPs may like the status quo just fine.   These are all things need to
> be assessed, and are more important than writing a new specification.
>

You can move anywhere you want and write any specification you want but you
still have to attract meaningful interest and adoption in order for it to
become a standard.



>
> Then, we need to expand the base of participants to include people who
> would be willing to implement the third-party authentication scheme after
> it is defined.   I think that list would need to look something like this:
>
>
>- A national government representative to ensure that any new proposal
>is not vetoed,
>
> What? Which national government are you referring to? Do you understand
that the IETF is international in it's participation? If you are referring
to the U.S. Government, can you show me a single example of the government
vetoing a technical standard?

>
>- A financial services industry representative
>- An Email Service Provider industry representative
>- A large organization that is holding back on DMARC p=reject because
>DKIM delegation is an obstacle.
>- One or more commercial product representatives
>- I would love to have Verizon Media participate, but I have asked and
>had no response.
>
> and why would you expect them to respond to you?


> If you want to participate, send me a direct email.More importantly,
> if you have connections with people who could play the role of influencers,
> reach out to them.
>
> If there are other topics that would move DMARC forward, we can put them
> up for consideration.  If you want to discuss special treatment for mailing
> lists, you are specifically disinvited.
>
>
> Doug Foster
>

Or you could apply for M3AAWG membership where all of those constituencies
participate already.

I wish you luck in your endeavors but I think you are doomed to failure.

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

[Joseph Brennan]

On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins 
wrote:

>
>
> The DMARC proponents have asserted that DMARC prevents domain specific
> spoofing and phishing. The amount of harm DMARC authentication has caused,
> however, seems disproportional to this small benefit. Phishing is still
> happening using cousin domains (and even random domains). Departments
> inside companies avoid DMARC mandates buy buying cousin and “campaign
> specific” domains which trains users to be phishing targets for those
> domains. Companies have tried to cut down on this by saying DMARC must be
> done for all those domains as well. Unfortunately, those “from above”
> decrees have often created more problems than they solved.
>
> Mailing lists have coped by rewriting from addresses, but that has caused
> a lot of issues. Two of the big ones are members can no longer search for
> “mail from this list member” and cannot easily create filters acting on
> mail from other participants.
>

Well said (I liked the poetic indentation too)

The fact is that DMARC has disrupted the flow of ordinary legitimate email.
Actors not involved or interested in DMARC have had to spend time and money
developing ways to work around DMARC in order to keep mailing lists and
forwarding working, or else they have had to spend time and money on the
alternative of informing their customers that legitimate practices they
have done for years no longer work reliably and have to be discontinued.

Adding more complexity does not make a broken thing less broken. I think
the proposed standard should simply spell out in plain words that the
purpose of DMARC is to protect transactional mail, e.g. about bank and
credit accounts or purchase confirmations, and that it is not for mail from
ordinary end users. Given that I think more sending systems would be
willing to publish p=reject and more receiving systems would be willing to
honor it. It won't be the end of spoofs, but it would reduce the disruption
to people outside the DMARC club.


---
Joseph Brennan
___
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 Mon, Aug 17, 2020 at 8:22 AM Laura Atkins 
wrote:

>
>
> On 17 Aug 2020, at 12:25, Alessandro Vesely  wrote:
>
> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
>
>
> The forum page is off the FTC website, but the document links are
> still accessible:
>
>
>
> A copy is here:
>
> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/
>
> A sentence says:
>
>The Report, however, identified domain-level authentication as a
>promising technological development that would enable Internet
>Service Providers (‘‘ISPs’’) and other domain holders to better
>filter spam, and that would provide law enforcement with a potent
>tool for locating and identifying spammers.
>
>
> And, 17 years on, we know that domain level authentication doesn’t
> actually help filter spam nor does it provide law enforcement with a potent
> tool for locating and identifying spammers. It was promising, it didn’t
> live up to the promise.
>
> There were a lot of thrown at the wall during those 3 days of talks. One
> of them was domain level opt-out. Another was a global opt-out list similar
> to the postal opt-outs run by the DMA. Another was a technology called
> TEOS. HashCash. The list of things we discussed as promising solutions was
> extensive. Just because we discussed a particular kind of solution does not
> mean that anything was decided. It also doesn’t mean that any particular
> solution mentioned was workable.
>
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>
>
>
> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>
>It doesn't require that one day everyone turns it on and we begin
>to drop the rest of the e-mail and break e-mail.  If a domain
>decides to turn it on, then they've prevented forgery for their
>domain and they're protected.  For persons that have not turned it
>on, then their e-mail still flows but they are not able to
>stop people from forging messages from their domain.  So, I think
>it's something useful and can be deployed incrementally.
>
>
> We know, now, that turning on domain level protection does not stop
> phishing attacks against that company. It stops direct spoofing of the
> domain, but the phishers simply use a completely different domain. Just
> this weekend I got a PayPal phish. PayPal who helped invent DMARC are still
> getting spoofed and phished. Sure, the phishers aren’t using the
> paypal.com domain, but that doesn’t seem to have any effect on their
> success at stealing money from people.
>

You raise an interesting point, Laura. Whatever "solutions" we put in
place, the abusers/bad guys will evolve. One of the problems for the good
guys (for some definition of good) is that standards work takes years
(decades?)  while the bad  guys change their tactics at will. Crime existed
before the Internet and will continue long after we are all dead and buried..

> It seems we're still stuck midstream...
>
>
> Stuck at what? Many of the people who were at that conference are still
> working in the field and understand both the purpose and what came out of
> the forum. I’d also say that most of what happened there is a nice bit of
> history but is also irrelevant to addressing the spam problem as it is now.
> Email has evolved significantly in the last 5 years, much less the last 15.
> We can use the discussion as history to say “we looked at this and it
> didn’t work” but I don’t really see a lot of value in saying “let’s retread
> things from a decade and a half ago that didn’t work.”
>

I think the most
 useful thing we can say about the FTC workshops is that they were a
forcing mechanism that instigated a lot of effort and innovation in the
space. Some of those efforts fell by the wayside and some still persist.

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

[Dave Crocker]

On 8/17/2020 2:57 AM, Alessandro Vesely wrote:
Reference to that event as if it 'established' anything is misguided, 
at best.  The meetings were helpful, but not definitive.  And the 
efforts at domain level authentication were wholly independent of 
these events.



Would it be still correct to mention that summit as a conspicuous event 
that testifies the emergence of domain-level authentication around the 
early 2000s?


No.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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 Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely  wrote:

> On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
> >
> > If I put my gmail address into the from field, there is no
> > pretending, no matter what platform I am using.
> 
> 
>  That conflicts with the coarse-grained authentication strategy,
>  established at the FTC Email Authentication Summit in November
>  2004, as Doug^W Michael recalled >>>
> >>> 1. I was making a semantic point, not a technical or technical
> >>> policy one.
> >>
> >> They have to match at some point.
> >
> > it would be nice, wouldn't it?
> >
> > but that's separate from the factual statement I made.
>
>
> Separate but related.
>
>
> >>> 2. There was nothing 'established' at that event.  There were
> >>> interesting discussions, but that's all.
> >>
> >>
> >> I wasn't there.  Can't it be considered the historic event that
> >> marked domain-level authentication as the promising strategy to
> >> counter email abuse?
> >
> > Reference to that event as if it 'established' anything is misguided,
> > at best.  The meetings were helpful, but not definitive.  And the
> > efforts at domain level authentication were wholly independent of
> > these events.
>
>
> Would it be still correct to mention that summit as a conspicuous
> event that testifies the emergence of domain-level authentication
> around the early 2000s?
>
>
As someone who was there, I would be reticent to make such a statement.

>
> > As already noted on this list, the events served as a plea from the
> > government and, therefore, a signal that the government was concerned.
>
>
> A noteworthy historical detail.
>

I think myself and many others considered it more of an ultimatum to the
private sector than a plea.

>
>
>  Your gmail address needs to be authenticated by gmail.
> >>>
> >>> Good grief, no.  There is no system rule to that effect.  DMARC
> >>> created that, but no policy before it was in place, never mind
> >>> accepted.
> >>
> >>
> >> DMARC took that strategy to the extremes.  A number of users and
> >> operators seem to have accepted it.  Why cannot we accept it too?
> >
> > That DMARC does something and that some people use it is quite
> > different from claiming that there was some grand change in the
> > semantics and operational policy of email.  Why can't THAT be accepted?
>

I think this is one of those areas that where you sit dictates where you
stand on the issue. When we talk about the evolution of the Internet we
could also go back to the days of AUP and talk about changes. Just saying.


>
> There's been a combination of events, from IETF's reluctant
> laissez-faire to Yahoo/AOL adoption, which brought up the illusion
> that email authentication can provide a global means to counter
> spoofing.  To believe that such illusion will come true makes for a
> strong motivation.
>

We really do need to stop using the word "spoofing" when we talk about
intermediaries such as MLMs.

>
> Couldn't we meet somewhere halfway?  I can see that you, John, Herr
> Hammer, and other relevant participants don't accept that domain-level
> authentication is semantically mandatory.  What d'you reckon about the
> possibility that such grand semantic change can be made official
> within the next 10~20 years?  I think that by just spelling the
> technical means /as if/ such change is going to happen, we can design
> a consistent authentication protocol.
>

Could people please stop referring to me as Herr Hammer. I am neither
German nor a Herr.


> It seems to me most expenses have been paid already, for example this
> mailing list is applying From: rewriting.  We don't need to propose
> further restrictions.  To the opposite, there are means on the
> table[*] that can enable us to sketch a time horizon where From:
> rewriting can cease.
>
> 16 years have passed since the FTC event, which is 1/3 of those 45.
> What I see looks much like a very mild shift.  Lazy operators have
> plenty of time before the semantic change is established, at some
> point in the medium-term future, if ever.
>

Notwithstanding my position on the issues being discussed, I think it is
unfair and inappropriate to refer to those opposed to changing semantics as
"lazy operators". Just because you want a change and they are against such
change does not make them lazy.

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 Sun, Aug 16, 2020 at 2:17 PM John R Levine  wrote:

>
> No, it was just some political theatre.  We were already working on SPF
> and DKIM.
>

DKIM didn't exist  until that approximate time frame. There was Domain
Keys (DK) and there was Internet Identified Mail (IIM)

>
> > DMARC took that strategy to the extremes.  A number of users and
> operators
> > seem to have accepted it.  Why cannot we accept it too?
>
> Please review the previous bazillion messages on this topic.
>

Are those bazillion messages authenticated? ;-)

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 Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely  wrote:

>
> >> That conflicts with the coarse-grained authentication strategy,
> >> established at the FTC Email Authentication Summit in November
> >> 2004, as Doug^W Michael recalled. >
>
> There was no such strategy established regardless of what one person
remembers.

>
>
>
> > 2. There was nothing 'established' at that event.  There were
> > interesting discussions, but that's all.
>

Agreed.

>
>
> I wasn't there.  Can't it be considered the historic event that marked
> domain-level authentication as the promising strategy to counter email
> abuse?
>

Nope. It was one of many things presented/disccussed.

>
> https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E
>
>
> >> Your gmail address needs to be authenticated by gmail.
> >
> > Good grief, no.  There is no system rule to that effect.  DMARC
> > created that, but no policy before it was in place, never mind accepted.
>

Just to reiterate, DMARC, SPF and DKIM operate at the domain level
granularity, not at the individual email address level granularity.

>
>
> DMARC took that strategy to the extremes.  A number of users and
> operators seem to have accepted it.  Why cannot we accept it too?
>

DMARC does one thing and one thing only, and that is to mitigate direct
domain abuse. It was not intended to stop phishing, spam or anything but
direct domain abuse. The issues with uses such as mailing lists were
identified and noted.

>
>
> >> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
> >> whitelisted as yet another domain (songbird.com) can hardly be
> >> verified.  There is no "pretending", since it's you, but it is not
> >> formally distinguishable from spoof, is it?
> >
> > Whether valid and invalid uses can be distinguished does not alter the
> > fact that valid uses are valid.
>
>
> The problem is to find the technical means that allow receivers and
> recipients to verify such validity.
>
>
> >>> This continuing practice of characterizing valid use as if it were
> >>> spoofing or pretending has been a major impediment to constructive
> >>> discussion in the industry.
> >>
> >> A system that is able to recognize all your domains and affiliations
> >> in order to authenticate messages does cost several orders of
> >> magnitude more than a simple "mechanical" verifier.  That way,
> >> requiring too much flexibility is a push toward oligopoly.
> >
> > I have no idea what you are referring it.
>
>
> Gmail has a visual perspective that allows them to know each and every
> email domain worldwide, and employs a number of people who help
> continuously upgrading domain reputation.  In order to enjoy such
> technology, medium-small domains can get a G Suite account.  That's
> oligopoly.  If the technology were simpler and clearer, running one's
> own mail server could be a valid alternative.
>

Setting aside DMARC, running email servers has always had a bit of
complexity that is beyond the ability of the average person. I'm not sure
what your point here is.

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 Sun, Aug 16, 2020 at 11:31 AM Dave Crocker  wrote:

>
>
> 2. There was nothing 'established' at that event.  There were
> interesting discussions, but that's all.
>

In fact, some of the most interesting discussions took place outside the
formal event.

>
> 3. I'm not finding the reference in any of Doug's notes that your are
> relying on.  Please be specific about it.
>
>
> > Doug recalled.  Your gmail address needs to be authenticated by gmail.
>
> Good grief, no.  There is no system rule to that effect.  DMARC created
> that, but no policy before it was in place, nevermind accepted.
>

We need to be very careful in asserting what DMARC does or does not do.
DMARC does not prevent spoofing within an email domain. So continuing the
gmail example, DMARC would not prevent dcroc...@gmail.com from pretending
to be dotz...@gmail.com within the gmail system. There are other mechanisms
for preventing this, but DMARC is not that solution.

>
>
> > Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
> > whitelisted as yet another domain (songbird.com) can hardly be
> > verified.  There is no "pretending", since it's you, but it is not
> > formally distinguishable from spoof, is it?
>
> Whether valid and invalid uses can be distinguished does not alter the
> fact that valid uses are valid.
>

What are valid uses constitutes a key part of the discussion.  At one end
of the discussion is "We have always done it this way so go away". At the
other end of the discussion is "Tough noogies, thing change". An
interesting question is who gets to determine what is a valid use? Another
aspect is whether such determinations are technical, political, legal,
social or ? Part of the difficulty we are having with our discussions here
is that people are conflating the various aspects of the problem space.

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

[Laura Atkins]

> On 17 Aug 2020, at 12:25, Alessandro Vesely  wrote:
> 
> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
>> 
>> The forum page is off the FTC website, but the document links are 
>> still accessible:
> 
> 
> A copy is here:
> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/
> 
> A sentence says:
> 
>The Report, however, identified domain-level authentication as a
>promising technological development that would enable Internet
>Service Providers (‘‘ISPs’’) and other domain holders to better
>filter spam, and that would provide law enforcement with a potent
>tool for locating and identifying spammers.

And, 17 years on, we know that domain level authentication doesn’t actually 
help filter spam nor does it provide law enforcement with a potent tool for 
locating and identifying spammers. It was promising, it didn’t live up to the 
promise. 

There were a lot of thrown at the wall during those 3 days of talks. One of 
them was domain level opt-out. Another was a global opt-out list similar to the 
postal opt-outs run by the DMA. Another was a technology called TEOS. HashCash. 
The list of things we discussed as promising solutions was extensive. Just 
because we discussed a particular kind of solution does not mean that anything 
was decided. It also doesn’t mean that any particular solution mentioned was 
workable. 

>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
> 
> 
> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
> 
>It doesn't require that one day everyone turns it on and we begin
>to drop the rest of the e-mail and break e-mail.  If a domain
>decides to turn it on, then they've prevented forgery for their
>domain and they're protected.  For persons that have not turned it
>on, then their e-mail still flows but they are not able to
>stop people from forging messages from their domain.  So, I think
>it's something useful and can be deployed incrementally.

We know, now, that turning on domain level protection does not stop phishing 
attacks against that company. It stops direct spoofing of the domain, but the 
phishers simply use a completely different domain. Just this weekend I got a 
PayPal phish. PayPal who helped invent DMARC are still getting spoofed and 
phished. Sure, the phishers aren’t using the paypal.com  
domain, but that doesn’t seem to have any effect on their success at stealing 
money from people. 

> It seems we're still stuck midstream...

Stuck at what? Many of the people who were at that conference are still working 
in the field and understand both the purpose and what came out of the forum. 
I’d also say that most of what happened there is a nice bit of history but is 
also irrelevant to addressing the spam problem as it is now. Email has evolved 
significantly in the last 5 years, much less the last 15. We can use the 
discussion as history to say “we looked at this and it didn’t work” but I don’t 
really see a lot of value in saying “let’s retread things from a decade and a 
half ago that didn’t work.”

laura


> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Alessandro Vesely]

On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
> 
> The forum page is off the FTC website, but the document links are 
> still accessible:


A copy is here:
https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/

A sentence says:

The Report, however, identified domain-level authentication as a
promising technological development that would enable Internet
Service Providers (‘‘ISPs’’) and other domain holders to better
filter spam, and that would provide law enforcement with a potent
tool for locating and identifying spammers.


> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf


Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:

It doesn't require that one day everyone turns it on and we begin
to drop the rest of the e-mail and break e-mail.  If a domain
decides to turn it on, then they've prevented forgery for their
domain and they're protected.  For persons that have not turned it
on, then their e-mail still flows but they are not able to
stop people from forging messages from their domain.  So, I think
it's something useful and can be deployed incrementally.


It seems we're still stuck midstream...


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

[Laura Atkins]

> On 17 Aug 2020, at 10:57, Alessandro Vesely  wrote:
> 
> On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
>> If I put my gmail address into the from field, there is no pretending, 
>> no matter what platform I am using.
> 
> 
> That conflicts with the coarse-grained authentication strategy, 
> established at the FTC Email Authentication Summit in November
> 2004, as Doug^W Michael recalled >>>
 1. I was making a semantic point, not a technical or technical policy one.
>>> 
>>> They have to match at some point.
>> it would be nice, wouldn't it?
>> but that's separate from the factual statement I made.
> 
> 
> Separate but related.
> 
> 
 2. There was nothing 'established' at that event.  There were interesting 
 discussions, but that's all.
>>> 
>>> 
>>> I wasn't there.  Can't it be considered the historic event that marked 
>>> domain-level authentication as the promising strategy to counter email 
>>> abuse?
>> Reference to that event as if it 'established' anything is misguided, at 
>> best.  The meetings were helpful, but not definitive.  And the efforts at 
>> domain level authentication were wholly independent of these events.
> 
> 
> Would it be still correct to mention that summit as a conspicuous event that 
> testifies the emergence of domain-level authentication around the early 2000s?

As someone who participated in the forum, that is not how I’d characterize it 
at all. You can read 

>> As already noted on this list, the events served as a plea from the 
>> government and, therefore, a signal that the government was concerned.
> 
> A noteworthy historical detail.

Maybe? This was part of the drafting of CAN SPAM. If you look at what CAN SPAM 
was concerned with, authentication didn’t show up. 

> 
> Your gmail address needs to be authenticated by gmail. 
 
 Good grief, no.  There is no system rule to that effect.  DMARC created 
 that, but no policy before it was in place, never mind accepted.
>>> 
>>> 
>>> DMARC took that strategy to the extremes.  A number of users and operators 
>>> seem to have accepted it.  Why cannot we accept it too?
>> That DMARC does something and that some people use it is quite different 
>> from claiming that there was some grand change in the semantics and 
>> operational policy of email.  Why can't THAT be accepted?
> 
> 
> There's been a combination of events, from IETF's reluctant laissez-faire to 
> Yahoo/AOL adoption, which brought up the illusion that email authentication 
> can provide a global means to counter spoofing.  To believe that such 
> illusion will come true makes for a strong motivation.
> 
> Couldn't we meet somewhere halfway?  I can see that you, John, Herr Hammer, 
> and other relevant participants don't accept that domain-level authentication 
> is semantically mandatory.  What d'you reckon about the possibility that such 
> grand semantic change can be made official within the next 10~20 years?  I 
> think that by just spelling the technical means /as if/ such change is going 
> to happen, we can design a consistent authentication protocol.

What issue will only domain-level authentication solve? 

The DMARC proponents have asserted that DMARC prevents domain specific spoofing 
and phishing. The amount of harm DMARC authentication has caused, however, 
seems disproportional to this small benefit. Phishing is still happening using 
cousin domains (and even random domains). Departments inside companies avoid 
DMARC mandates buy buying cousin and “campaign specific” domains which trains 
users to be phishing targets for those domains. Companies have tried to cut 
down on this by saying DMARC must be done for all those domains as well. 
Unfortunately, those “from above” decrees have often created more problems than 
they solved. 

Mailing lists have coped by rewriting from addresses, but that has caused a lot 
of issues. Two of the big ones are members can no longer search for “mail from 
this list member” and cannot easily create filters acting on mail from other 
participants. 

laura 

> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
> whitelisted as yet another domain (songbird.com) can hardly be verified.  
> There is no "pretending", since it's you, but it is not formally 
> distinguishable from spoof, is it?
 
 Whether valid and invalid uses can be distinguished does not alter the 
 fact that valid uses are valid.
>>> 
>>> The problem is to find the technical means that allow receivers and 
>>> recipients to verify such validity.
>> Of course.  But when it's at the expense of valid use that has worked for 45 
>> years, then those means are problematic.  Highly.
> 
> It seems to me most expenses have been paid already, for example this mailing 
> list is applying From: rewriting.  We don't need to propose further 
> restrictions.  To the opposite, there are means on the table[*] that can 
> enable us to sketch a time horizon where

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

[Alessandro Vesely]

On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:


If I put my gmail address into the from field, there is no 
pretending, no matter what platform I am using.



That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November

2004, as Doug^W Michael recalled >>>
1. I was making a semantic point, not a technical or technical 
policy one.


They have to match at some point.


it would be nice, wouldn't it?

but that's separate from the factual statement I made.



Separate but related.


2. There was nothing 'established' at that event.  There were 
interesting discussions, but that's all.



I wasn't there.  Can't it be considered the historic event that 
marked domain-level authentication as the promising strategy to 
counter email abuse?


Reference to that event as if it 'established' anything is misguided, 
at best.  The meetings were helpful, but not definitive.  And the 
efforts at domain level authentication were wholly independent of 
these events.



Would it be still correct to mention that summit as a conspicuous 
event that testifies the emergence of domain-level authentication 
around the early 2000s?



As already noted on this list, the events served as a plea from the 
government and, therefore, a signal that the government was concerned.



A noteworthy historical detail.


Your gmail address needs to be authenticated by gmail. 


Good grief, no.  There is no system rule to that effect.  DMARC 
created that, but no policy before it was in place, never mind 
accepted.



DMARC took that strategy to the extremes.  A number of users and 
operators seem to have accepted it.  Why cannot we accept it too?


That DMARC does something and that some people use it is quite 
different from claiming that there was some grand change in the 
semantics and operational policy of email.  Why can't THAT be accepted?



There's been a combination of events, from IETF's reluctant 
laissez-faire to Yahoo/AOL adoption, which brought up the illusion 
that email authentication can provide a global means to counter 
spoofing.  To believe that such illusion will come true makes for a 
strong motivation.


Couldn't we meet somewhere halfway?  I can see that you, John, Herr 
Hammer, and other relevant participants don't accept that domain-level 
authentication is semantically mandatory.  What d'you reckon about the 
possibility that such grand semantic change can be made official 
within the next 10~20 years?  I think that by just spelling the 
technical means /as if/ such change is going to happen, we can design 
a consistent authentication protocol.



Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?


Whether valid and invalid uses can be distinguished does not alter 
the fact that valid uses are valid.


The problem is to find the technical means that allow receivers and 
recipients to verify such validity.


Of course.  But when it's at the expense of valid use that has worked 
for 45 years, then those means are problematic.  Highly.



It seems to me most expenses have been paid already, for example this 
mailing list is applying From: rewriting.  We don't need to propose 
further restrictions.  To the opposite, there are means on the 
table[*] that can enable us to sketch a time horizon where From: 
rewriting can cease.


16 years have passed since the FTC event, which is 1/3 of those 45. 
What I see looks much like a very mild shift.  Lazy operators have 
plenty of time before the semantic change is established, at some 
point in the medium-term future, if ever.



Best
Ale
--

[*] For MLMs to resume traditional address usage, the most promising 
I-D's is dkim-transform, IMHO.































___
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 16 Aug 2020, at 19:16, John R Levine  wrote:
> 
> On Sun, 16 Aug 2020, Alessandro Vesely wrote:
> If I put my gmail address into the from field, there is no pretending, no 
> matter what platform I am using.
 That conflicts with the coarse-grained authentication strategy, 
 established at the FTC Email Authentication Summit in November
 2004, as Doug^W Michael recalled. >
>>> 1. I was making a semantic point, not a technical or technical policy one.
>> 
>> They have to match at some point.
> 
> Sorry, that's just wrong.  There's no technical reason a mail message can't 
> have any identifiers the sender wants.
> 
>>> 2. There was nothing 'established' at that event.  There were interesting 
>>> discussions, but that's all.
>> 
>> I wasn't there.  Can't it be considered the historic event that marked 
>> domain-level authentication as the promising strategy to counter email abuse?
> 
> No, it was just some political theatre.  We were already working on SPF and 
> DKIM.

I don’t remember much focus on domain-level authentication at the event. 
Authentication was one small piece of the discussion but not even a focus. My 
recollection is that the 3 days were mostly about scoping the spam problem, not 
solving it. 

The forum page is off the FTC website, but the document links are still 
accessible: 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
 



>> DMARC took that strategy to the extremes.  A number of users and operators 
>> seem to have accepted it.  Why cannot we accept it too?
> 
> Please review the previous bazillion messages on this topic.

There’s a difference between accepting it and working around the damage it 
causes to let users continue to use mailing lists. Consumer mailbox providers 
deciding their users couldn’t participate in mailing lists was and is a 
problem. Companies preventing their employees from participating in work 
related forums was and is a problem. 

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