Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"

[John Levine]

In article <01d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> you write:
>The author fails to recognize that we have a single-author email
>architecture.  Consequently, the last entity to alter the message IS the
>author.

Sorry, but no.  The structure of Internet mail is quite clear, and that's not 
it.

I can belive there are people who wish it were like that, but no.

R's,
John

___
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

[John R Levine]

I do think that sometimes people don’t take p=reject seriously enough, and 
don’t realize how much time and monitoring and prep it takes. I mostly work 
with smaller entities but I advise staying at  p=none of the time unless 
there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take 
action if and only if there’s a problem.


Completely agree.  I have 240,000 aggregate and 80,000 failure reports in 
my database and I'm still publishing p=none for all my domains that 
actually send mail.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
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

[Neil Anuskiewicz]

> On Aug 7, 2020, at 12:12 PM, John Levine  wrote:
> 
> In article 
> 
>  you write:
>> I feel like what is happening sometimes is that central university IT is 
>> trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully 
>> understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.
> 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.
> 
> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.
> 
> R's,
> John
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

When mail breaks it’s more than an inconvenience. In business it can materially 
affect people’s livelihoods.

 I do think that sometimes people don’t take p=reject seriously enough, and 
don’t realize how much time and monitoring and prep it takes. I mostly work 
with smaller entities but I advise staying at  p=none of the time unless 
there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take 
action if and only if there’s a problem. 

I do get the instinct to be proactive but if you’re going to be proactive, get 
ready to take the time and, if outside help needed, the money to do it without 
breaking legit mail. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"

[Doug Foster]

-1
A vote against the proposal in the strongest possible  terms.

About the Analysis:

Quote
Internet mail defines the RFC5322.From field to indicate the author of the
message's content and the RFC5322.Sender field to indicate who initially
handled the message...  This was not a problem, until development of
stringent protections on use of the RFC5322.From field.  It has prompted
Mediators, such as mailing lists, to modify the RFC5322.From field, to
circumvent mail rejection caused by those protections.

Comment
The author fails to recognize that we have a single-author email
architecture.  Consequently, the last entity to alter the message IS the
author.  An altered message can be compared to a Hollywood movie that is
"inspired by real events."   The delivered message probably has a connection
to what the originator wrote, but the nature of that connection is unknown
to the recipient.   DMARC forces the true author (the mailing list) to take
ownership of its work by using a From address in its own domain. 

Quote
This affects end-to-end behavior of email, between the author and the final
recipients, because mail from the same author is not treated the same,
depending on what path it followed.  In effect, the RFC5322.From field has
become dominated by its role as a handling identifier.

Comment
This is factually wrong.  The path that a message follows has always been of
interest, because the reputation of each handler is relevant to the risk
associated with the received document.  DKIM signatures provided a
technology to address this problem.   If and only if a DKIM signature can be
verified, then the receiver can conclude that the path is irrelevant to
message risk.   For the problem at hand, messages are assumed to originate
with a valid signature, so path would not matter if the document was not
altered.   It is the mailing list action to alter the message which alters
the risk profile of the message, not the path followed. 

Document alteration is an inherently untrusted activity.  The ability to
make constructive changes is also the ability to make malicious changes.
The ability to make changes is also the ability to create entirely new
messages, because a new message could be fabricated to look like a forwarded
message if it was advantageous to an attacker to do so.   Mailing lists want
recipient systems to conclude that the mailing list will only make
constructive changes.   This is an administrative decision which cannot be
obtained from the document itself.   It must be obtained using an
out-of-band process, and it must be obtained from each recipient, or from
the originator domain using a process that each recipient domain will trust.
   
This document proposes a way for recipient domains to authorize exactly what
mailing lists wish to do.  The proposed protocol would grant that trust if
both originating and sending domains choose to participate.   But the stated
path sensitivity is a misrepresentation of the situation.

Quote
The current specification augments use of the RFC5322.From field, by
enhancing DMARC to also use the RFC5322.Sender field.  This preserves the
utility of RFC5322.From field while also preserving the utility of DMARC.

Comment
As we shall see, this proposal has the effect of rolling back DMARC, not
preserving it, for any domains that choose to enroll in it.

Quote
Because the current email protection behavior involves the RFC5322.From
field, and pertain to the human author, it is common to think that the
issue, in protecting the field's content, is behavior of the human
recipient.  However there is no indication that the enforced values in the
RFC5322.From field alter end-user behavior.  In fact there is a long train
of indication that it does not.  Rather, the meaningful protections actually
operate at the level of the receiving system's mail filtering engine, which
decides on the
disposition of received mail.

Comment
This assertion is based on the author's inability or unwillingness to
distinguish between an author identifier and a trust indicator about
authorship identifier.  The From address is an identifier which indicates
the entity which is supposedly responsible for the content.  The reliability
of that assertion is affected by whether the connection between the author
and the document can be verified by a mechanism such as DMARC.   A trust
indicator is a symbol or text phrase which indicates whether verification
has been successful or not.   As discussed in the WG, trust indicators have
some effect on user behavior, but not the dramatic effect one might hope
would occur.  This means that the user tends to believe that the From
address is valid, whether the trust indicator is present or not.  It does
not mean that the From address has no relevance to the user.   In general,
the user expects that the From address will be the Reply-To recipient.  A
user would be surprised and alarmed to reply to a message using the From
address, and then learn that the reply made no s

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

[John Levine]

In article <0c8afc68-bc51-702a-c794-610b2d355...@dcrocker.net> you write:
>Here's why I think it won't:  They already have From:.

I was going to answer but Steve Atkins said it better.

Let's work on your Sender draft which doesn't try to change what MUAs display.

R's,
John

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

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

[Steve Atkins]

On 12/08/2020 04:32, Dave Crocker wrote:


Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but 
in having a required field that cites the originating domain name.  
That doesn't change if there are additional fields that might or might 
not mention the originating domain.


I think we disagree on the goal of DMARC. The entire point of DMARC is 
brand protection. Control over what is displayed to the user, not what's 
in any particular header. You could use it for other things, but that's 
what informed publishers of DMARC say they're using it for (sometimes 
phrased as "protection against phishing" but that too is all about 
what's displayed to the recipient).


If you display the contents of Author to the user, then DMARC publishers 
will want to control that.


If MUAs will display the contents of the Author: header where the From: 
header is now then draft-crocker-dmarc-author-00 effectively moves what 
used to be Sender: header to the From: header and what used to be the 
From: header to the Author: header.


You could achieve exactly the same result, with much less deployment 
effort, by updating DMARC to enforce the Sender header and leaving MUAs 
displaying the From: header. That wouldn't be acceptable to anyone who 
wants to publish DMARC, so the Author: proposal won't be either.


Cheers,
  Steve

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

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

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker  wrote:

> On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote:
> > IETF are more relaxed than I expected.
>
> Don't believe it.  The advice was warranted.
>
> Well, it's good to mostly lurk for a while as a courtesy unless and until
I have something useful to contribute. I will say if there's help needed
with writing an FAQ, a RFP, or something else entirely that would be
useful, I'm willing to help.

My experience with DMARC has been hands-on implementation so thinking about
the protocol and how to make it better is new ground. I have idea if I'll
have any insight. I'll try to learn enough to contribute through lurking.


> d/;
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote:

IETF are more relaxed than I expected.


Don't believe it.  The advice was warranted.

d/;

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker  wrote:

> On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> >
> >
> > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  > > wrote:
> >
> > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> >  > Mr. Crocker, is there a document that describes some of these
> > proposals
> >  > and perhaps the best arguments for an against somewhere? The
> > firehose of
> >  > learning would a bit easier if there were a FAQ. I think it might
> > even
> >  > help the participants if this was all documented. Yes, I know
> > there's
> >  > the archived but I mean an organized and linear doc.
> >
> >
> >
> > If you have particular questions, ask them.
> >
> >
> > I've just recently started lurking but I think this is a discussion
> > about semantics. What to call a proposed RFC5322.Sender field.
>
> The reference to field name was for an alternative to the rfc5322.From
> field, not sender.
>
>
> > The problem being addressed is the munging of headers by mailing lists
> > and other forwarders, breaking things like DKIM.
>
> mailing lists pretty much always break DKIM.  One of the proposals is to
> try to recover signature validation, post hoc.
>
> > I've not been lurking long enough to grok what's going on but I'll
> > continue to lurk and learn, eventually finding a small way to contribute
> > to this effort even if it's just to sweep out the IETF Ashram. :-)
>
>
> Welcome aboard.
>
> Thank you. That was a warm welcome. The guy who recommended this list to
me suggested I lurk for like a year or get eaten alive. IETF are more
relaxed than I expected.


> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker  wrote:

> On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> >
> >
> > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  > > wrote:
> >
> > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> >  > Mr. Crocker, is there a document that describes some of these
> > proposals
> >  > and perhaps the best arguments for an against somewhere? The
> > firehose of
> >  > learning would a bit easier if there were a FAQ. I think it might
> > even
> >  > help the participants if this was all documented. Yes, I know
> > there's
> >  > the archived but I mean an organized and linear doc.
> >
> >
> >
> > If you have particular questions, ask them.
> >
> >
> > I've just recently started lurking but I think this is a discussion
> > about semantics. What to call a proposed RFC5322.Sender field.
>
> The reference to field name was for an alternative to the rfc5322.From
> field, not sender.
>
> Ah, an alternative way for DMARC to come into alignment: RFC5322.Sender
== RFC5322.From so if tag is present permitting this alternative means of
alignment. With the tag present, the receiving system checks the DNS
of the RFC5322.Sender
domain. If the tag isn't present, it's business as usual.

My opinion is that having more ways to come into alignment available's a
good thing. I work mostly with small businesses that don't have zillions of
mail streams and moving parts. But DMARC sometimes finds rogue senders
within the organization (The Toledo office decided to do their own
marketing or Bob in sales is gonna make everything happen), legit senders
who aren't authenticated, mail streams everyone forgot about, and,
occasionally spoofers.

Even with a small business, turning the policy knob above none is
unnerving, especially if there's less than perfecto authentication across
the board on legit sources. I rarely go above none anyway but I do like the
option.



> > The problem being addressed is the munging of headers by mailing lists
> > and other forwarders, breaking things like DKIM.
>
> mailing lists pretty much always break DKIM.  One of the proposals is to
> try to recover signature validation, post hoc.
>
> > I've not been lurking long enough to grok what's going on but I'll
> > continue to lurk and learn, eventually finding a small way to contribute
> > to this effort even if it's just to sweep out the IETF Ashram. :-)
>
>
> Welcome aboard.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:



On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > wrote:


On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
 > Mr. Crocker, is there a document that describes some of these
proposals
 > and perhaps the best arguments for an against somewhere? The
firehose of
 > learning would a bit easier if there were a FAQ. I think it might
even
 > help the participants if this was all documented. Yes, I know
there's
 > the archived but I mean an organized and linear doc.



If you have particular questions, ask them.


I've just recently started lurking but I think this is a discussion 
about semantics. What to call a proposed RFC5322.Sender field.


The reference to field name was for an alternative to the rfc5322.From 
field, not sender.



The problem being addressed is the munging of headers by mailing lists 
and other forwarders, breaking things like DKIM.


mailing lists pretty much always break DKIM.  One of the proposals is to 
try to recover signature validation, post hoc.


I've not been lurking long enough to grok what's going on but I'll 
continue to lurk and learn, eventually finding a small way to contribute 
to this effort even if it's just to sweep out the IETF Ashram. :-)



Welcome aboard.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  wrote:

> On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> > Mr. Crocker, is there a document that describes some of these proposals
> > and perhaps the best arguments for an against somewhere? The firehose of
> > learning would a bit easier if there were a FAQ. I think it might even
> > help the participants if this was all documented. Yes, I know there's
> > the archived but I mean an organized and linear doc.
>
>
>
> If you have particular questions, ask them.
>

I've just recently started lurking but I think this is a discussion about
semantics. What to call a proposed RFC5322.Sender field.

The problem being addressed is the munging of headers by mailing lists and
other forwarders, breaking things like DKIM.

I've not been lurking long enough to grok what's going on but I'll continue
to lurk and learn, eventually finding a small way to contribute to this
effort even if it's just to sweep out the IETF Ashram. :-)

> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
Mr. Crocker, is there a document that describes some of these proposals 
and perhaps the best arguments for an against somewhere? The firehose of 
learning would a bit easier if there were a FAQ. I think it might even 
help the participants if this was all documented. Yes, I know there's 
the archived but I mean an organized and linear doc.



There is a small number of Internet Drafts.  Each of them explains 
themselves, well or poorly.


This kind of work is early-stage development and requires participants 
to be actively engaged in that development.  FAQs, for example, come 
later, for wider consumption.


If you have particular questions, ask them.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Neil Anuskiewicz]

Mr. Crocker, is there a document that describes some of these proposals and
perhaps the best arguments for an against somewhere? The firehose of
learning would a bit easier if there were a FAQ. I think it might even help
the participants if this was all documented. Yes, I know there's the
archived but I mean an organized and linear doc.

On Tue, Aug 11, 2020 at 8:32 PM Dave Crocker  wrote:

>
> >> I was quite surprised -- at the level of astonished -- to see the
> >> pushback on the Author header-field proposal, since it is such a simple
> >> and straightforward mechanism.
> >
> > The different bits in the message are simple enough.
> >
> > The problem is that it might as well be called Really-From, and then
>
> Your opening item is that you don't like the name of the field?
>
> In any event, I suggested "Author" because it is simple and accurate.
> Something like what you suggest - on the off-chance you are serious --
> offers distracting tone and baggage.
>
>
> > when enough systems do mutant DMARC to cause the same problems with
> > Really-From that we have with From,
>
> That's a premise with no foundation and arguably no validity.
>
> At the least, if you are going to use this as the substance of your
> concern, perhaps you could explain with some care why you are so certain
> this will happen.
>
> Here's why I think it won't:  They already have From:.
>
> The real value in DMARC is not what is displayed to the end-user but in
> having a required field that cites the originating domain name.  That
> doesn't change if there are additional fields that might or might not
> mention the originating domain.
>
>
> > the step after that is
> > Really-Really-From, so on ad nauseam. While that happens (or maybe
> > doesn't) we have no idea whether MUAs will display it or let you enter
>
> The question of whether any MUAs will implement this is the same concern
> for any proposal.  So on its own, that would mean we never do anything
> unless implementers and operators promise to use it.  Absent an IETF
> formal policy to that end...
>
>
> > it or automatically make it the same as From or maybe something else,
> > likely making it a disaster for interoperability.
> >
> > I think the DMARC sender draft is a lot more promising.
>
> It has it's own problems.
>
> There's no perfection here, since the task is retro-fitting work-arounds
> to an established mechanism that has been altered.  As I've noted,
> realistically, DMARC makes the From: field be the Sender: field.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> 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