Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/10/20 6:44 PM, Dave Crocker wrote:

On 12/10/2020 6:32 PM, Michael Thomas wrote:

Semantic nit picking at best.


Because semantics do not matter in a specification?


It's ok, I guess but I wouldn't want to make a career of nit picking. 
It's a lot more useful to get intent across of what the actual intent is 
rather than trying to express what is ultimately a code point for a 
filter that doesn't care about the ascii string.


Mike

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 6:32 PM, Michael Thomas wrote:

Semantic nit picking at best.


Because semantics do not matter in a specification?

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Dave Crocker]

On 12/10/2020 6:21 PM, Rich Kulawiec wrote:

but here's a version of it:


Just a thought, but the topic of mailing lists is both on-topic and 
currently being discussed, in the emailcore working group.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 6:25 PM, Michael Thomas wrote:

I think this all should be driven by "what are you asking me to do?"


The domain owner has no business asking the receiver to do anything.  
The receiver has no relationship with the domain owner.


However, the receiver might like to hear the domain owner's opinion 
about usage of the domain when DMARC fails.  But that's different from 
attempting to give direction to the receiver (who demonstrably will 
ignore that direction and make their own decision.)


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
I think that is much closer to the right semantic but highlights a 
problem that the mail coming from a particular domain probably doesn't 
rate a single broad-brush characterization of seriousness. 


I've assumed the none, quarantine, reject choices are meant to indicate 
just how certain the domain owner is that the mail is problematic.


Perhaps:

    none: not certain at all

    quarantine: I believe I've got control of all my sending, but am 
not 100% positive


    reject: I have control of all my sending; if it doesn't pass DMARC, 
it's use of the domain is bogus.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/10/20 6:01 PM, Kurt Andersen (b) wrote:
On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker > wrote:


On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:

to quibble with the "*unauthorized use*"  situation. This
situation devolves into use-as-imagined vs. use-as-really-used
when one considers various intermediary scenarios.


(to respond to the content...)

So, the driving issue is that it's characterizing problematic
usage; use that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the
other possible explanations for failure.

So, without suggesting a label, I'd describe this factor as "how
serious is a failure to get a DMARC pass"?  If that's the right
semantic, what's a reasonable label to use?  If it's not the right
semantic, what is?

I think that is much closer to the right semantic but highlights a 
problem that the mail coming from a particular domain probably doesn't 
rate a single broad-brush characterization of seriousness.


I think this all should be driven by "what are you asking me to do?". 
p=quarantine is asking for a specific thing, but it doesn't seem to mean 
literally what it's asking for. it seems to mean "i'm not comfortable 
with this except in certain situations that i can't enumerate with any 
accuracy". maybe p=quarantine is my "only if you trust the intermediary" 
state I was talking about the other day.


Mike

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Rich Kulawiec]

Yes, they are.  I've been editing a document that lays out some of
the strong arguments in their favor.  It's still a draft (and may
always be because I keep revising it), but here's a version of it:

--

Mailing lists, which were sometimes called "reflectors" in their early
days, are one of the older pieces of Internet technology.  Despite that,
they're still heavily used -- including by the very people who built
and still run the Internet, people who could use anything they wanted.

That's not an accident.  It's because mailing lists have enormous
technical advantages over the alternatives.  Here are some of those:

1. Mailing lists require no special software: anyone with a sensible
mail client can participate.  Thus they allow you to use *your* software
with the user interface of *your* choosing rather than being compelled
to learn 687 different web forums with 687 different user interfaces,
all of which range from "merely bad" to "hideously bad".

2. Mailing lists are simple: learn a few basic rules of netiquette and a
couple of Internet-wide conventions, and one's good to go.  Web forums
are complicated because all of them are different.  In other words,
participating in 20 different mailing lists is just about as easy as
participating in one; but participating in 20 different web forums
is onerous.

3. They impose minimal security risk.

4. They impose minimal privacy risk.

Points 3 and 4 stand in stark contrast to the security and privacy risks
imposed on users of web forums and "social" media, especially the latter.

5. Mailing lists are bandwidth-friendly -- an increasing concern for
people on mobile devices and thus on expensive data plans.  Web forums
are bandwidth-hungry.

6. Mailing lists interoperate.  I can easily forward a message from one
list to another one.  Or to a person.  I can send a message to multiple
lists.  I can forward a message from a person to a list.  And so on.
Try doing this with web forum software A on host B with destinations
web forum software X and Y on hosts X1 and Y1.  Good luck with that.

7. They're asynchronous: you don't have to interact in real time.
You can download messages when connected to the Internet, then read them
and compose responses when offline.

8. As a result of 7, They work reasonably well even in the presence
of multiple outages and severe congestion.  Messages may be delayed,
but once everything's up again, they'll go through.  Web-based forums
simply don't work.

9. They're push, not pull, so new content just shows up.  Web forums
require that you go fishing for it.

10. They scale beautifully.

11. (When properly run) they're relatively free of abuse vectors.
Mailing lists are highly resistant to abuse.  Web forums, because of
their complexity, are highly vulnerable to software security issues
as well as spam/phishing and other attacks.

12. They handle threading well.  And provided users take a few seconds
to edit properly, they handle quoting well.

13. They're portable: lists can be rehosted (different domain, different
host) rather easily.

14. They can be freely interconverted -- that is, you can move a list
hosted by A using software B on operating system C to host X using
software Y on operating system Z.

15. They can be written to media and read from it.  This is a very
non-trivial task with web forums.

16. The computing resources require to support them are minimal -- CPU,
memory, disk, bandwidth, etc.

17. Mailing lists can be uni- or bidirectionally gatewayed to Usenet.
(The main Python language mailing list is an example of this.)  This can
be highly useful.

18. They're easily archivable in a format that is simple and likely to
be readable long into the future.  Mail archives from 10, 20, even 30
or more years ago are still completely usable.  And they take up very
little space.

[ Numerous tools exist for handling Unix "mbox" format: for
example, "grepmail" is a highly useful basic search tool.
Most search engines include parsers for email, and the task
of ingesting mail archives into search engines is very well
understood. ]

19. You can archive them locally...

20. ...which means you can search them locally with the software of
*your* choice.  Including when you're offline.  And provided you make
backups, you'll always have an archive -- even if the original goes away.
Web forums don't facilitate this.

[ Those of us who've been around for a while have seen a lot of
web-based discussions vanish forever because a host crashed or a
domain expired or a company went under or a company was acquired
or someone made a mistake or there was a security breach or a
government confiscated it. ]

There's more, but I think this easily suffices to make a slamdunk case.

Frank Zappa once said that you can't be a real country unless you have
a beer and an airline.  I don't think you can take an organization or
a project seriously unless it has a 

Re: [dmarc-ietf] are mailing lists worth saving?

[Michael Thomas]

So where is the proper place to discuss an ongoing IETF experiment? 
Seems sort of like catch-22.


Mike

On 12/10/20 3:52 PM, Seth Blank wrote:

Michael, Dave, this discussion is off topic.

Please see the Chairs' note here: 
https://mailarchive.ietf.org/arch/msg/dmarc/HhfoBzu_RlM4aiMbiLc4BaHjjmc/ 



There will be a time to discuss indirect mail flow (and if we even 
care about mailing lists) after the core bis tickets are addressed.


Thank you.

Seth, as Chair

On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker > wrote:


On 12/10/2020 3:34 PM, Michael Thomas wrote:
> I'm just making the observation


"Basically just declare" is not a linguistic form for 'just making an
observation'.  It's a proposal.

d/

-- 
Dave Crocker

dcroc...@gmail.com 
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org 

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




--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com 
*p:*415.273.8818


This email and all data transmitted with it contains confidential 
and/or proprietary information intended solely for the use of 
individual(s) authorized to receive it. If you are not an intended and 
authorized recipient you are hereby notified of any use, disclosure, 
copying or distribution of the information included in this 
transmission is prohibited and may be unlawful. Please immediately 
notify the sender by replying to this email and then delete it from 
your system.


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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker  wrote:

> On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
>
> to quibble with the "*unauthorized use*"  situation. This situation
> devolves into use-as-imagined vs. use-as-really-used when one considers
> various intermediary scenarios.
>
> (to respond to the content...)
>
> So, the driving issue is that it's characterizing problematic usage; use
> that did not achieve a DMARC pass.
>
> And, yeah, that doesn't mean the use was unauthorized, given the other
> possible explanations for failure.
>
> So, without suggesting a label, I'd describe this factor as "how serious
> is a failure to get a DMARC pass"?  If that's the right semantic, what's a
> reasonable label to use?  If it's not the right semantic, what is?
>
I think that is much closer to the right semantic but highlights a problem
that the mail coming from a particular domain probably doesn't rate a
single broad-brush characterization of seriousness.

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Seth Blank]

Doug, this thread is off topic. Please disengage.

Seth, as Chair

On Thu, Dec 10, 2020 at 17:58 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> What you miss is that mailing lists are not the whole scope.  All
> forwarding creates trust problems and all modifications by intermediaries
> will cause trust problems.
>
>   Modification is done by many spam filters, and the prevalence of
> modification seems to be increasing.   If any of that traffic is
> auto-forwarded, it also has the mailing list problem.
>
> Reverse transformation may help with the modification problem but it
> cannot help with the larger problems of forwarder trust.  And there are
> many users of forwarding.
>
> A forwarder needs to do more than gain trust that it did nothing
> unacceptable, it also must help the recipient conclude that the originator
> did nothing unacceptable.   We have lacked a strategy for doing this.
>
> Right now, forwarding under SPF and DMARC causes important information to
> be discarded.So they make the forwarding trust problem worse.
> Unverifiable Received entries make the problem even harder.
>
> ARC is a technology which should be able to address the forwarder trust
> problem, whether modification occurs or not.   Whether it currently conveys
> all of the needed information to satisfy recipients must remain to be
> seen.  I do not believe that it does at present, but I believe that it
> could and should.
>
>
> On Thu, Dec 10, 2020, 6:23 PM Michael Thomas  wrote:
>
>>
>> On 12/10/20 2:58 PM, Dave Crocker wrote:
>>
>> On 12/9/2020 3:05 PM, Michael Thomas wrote:
>>
>> we know that amount of traffic going through mailing lists is tiny --
>> like a couple percent.
>>
>>
>> Keeping in mind that mailing lists have been a legitimate
>> Arpanet/Internet email activity since the start of network email and that
>> it is DMARC that created operational problems, rather than mailing list
>> activity creating problems,  the onus for declaring a nearly 50 year
>> activity no longer supported should be pretty compelling.  It should not
>> rely on anecdotes or the views of an isolated few. And it certainly should
>> not justify the change with some broad, cavalier claims about security.
>>
>> For starters:
>>
>>- Please document attacks and other misbehaviors that have been
>>attributed to mailing list operation
>>- Please provide objective, validated documentation for you assertion
>>that the traffic through mailing lists is tiny.
>>- Please include similar substantiation for the percentage claim
>>- Please explain how this type of long-standing legitimate activity
>>can reasonably be otherwise conducted; a generic reference to the web is
>>not sufficient; what is needed is a point-for-point evaluation of mailing
>>list group and technical functionality and an comparison to replacement
>>choices.
>>
>>
>> This assumes that the IETF has any say whatsoever in this matter. It
>> doesn't. DMARC and ADSP before it gives the world the ability to say "i
>> don't care about mailing lists". Apparently Yahoo is one of them. That
>> horse has left the barn. Many domains would rather the security
>> improvements with p=reject. And it's not mailing lists that are the problem
>> per se, it is that the security posture that facilitating them leaves
>> organizations vulnerable to phishing attacks. Many organizations are giving
>> that a nope, and there is nothing we can do about that.
>>
>> There are many things that had their day and died because they couldn't
>> adapt, were redundant, or their time was just over. Usenet is a great
>> example. After 16 years of trying to deal with the mailing list problem,
>> we're right back where we started. Murray's hacks for recovering the
>> signature are not different in kind to my heuristics and hacks I did 15
>> years ago. And ARC seems to boil down to requiring the previously unsolved
>> problem of "trusting" the mailing list.
>>
>> So no, I won't be doing any of those things because they are completely
>> beside the point. Feel free trying your hand solving it.
>>
>> Mike
>> ___
>> 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
>
-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

Re: [dmarc-ietf] are mailing lists worth saving?

[Douglas Foster]

What you miss is that mailing lists are not the whole scope.  All
forwarding creates trust problems and all modifications by intermediaries
will cause trust problems.

  Modification is done by many spam filters, and the prevalence of
modification seems to be increasing.   If any of that traffic is
auto-forwarded, it also has the mailing list problem.

Reverse transformation may help with the modification problem but it cannot
help with the larger problems of forwarder trust.  And there are many users
of forwarding.

A forwarder needs to do more than gain trust that it did nothing
unacceptable, it also must help the recipient conclude that the originator
did nothing unacceptable.   We have lacked a strategy for doing this.

Right now, forwarding under SPF and DMARC causes important information to
be discarded.So they make the forwarding trust problem worse.
Unverifiable Received entries make the problem even harder.

ARC is a technology which should be able to address the forwarder trust
problem, whether modification occurs or not.   Whether it currently conveys
all of the needed information to satisfy recipients must remain to be
seen.  I do not believe that it does at present, but I believe that it
could and should.


On Thu, Dec 10, 2020, 6:23 PM Michael Thomas  wrote:

>
> On 12/10/20 2:58 PM, Dave Crocker wrote:
>
> On 12/9/2020 3:05 PM, Michael Thomas wrote:
>
> we know that amount of traffic going through mailing lists is tiny -- like
> a couple percent.
>
>
> Keeping in mind that mailing lists have been a legitimate Arpanet/Internet
> email activity since the start of network email and that it is DMARC that
> created operational problems, rather than mailing list activity creating
> problems,  the onus for declaring a nearly 50 year activity no longer
> supported should be pretty compelling.  It should not rely on anecdotes or
> the views of an isolated few. And it certainly should not justify the
> change with some broad, cavalier claims about security.
>
> For starters:
>
>- Please document attacks and other misbehaviors that have been
>attributed to mailing list operation
>- Please provide objective, validated documentation for you assertion
>that the traffic through mailing lists is tiny.
>- Please include similar substantiation for the percentage claim
>- Please explain how this type of long-standing legitimate activity
>can reasonably be otherwise conducted; a generic reference to the web is
>not sufficient; what is needed is a point-for-point evaluation of mailing
>list group and technical functionality and an comparison to replacement
>choices.
>
>
> This assumes that the IETF has any say whatsoever in this matter. It
> doesn't. DMARC and ADSP before it gives the world the ability to say "i
> don't care about mailing lists". Apparently Yahoo is one of them. That
> horse has left the barn. Many domains would rather the security
> improvements with p=reject. And it's not mailing lists that are the problem
> per se, it is that the security posture that facilitating them leaves
> organizations vulnerable to phishing attacks. Many organizations are giving
> that a nope, and there is nothing we can do about that.
>
> There are many things that had their day and died because they couldn't
> adapt, were redundant, or their time was just over. Usenet is a great
> example. After 16 years of trying to deal with the mailing list problem,
> we're right back where we started. Murray's hacks for recovering the
> signature are not different in kind to my heuristics and hacks I did 15
> years ago. And ARC seems to boil down to requiring the previously unsolved
> problem of "trusting" the mailing list.
>
> So no, I won't be doing any of those things because they are completely
> beside the point. Feel free trying your hand solving it.
>
> Mike
> ___
> 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] p=quarantine

[Dave Crocker]

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
to quibble with the "*unauthorized use*"  situation. This situation 
devolves into use-as-imagined vs. use-as-really-used when one 
considers various intermediary scenarios.


(to respond to the content...)


So, the driving issue is that it's characterizing problematic usage; use 
that did not achieve a DMARC pass.


And, yeah, that doesn't mean the use was unauthorized, given the other 
possible explanations for failure.


So, without suggesting a label, I'd describe this factor as "how serious 
is a failure to get a DMARC pass"?  If that's the right semantic, what's 
a reasonable label to use?  If it's not the right semantic, what is?



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:

but I'd have to quibble with the "*unauthorized use*"  situation.


please do quibble. or more.

I intended the text to prime the pump, and don't have any expectation is 
is already perfect.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker  wrote:

> It might be worth a bit of thinking about what, exactly, DMARC can
> reasonably do and how it should be summarized, for popular consumption:
>
> *Alignment - *DMARC defines a basis for authenticating use of the domain
> name in the rfc5322.From addr-spec.  (But nothing else in that header field
> or elsewhere in the message, neither header nor body.
>
> *Severity of unauthorized use - *DMARC provides a means of indicating to
> receivers how serious the domain owner considers unauthorized use of that
> domain name to be.
>
> *Reporting -* DMARC defines a mechanism for reporting DMARC-related
> activity by a receiver
>
> I've tried to state each of these precisely and accurately, in terms of
> real-world pragmatics.
>
These seem like a good starting point, but I'd have to quibble with
the "*unauthorized
use*"  situation. This situation devolves into use-as-imagined vs.
use-as-really-used when one considers various intermediary scenarios. Does
a domain owner really have the prerogative to define recipient behaviour as
"unauthorized"?

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

Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110

[Kurt Andersen (b)]

I'm wondering why we should wait for IETF110 rather than having an interim
meeting sooner. Interim meetings are also likely to garner greater
participation since they do not include participation fee. If there are
topics worthy of F2F discussion, why wait? If there are not, then why
charge people to join a pointless meeting?

--Kurt

On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool <
session-requ...@ietf.org> wrote:

>
>
> A new meeting session request has just been submitted by Alexey Melnikov,
> a Chair of the dmarc working group.
>
>
> -
> Working Group Name: Domain-based Message Authentication, Reporting 
> Conformance
> Area Name: Applications and Real-Time Area
> Session Requester: Alexey Melnikov
>
>
> Number of Sessions: 1
> Length of Session(s):  1 Hour
> Number of Attendees: 76
> Conflicts to Avoid:
>  Chair Conflict: dnsop dprive cfrg kitten emailcore
>  Technology Overlap: saag uta extra jmap cbor
>
>
>
>
>
>
> People who must be present:
>   Alexey Melnikov
>   Murray Kucherawy
>   Tim Wicinski
>   Seth Blank
>
> Resources Requested:
>
> Special Requests:
>
> -
>
>
> ___
> 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] are mailing lists worth saving?

[Dave Crocker]

On 12/10/2020 3:52 PM, Seth Blank wrote:

Michael, Dave, this discussion is off topic.


oops. ack. sorry. d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Michael Thomas]

On 12/10/20 3:45 PM, Dave Crocker wrote:

On 12/10/2020 3:34 PM, Michael Thomas wrote:
I'm just making the observation 



"Basically just declare" is not a linguistic form for 'just making an 
observation'.  It's a proposal.



A proposal that we face reality? I suppose in an odd sense of the word. 
Unless you have a different means of avoiding that fate after 16 years 
with a technical solution that has eluded everybody else, then nature 
will just take its course with more and more organizations setting up 
p=reject making it harder and harder to use mailing lists.


As far as this working group goes, it seems the charter already takes 
this into account. ARC provides the fig leaf and DMARC is just getting 
cleaned up as the charter said to.


Mike

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Seth Blank]

Michael, Dave, this discussion is off topic.

Please see the Chairs' note here:
https://mailarchive.ietf.org/arch/msg/dmarc/HhfoBzu_RlM4aiMbiLc4BaHjjmc/

There will be a time to discuss indirect mail flow (and if we even care
about mailing lists) after the core bis tickets are addressed.

Thank you.

Seth, as Chair

On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker  wrote:

> On 12/10/2020 3:34 PM, Michael Thomas wrote:
> > I'm just making the observation
>
>
> "Basically just declare" is not a linguistic form for 'just making an
> observation'.  It's a proposal.
>
> d/
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] are mailing lists worth saving?

[Dave Crocker]

On 12/10/2020 3:34 PM, Michael Thomas wrote:
I'm just making the observation 



"Basically just declare" is not a linguistic form for 'just making an 
observation'.  It's a proposal.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Michael Thomas]

On 12/10/20 3:25 PM, Dave Crocker wrote:

On 12/10/2020 3:23 PM, Michael Thomas wrote:
So no, I won't be doing any of those things because they are 
completely beside the point. Feel free trying your hand solving it.


Yet you were the one making the proposal and making claims as 
foundational to it.


I don't need to prove anything here. I'm just making the observation 
that after 15 years we still don't know how to solve the mailing list 
problem so I'm going to assume that we never will. We don't even know 
how to declare victory. Every time I've asked that it's met with "good 
question".  Ditto the mailing list trust problem.


Mike

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Michael Thomas]

On 12/10/20 3:23 PM, Dave Crocker wrote:

On 12/10/2020 3:17 PM, John Levine wrote:

People at very large mail systems tell me that while the amount of
traffic from discussion lists is a tiny part of the overall mail flow,
it is mail that their recipients really want and complain if they
don't get.


The relates to my point about getting community consensus...

There is no consensus to be had. IETF has no say in this matter. Reddit 
is a terrible Usenet 2.0, but that's what happened when Usenet couldn't 
keep up with the times.


Mike

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Dave Crocker]

On 12/10/2020 3:23 PM, Michael Thomas wrote:
So no, I won't be doing any of those things because they are 
completely beside the point. Feel free trying your hand solving it.


Yet you were the one making the proposal and making claims as 
foundational to it.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Dave Crocker]

On 12/10/2020 3:17 PM, John Levine wrote:

People at very large mail systems tell me that while the amount of
traffic from discussion lists is a tiny part of the overall mail flow,
it is mail that their recipients really want and complain if they
don't get.


The relates to my point about getting community consensus...

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Michael Thomas]

On 12/10/20 2:58 PM, Dave Crocker wrote:

On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- 
like a couple percent.



Keeping in mind that mailing lists have been a legitimate 
Arpanet/Internet email activity since the start of network email and 
that it is DMARC that created operational problems, rather than 
mailing list activity creating problems,  the onus for declaring a 
nearly 50 year activity no longer supported should be pretty 
compelling.  It should not rely on anecdotes or the views of an 
isolated few. And it certainly should not justify the change with some 
broad, cavalier claims about security.


For starters:

  * Please document attacks and other misbehaviors that have been
attributed to mailing list operation
  * Please provide objective, validated documentation for you
assertion that the traffic through mailing lists is tiny.
  * Please include similar substantiation for the percentage claim
  * Please explain how this type of long-standing legitimate activity
can reasonably be otherwise conducted; a generic reference to the
web is not sufficient; what is needed is a point-for-point
evaluation of mailing list group and technical functionality and
an comparison to replacement choices.


This assumes that the IETF has any say whatsoever in this matter. It 
doesn't. DMARC and ADSP before it gives the world the ability to say "i 
don't care about mailing lists". Apparently Yahoo is one of them. That 
horse has left the barn. Many domains would rather the security 
improvements with p=reject. And it's not mailing lists that are the 
problem per se, it is that the security posture that facilitating them 
leaves organizations vulnerable to phishing attacks. Many organizations 
are giving that a nope, and there is nothing we can do about that.


There are many things that had their day and died because they couldn't 
adapt, were redundant, or their time was just over. Usenet is a great 
example. After 16 years of trying to deal with the mailing list problem, 
we're right back where we started. Murray's hacks for recovering the 
signature are not different in kind to my heuristics and hacks I did 15 
years ago. And ARC seems to boil down to requiring the previously 
unsolved problem of "trusting" the mailing list.


So no, I won't be doing any of those things because they are completely 
beside the point. Feel free trying your hand solving it.


Mike

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

Re: [dmarc-ietf] are mailing lists worth saving?

[John Levine]

In article  you write:
>-=-=-=-=-=-
>
>On 12/9/2020 3:05 PM, Michael Thomas wrote:
>> we know that amount of traffic going through mailing lists is tiny -- 
>> like a couple percent.

People at very large mail systems tell me that while the amount of
traffic from discussion lists is a tiny part of the overall mail flow,
it is mail that their recipients really want and complain if they
don't get. That is unlike commercial bulk mail, which recipients don't
mind but wouldn't miss.

The mail providers didn't invent ARC because they were bored and had
too much spare time. It was because it addresses a real problem they
have.

R's,
John

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

Re: [dmarc-ietf] are mailing lists worth saving?

[Dave Crocker]

On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- 
like a couple percent.



Keeping in mind that mailing lists have been a legitimate 
Arpanet/Internet email activity since the start of network email and 
that it is DMARC that created operational problems, rather than mailing 
list activity creating problems,  the onus for declaring a nearly 50 
year activity no longer supported should be pretty compelling.  It 
should not rely on anecdotes or the views of an isolated few. And it 
certainly should not justify the change with some broad, cavalier claims 
about security.


For starters:

 * Please document attacks and other misbehaviors that have been
   attributed to mailing list operation
 * Please provide objective, validated documentation for you assertion
   that the traffic through mailing lists is tiny.
 * Please include similar substantiation for the percentage claim
 * Please explain how this type of long-standing legitimate activity
   can reasonably be otherwise conducted; a generic reference to the
   web is not sufficient; what is needed is a point-for-point
   evaluation of mailing list group and technical functionality and an
   comparison to replacement choices.

Once these documentation details have been lined up and have obtained 
meaningful community support, it might be worth pursuing the 
de-legitimization of Internet mailing lists.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/9/20 10:28 PM, seth=40valimail@dmarc.ietf.org wrote:
> As an individual, I feel extremely strongly that failure reports should go 
> away in their entirety. Although Jesse Thompson has outlined a use case that 
> really has no other good solution, and is equally true in other large 
> complicated organizations. However, this problem is mitigated with a tree 
> walk, where you can get the reports to the appropriately localized part of 
> the organization (like, math.wisc.edu , instead of to 
> Jesse at wisc.edu  who'd need to hunt things down).

To be clear, I'm not advocating for this From/To use case, but I know of 
universities who would.  There's at least one who cleverly flattened their SPF 
record to include every known sender specifically because they had no mission 
to change the way their institution distributively sends email.  That is the 
type of organization who *may* want From/To data, assuming they want to do more 
validation before adding yet another IP to their SPF.  It's a stretch in my 
mind.

I would only strongly advocate for seeing the unredacted From header, since my 
primary concern was with identifying a little bit more information about who 
was using the domain and why (i.e. who is using random ESP). 

The stated purpose of Failure Reports is "for quickly notifying the Domain 
Owners when there is an authentication failure ... also provide more 
information about the failed message than is available in an aggregate report". 
 Since the focus of DMARC is to authorize the use of the domain used in the 
From header, then the logical next incremental levels of "more information" 
should be:

1) From header domain (already known)
2) local part of From address
3) Friendly From
4) Subject
5) other parts of the message containing identifiable information

1->5 decreases in usefulness/relevancy to DMARC
1->5 increases in unnecessary information disclosure

Jesse

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/9/20 6:12 PM, Brandon Long wrote:
> At best, we considered allowing RUF reports for cases where the dmarc domain 
> was the receiver, ie if someone had a message that failed dmarc while sending 
> to the same domain, then presumably the domain admin already has the power to 
> view the message.
> 
> But, if you limit it to that level, then the domain admin could already 
> theoretically do this themselves by having those messages delivered to some 
> destination to look at them, or setting
> up their own forwarding rule to their dmarc analysts.

I agree with this.  With senders that have a relatively large volume, there is 
a very high probability that at least one of the recipients is local.  Most of 
the necessary information is probably already available in logs.

Jesse

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Alessandro Vesely]

On Thu 10/Dec/2020 05:28:55 +0100 Seth Blank wrote:

On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy wrote:

On Wed, Dec 9, 2020 at 1:29 PM Brandon Long wrote:


In today's much more privacy conscious world, should we have RUF reports
in DMARC at all?


[...]
Seems to me that's still a useful thing to have, at least sometimes.  We
might say something like: Include support for this, but don't have it on by
default.  Or even if it's an extension to DMARC and not part of the base
protocol, it might be really helpful in some situations.



Can we be explicit about that?  I mean to suggest to develop but not to enable. 
 Furthermore, I'd recommend to develop options to enable failure reports on a 
per-domain basis.  (We could also mention that admins may contact the email in 
the  section of troublesome aggregate reports to ask for 
failure reports to be enabled for their domain for the time necessary to solve 
the problem at hand.)




As an individual, I feel extremely strongly that failure reports should go
away in their entirety.



Could we at least limit them to a single, must-be-aligned recipient?



For this ticket in particular-- the simplified failure report with only
from: and to: addresses speaks to Jesse's exact use case, without any of
the other PII that tends to get failure reports in privacy trouble (like
body content and attachments). This approach to Jesse's use case should get
a fair discussion, separate from whether we want failure reports at all.



I would suggest to redact the local parts of To:, Cc: and similar fields 
(X-Original-To:, Received: for), possibly leaving only the From: intact. 
Delivered-To: should be removed.  The rest of the header can be sent safely, 
methinks.



Best
Ale
--




















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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Alessandro Vesely]

On Thu 10/Dec/2020 02:23:10 +0100 Michael Thomas wrote:

On 12/9/20 4:04 PM, Brandon Long wrote:


When you switch to p=quarantine pct=0, no one should apply quarantine (so 
it's equivalent to p=none), but Groups will start rewriting, thereby removing 
all of those failures from your reports.  Yes, you won't see those messages 
in the reports at all anymore because they are no longer using your domain.



There is a reporting feature of mlm-transform that might be worth considering 
apart from any indirect mailflow revival.  By adding an Original-From: header 
field —a copy of From: on the first relay— a domain owner can ask to receive 
aggregate reports even if From: was rewritten by a MLM.



Is that what's going on with some of the messages I see on this list? That 
seems pretty awful from a security standpoint. Basically you're engineering a 
lookalike From address attack. The one big disappointment from my standpoint is 
that MUA's don't seem to be using auth-res, etc, to do some basic annotation. 
At least Thunderbird.



You need to install DKIM Verifier[*].  It reads A-R and displays some results.


Best
Ale
--

[*] https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/




























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

Re: [dmarc-ietf] A-R results for DMARC

[Alessandro Vesely]

On Thu 10/Dec/2020 00:37:19 +0100 Brandon Long wrote:

On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas  wrote:

On 12/8/20 4:51 PM, Brandon Long wrote:
On Mon, Dec 7, 2020 at 8:31 PM John R Levine  wrote:

On Mon, 7 Dec 2020, Murray S. Kucherawy wrote:

The original intent back in RFC 5451 was to relay only those details
that an MUA might care about, such as the DKIM result (so you can
display something representing a "pass" or "fail" on a message) and
maybe the domain name found in a passing signature (an early shot at
caring about alignment when rendering a message). ... >>>

I suppose but 5451 also says it might be useful to message filters.


Right, there are clearly MUAs that do some amount of spam filtering, so 
disposition of p=quarantine would seem to be useful for that. >>
Is there any evidence for that though? I would assume that the folks on 
this list use a diverse set of MUA's and would be in a position to tell

us if some of them do. >

Gmail does put messages with disposition quarantine into the spam label, but
we don't rely on the A-R header to pass that information from the smtp 
transaction to the mailbox.


As an SMTP filter, zdkimfilter can reject, but it cannot quarantine.  That is 
MDA's territory.  It passes quarantine information in an A-R comment[*].  If 
there was a standard way to convey that info, it could be used by MUAs as well 
as by any other software not specifically designed around zdkimfilter's 
idiosyncrasies.



Best
Ale
--

[*] https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#dmarcand

























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