Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dotzero]

On Wed, Jun 24, 2020 at 9:43 AM  wrote:

> Hi,
>
> just answering this one bit, which I believe is at the heart of the
> disagreement:
>
> 
>
> IMHO "phishing and spam messages" is way too broad a concept to permit
> useful discussion. DMARC nowadays addresses a whole range of problems of
> varying severity to the end user.
>

I'm curious, could you please provide us with the " whole range of
problems" which you believe DMARC addresses? As far as I know, it only
addresses the problem of direct domain abuse, nothing more and nothing less.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[devel2020]

Hi,

just answering this one bit, which I believe is at the heart of the 
disagreement:


Le 22/06/2020 à 21:44, Brandon Long a écrit :


[...]  It's the majority which are 
routinely subjected
to phishing and spam messages... 


IMHO "phishing and spam messages" is way too broad a concept to permit 
useful discussion. DMARC nowadays addresses a whole range of problems of 
varying severity to the end user.


When protecting security-sensitive domains like banks, where phishing is 
a major threat to the end user, a fail-closed policy is a necessity, and 
incompatibility with some uses is acceptable.


However, mailboxes with no special security needs call for a different 
tradeoff. From the end user's point of view, spam or addressbook-based 
phishing attempts are small annoyances that they somehow deal with 
(otherwise, they couldn't be using e-mail today). The goal here is an 
incremental win over an acceptable statu quo, not a revolution. No 
legitimate communication should thus be made to ressort to tedious 
workarounds to send mail (mailing-list users having to send every 
message twice, really?) or to find out who said what.


Cheers,
Baptiste

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dotzero]

On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker  wrote:

>
> When first specified, Sender: was to cover the case of someone doing the
> online work, on behalf of  authors who weren't online, or at least not
> online for processing the message.  Back in those days, that was not
> uncommon.  Even if the author officially had an online presence, they
> often did not do the typing.
>
> It's important to note that in those times the "Sender:" was almost
certainly in the same organization/location/address/namespace as the
author. If that were still true today we wouldn't be having this discussion
because the RH side of the email addresses would align.


> For most email, From: and Sender: are the same person (and the same
> email address.)  This fact was the reason the original specification of
> Sender: in RFC 733 only required an explicit Sender: field be present
> when the addresses are different.
>
> For today, these same abstract constructs have -- or should have -- only
> slightly different application.  From: is still supposed to be the
> author, which remains the creator of the (original) content.  Sender:
> could be any separate party responsible for processing the message


"Processing"? That covers a whole lot more than sending. A security
appliance "processes" the message but is clearly not the Sender.

> .
>
> So, in abstract terms, if I go to a greeting card site and have it send
> a greeting on my behalf, the From: field should be my own email address
> and Sender: should an address at the greeting card company.  But I said
> 'abstract' because current realities mean this isn't as useful an
> arrangement as the theory intended.
>

Now you are in a space I know a tiny bit about. There's a little bit of
history here, starting with the  FTC spam workshop in 2003 and the FTC
email authentication workshop in 2004 we saw a lot of changes starting to
occur in the email authentication space. The FTC was forcing things by
indicating that if the private sector didn't come up with solutions, the
FTC was going to regulate. SPF took a spot in the limelight and DK and IIM
were merged to create DKIM. A number of people on this list were involved
in all the happenings. Anyways, I wrote a 46 page document for internal
consumption at the greeting card company I worked for. At the time, pretty
much all greeting card companies sent email in the manner you describe
except that many didn't even bother with Sender... and the emails typically
got through to the recipient. In my analysis, I posited that there would be
drastic changes coming in practices for greeting card sites along with news
sites (share with a friend) or sites that had a refer a friend function
(and which typically sent the email using the email address of the person
doing the referring on the theory it would result in more opens. In any
event, my thesis was that all of these types of websites would have to
start sending emails as themselves rather than using an email address not
their own. This was specifically linked to these nascent email
authentication efforts. In 2007, the Storm Worm started spewing "greeting
card notifications" (along with other sites) purporting to be from a
variety of greeting card sites. The volume of these sends was orders of
magnitude greater than any greeting card site was sending itself. This
caused management to ask me what could be done about this problem. We
implemented changes like strict SPF and DKIM across the board for all our
end user facing websites (mail), moving all our employees (with the
exception of role accounts and a handful of user accounts that responded
directly to end users or partners and publicizing to receiving domains and
security companies what we were doing and that if mail claiming to be from
our domains failed to pass either SPF or DKIM, throw it away. Absent the
feed back loop and the formal definitions in the standard, this is the
essence of DMARC. If someone cares to look back in the DKIM-OPS list from
that time frame you can find posts from me making those assertions.

At roughly the same timeframe, Pat Peterson, who was still at IronPort,
organized a small group of senders (mostly financials and a greeting card
company), a couple intermediaries (like ReturnPath and eCert) and some
major receiving sites (like Yahoo! and AOL). PayPal and Yahoo! at the time
were working on a private peering solution which was successful. This all
eventually became the DMARC "team" and later dmarc.org. It is important to
remember that both SPF and DKIM function at the domain level, not the
individual account level (with the exception of edge cases like a domain
which is a personal domain with a single user account). Yes, there was the
d= vs i= debate with DKIM... and i= lost out in practice.

Today you won't find any (major) greeting card site sending email in the
way you describe. This isn't because they wanted to change. It's because
they were forced to change. Email authentication has a network effect that
in 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

To the chairs:
It has become clear that we do not have consensus on the issue of 
content-altering mailing lists.

Despite the diversity of viewpoints the number of persons involve in the 
discussion is fairly small.
Have you identified the stakeholder groups that should be represented in the 
DMARCbis process for it to be considered sufficiently representative?
Have you made any assessment of whether all such groups are in some way 
represented in this discussion?
Do we need to do some outreach to ensure that all stakeholder groups are 
involved

Of course, adding additional voices may make the consensus problem more 
difficult.  What is your mechanism for resolving consensus problems?

Doug Foster


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/22/20 6:23 AM, Alessandro Vesely wrote:
> The fact that it cannot be set by a MUA implies Sender: already lost
> its menial meaning.  So it became a Mediator sort of thing.  This list
> sets it to "dmarc" .  Does anybody use it, or
> ever happened o take a look at it?

Yes, and I assume that's partially why the OP (who I was posting on behalf of) 
brought this Sender dilemma up in the first place.

Outlook on the Web displays:

dmarc  on behalf of dcroc...@gmail.com

and for those domains that have DMARC policies

dmarc  on behalf of 
todd.herr=40valimail@dmarc.ietf.org

Jesse

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/21/2020 3:44 PM, Douglas E. Foster wrote:

Dave Crocker writes:

 The practical problem with From: field munging by MLMs that are
 otherwise trying to relay a largely-unmodified messages, is that they
 effective destroy author information, by putting in a different email
 address.

This is helpful for identifying the three key stakeholder needs:

1) MLM's such as IETF want to alter the author's submission.

2) Authors like Hector want their submission left unmodified


List Servers has historically modified submissions, the body and 
subject line. It is part of the "package" per se.  Burned in. While 
problematic for DKIM, I doubt that will ever change.


However, my only concern has been always with the RFC5322.From address 
rewriting kludge when done in a blind way.  If the MLM is aware of 
DMARC, then it is intentional ignorant of a security protocol. While 
it may have been done in certain legacy distributions, it was not a 
common practice for List Servers to rewrite the 822/2822/5322.From 
field. What was "rewritten" was the return address for errors & 
bouncing back to the MLM list agent.


A kludge is by definition (by Google) "an ill-assorted collection of 
parts assembled to fulfill a particular purpose."  We ideally view a 
kludge as a temporary solution until a real fix is obtained. But as we 
have learned by practice, a kludge, a temporary solution left 
unaddressed, has a tendency to become permanent. So if the IETF is 
going to sanction this kludge, then we should get it officially IETF 
reviewed, documented, and not via some highly subjective wiki 
primarily authored by one person who believed this was the right thing 
to do without foreseeing the consequences.



3) Users like Dave want accurate author information in the MUA.

There is no legal corollary for "largely-unmodified".  If I use whiteout on a
signed document, spill an ink bottle on hallf of the signature, or replace the
special lawyer-only staples with standard staples, the document ceases to be
trusted and is probably unenforcable.

The nature of the changes made by the IETF mailing list renders the reverse
transformation impossible, so there is no way to validate the transformed
document against the original unless the original is obtained, yet the purpose
of the transformatiin is to hide the original.  A real solution has to eliminate
this operation.  Hector is right.


Imo, the resigner performing the rewriting, SHOULD resign using a 
secured resigner domain with the same level protection sought by the 
original author domain.


This would be consistent with the ietf.org only rewriting for domains 
with a p=reject|quarantine DMARC policy. It uses _dmarc.ietf.org for 
the rewriting domain.  Since this _dmarc.ietf.org domain only exist 
for rewriting a p=reject|quarantine domain, it would be technically 
logical for _dmarc.ietf.org to also have a p=reject|quarantine policy 
as well.   This includes using _dmarc.ietf.org for the return address 
to kept with the expected DMARC alignment. That will maintain the 
DMARC aligned protection for the original submission and resigner 
distribution.



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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[devel2020]

Hi,

Le 21/06/2020 à 21:44, Douglas E. Foster a écrit :
> 
> There is no legal corollary for "largely-unmodified".  [...]

Then what? An overwhelming majority of users need e-mail for day-to-day
communication, not for binding legal contracts. "Largely-unmodified" as
mailing-lists have been doing it for 40 years is good enough (we usually
don't hear authors complaining that they were impersonated).

People who need a high-integrity validation for each and every message
before reading it are the minority. The rest of us would rather keep our
communication possibilities unimpaired, even if it means dealing with a
bit of spam and use cryptography or out-of-band checks for important
business.

Not to say that DMARC's validation is not valuable per se. But asking
mailing-list (or other) users to jump through hoops to simply
communicate as they have for 40 years is incredibly arrogant.

Cheers,
Baptiste

P.S.: and no, "then don't use DMARC" cannot be the answer. Some time
down the road, it will be forced on us by the large mailhosts, who have
a business interest in curbing spam. So it'd better be done right.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

On 2020-06-21 7:32 p.m., Dave Crocker wrote:
> On 6/18/2020 12:46 AM, Alessandro Vesely wrote:
>> "Authoring" can have subtly different acceptations, though.  The
>> exact sentence is:
>>
>>  The "From:" field specifies the author(s) of the message,
>>    that is, the mailbox(es) of the person(s) or system(s) responsible
>>    for the writing of the message.
>> [https://tools.ietf.org/html/rfc5322#section-3.6.2]
>>
>> That is not so far from real.  The term "writing" sounds ambiguous,
>> as it is not clear whether it means "typing" or "publishing", in the
>> case of public mailing lists.  Given that Sender: is dedicated to
>> the typist, I'd opt for the latter interpretation.
> 
> In simple terms, author is the creator of the content and sender is
> the agent for getting the content processed.  The latter was
> distinguished to provide a means of improving accountability if there
> were problems.  When SMTP was created, later, MailFrom was added as an
> address for sending message handling reports.
> 
> When first specified, Sender: was to cover the case of someone doing
> the online work, on behalf of  authors who weren't online, or at least
> not online for processing the message.  Back in those days, that was
> not uncommon.  Even if the author officially had an online presence,
> they often did not do the typing.
> 
> (To underscore this a bit: in most of the business world, knowing how
> to type was deemed a menial, secretarial skill and not appropriate for
> an executive. To carry this a bit further: around the time RFC733 was
> developed, in 1977, I managed to get the person in charge of
> department administration functions to authorize my getting a desk
> with a right-hand return, where a secretary's typewriter would go, and
> where I put my terminal. This was extremely unusual and the immediate,
> similar requests from all the other staff like me were rejected. Also,
> when I announced my departure, the next year, the admin was instantly
> flooded with requests for my desk...)


Thank you for sharing the above historic perspective.


> [...]
> 
> So, in abstract terms, if I go to a greeting card site and have it
> send a greeting on my behalf, the From: field should be my own email
> address and Sender: should an address at the greeting card company. 
> But I said 'abstract' because current realities mean this isn't as
> useful an arrangement as the theory intended.


Agreed.  I'd derive it's time to revise the theory, however slightly.


> I believe this is because Sender: is not reliably present. Hence, it
> literally cannot be relied upon.  The Sender field is not created
> reliably to indicate such distinctions and the receive side does not
> reliable note the distinctions.


The fact that it cannot be set by a MUA implies Sender: already lost
its menial meaning.  So it became a Mediator sort of thing.  This list
sets it to "dmarc" .  Does anybody use it, or
ever happened o take a look at it?

See below for an alternative arrangement.


>> For a newspaper, if you pardon the analogy, the masthead is more
>> visible than columnist signatures at the end of the articles.  For a
>> mailing list, publisher visibility used to be provided by subject
>> tags, leaving the From: intact.  Why?  Presumably, because it just
>> worked that way.  However, if the MLM is the system responsible for
>> writing, not modifying From: should be considered a violation.
> 
> If a Mediator makes 'substantial' changes to a message, then it can be
> considered a new and different message?  Yes, but note that we have no
> objective criteria for this.  That's why I class this reference to
> 'publisher' as a business issue rather than a technical one.  (And an
> ethical one, as some wayward journalists discover when they claim to
> be quoting someone but it turns out the reporter invented the content.)


You certainly recall the level of sophistication described in Nelson's
Literary Machines.  Email is nowhere near that precision, therefore we
/have/ to relegate such issues to ethical or business ones.

As you say, an add-on to check quotation authenticity would require
access to the whole thread, and even then it wouldn't be trivial to
get it done.


> However I think that referencing the role of an MLM as 'publisher' can
> be helpful to remind us that MLMs have their own agency and can,
> legitimately, make all sorts of changes.  Whether authors and
> recipients like those changes is a non-technical matter.
> 
> The practical problem with From: field munging by MLMs that are
> otherwise trying to relay a largely-unmodified messages, is that they
> effective destroy author information, by putting in a different email
> address.
> 
> In practical terms, today, the MLMs arguably don't have a choice.  But
> it still can be helpful to understand the problems created by this
> alternation.


IMHO, the choice is how to do rewriting given the constraint that the
domain of From:'s addr-spec must match d= in MLM's 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

Dave Crocker writes:The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email address. This is helpful for identifying the three key stakeholder needs:1) MLM's such as IETF want to alter the author's submission.  2) Authors like Hector want their submission left unmodified3) Users like Dave want accurate author information in the MUA.There is no legal corollary for "largely-unmodified".  If I use whiteout on a signed document, spill an ink bottle on hallf of the signature, or replace the special lawyer-only staples with standard staples, the document ceases to be trusted and is probably unenforcable.   The nature of the changes made by the IETF mailing list renders the reverse transformation impossible, so there is no way to validate the transformed document against the original unless the original is obtained, yet the purpose of the transformatiin is to hide the original.  A real solution has to eliminate this operation.  Hector is right.MLMs could compare a submission against their screening criteria and reject submissions rather than transforming them.   IETF wants text-only subnissions.  Why not simply require text-only?   Because we have a MUA problem:  Some MUAs, including the one I am using, do not provide an option for sending text on ly.   Fix tbe submitter MUA and you eliminate the need for MLM reauthoring.The recipient need is ironic.   We have established that the MUA's handling of From is unimportant as it has no effect on user behavior, and Dave has been forceful on this point.   But now Dave and others argue that From rewrite is a problem because it reduces the usability of the MUA.  The two positions need to be reconciled.However, the upshot of this issue is that From rewrite creates a MUA problem and it can be solved with MUA changes. I have previously reported that my 3 MUAs present the IETF header information in 3 different ways.  This is ripe for standadization, and the header rewrite objection can be addressed during that process.So we have two MUA problems.  Fixing the latter one provides a quick fix while header rewrite continues.   Fixing the former one and changing MLM behavior will take a little longer, but provides a high-integrity end result over time.IETF also applies Subject tagging, which breaks DKIM signatures.  There are altetnatives for this as well, largely involving MUA tweaks.DF___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/18/2020 12:46 AM, Alessandro Vesely wrote:
"Authoring" can have subtly different acceptations, though.  The exact 
sentence is:


 The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.
[https://tools.ietf.org/html/rfc5322#section-3.6.2]

That is not so far from real.  The term "writing" sounds ambiguous, as 
it is not clear whether it means "typing" or "publishing", in the case 
of public mailing lists.  Given that Sender: is dedicated to the 
typist, I'd opt for the latter interpretation.


In simple terms, author is the creator of the content and sender is the 
agent for getting the content processed.  The latter was distinguished 
to provide a means of improving accountability if there were problems.  
When SMTP was created, later, MailFrom was added as an address for 
sending message handling reports.


When first specified, Sender: was to cover the case of someone doing the 
online work, on behalf of  authors who weren't online, or at least not 
online for processing the message.  Back in those days, that was not 
uncommon.  Even if the author officially had an online presence, they 
often did not do the typing.


(To underscore this a bit: in most of the business world, knowing how to 
type was deemed a menial, secretarial skill and not appropriate for an 
executive. To carry this a bit further: around the time RFC733 was 
developed, in 1977, I managed to get the person in charge of department 
administration functions to authorize my getting a desk with a 
right-hand return, where a secretary's typewriter would go, and where I 
put my terminal. This was extremely unusual and the immediate, similar 
requests from all the other staff like me were rejected. Also, when I 
announced my departure, the next year, the admin was instantly flooded 
with requests for my desk...)


For most email, From: and Sender: are the same person (and the same 
email address.)  This fact was the reason the original specification of 
Sender: in RFC 733 only required an explicit Sender: field be present 
when the addresses are different.


For today, these same abstract constructs have -- or should have -- only 
slightly different application.  From: is still supposed to be the 
author, which remains the creator of the (original) content.  Sender: 
could be any separate party responsible for processing the message.


So, in abstract terms, if I go to a greeting card site and have it send 
a greeting on my behalf, the From: field should be my own email address 
and Sender: should an address at the greeting card company.  But I said 
'abstract' because current realities mean this isn't as useful an 
arrangement as the theory intended.


I believe this is because Sender: is not reliably present. Hence, it 
literally cannot be relied upon.  The Sender field is not created 
reliably to indicate such distinctions and the receive side does not 
reliable note the distinctions.



For a newspaper, if you pardon the analogy, the masthead is more 
visible than columnist signatures at the end of the articles.  For a 
mailing list, publisher visibility used to be provided by subject 
tags, leaving the From: intact.  Why?  Presumably, because it just 
worked that way.  However, if the MLM is the system responsible for 
writing, not modifying From: should be considered a violation.


If a Mediator makes 'substantial' changes to a message, then it can be 
considered a new and different message?  Yes, but note that we have no 
objective criteria for this.  That's why I class this reference to 
'publisher' as a business issue rather than a technical one.  (And an 
ethical one, as some wayward journalists discover when they claim to be 
quoting someone but it turns out the reporter invented the content.)


However I think that referencing the role of an MLM as 'publisher' can 
be helpful to remind us that MLMs have their own agency and can, 
legitimately, make all sorts of changes.  Whether authors and recipients 
like those changes is a non-technical matter.


The practical problem with From: field munging by MLMs that are 
otherwise trying to relay a largely-unmodified messages, is that they 
effective destroy author information, by putting in a different email 
address.


In practical terms, today, the MLMs arguably don't have a choice.  But 
it still can be helpful to understand the problems created by this 
alternation.



My understanding of the meaning that DMARC added was, "The author of 
this
message, as expressed in the From: field, always has their messages 
properly
signed by the domain in the From: address." You seem to be saying 
that, no,

what DMARC did was changed the semantic to be, "The From: field now
represents the transmitter of the message (as used to be expressed in 
the
Sender: field when present), not the author, and that transmitter 
always has

their messages properly signed by the domain 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/19/2020 2:22 PM, Jim Fenton wrote:


That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.



As an "MUA" author/developer, this is a matter on how aggressive the 
end-user client software wishes is to be.  We have seen this evolved 
and increasingly employed over the years.  I can them "Scare Tactics 
Ponzi Schemes."


o Code Signing: Today, developers are being forced to fork up money to 
order to stop scaring users that they are to install "uncertified" 
software.  While I believe this has good reason for FIRST TIME 
installations, I considered it unethical, unfair for established 
developers when the software is already installed and user is merely 
upgrading.


o Self-signed SSL certs:  Today, the browsers, especially Chrome, are 
scaring the "manure" of the laymen users with FALSE complex page 
display indications that they domain just intended to reach is not 
secured. That is false.  The target and common name match and it is 
not expired. What remains is, once again, the lack of an authorized 
3rd party signature requirement.  The domain simply did not wish to 
pay extortion fees to a CA that has a mechanism for an SSL trusted 
chain.  Thanks to Let's Encrypt, this is less of an issue today.


So do we consider advising MUA to add or don't add "Scare Tactics?"

I believe the MUA must begin to become proactive with assisting users 
with the mails DKIM Policy and Trust-based indicators.  I know some 
cites have explored this that was before DKIM POLICY took how. How 
will it play to today with DMARC.  Overall, as a MUA developer, who 
does have new MUA projects in the works, the perpetual mantra that "we 
did that and it didn't work" and the idea that one size (one protocol) 
must fit all and that is must scale, otherwise its useless, doesn't 
really apply anymore.


We need to allow systems who are capable of giving the user more 
confidence with what their eyeballs are seeing explore the considerations.


My take with all this since the beginning was since we don't know all 
the answers on how people will use protocols, we should at least 
provide the considered possible options for them to explore using 
DMARC Tag Extensions.   Here are few that can apply:


Proposed Tag Extensions:

-Rewrite=0|1  if 1, authorize any list system to rewrite 5322.From, 
using the a "standardized" approach that helps keep the domains 
original security.


-atps=0|1  if 1, the domain supports RFC6541 "DomainKeys Identified 
Mail (DKIM) Authorized Third-Party Signatures"


and this one I just came up with to address this MUA display question, 
just winging it now:


-MUA.From={logic to offer MUA on what to display}

The MUA can do its own lookup to see domain's desire to what to 
display. Maybe the options can be:


-MUA.From=0 No advice (default)
-MUA.From=1 Display the Address with User Name
-MUA.From=2 Display just the address
-MUA.From=3 Only Display address when signer domain differs

Of course, with change comes new opportunity.  If the MUA was updated 
to support this tag, then we may not need the tag and just advise the 
MUA to prominently display the address and/or when we have a 3rd party 
resigner involved.


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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Todd Herr]

On Fri, Jun 19, 2020 at 2:22 PM Jim Fenton  wrote:

> On 6/19/20 10:41 AM, Todd Herr wrote:
>
> On Fri, Jun 19, 2020 at 1:23 PM Dotzero  wrote:
>
>>
>>
>> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton 
>> wrote:
>>
>>>
>>> A verified identity is established by DKIM and/or SPF. What is DMARC
>>> adding in this respect?
>>>
>>> Policy expressed by the  domain owner/administrator based on some
>> combination of DKIM and/or SPF and the feedback loop.
>>
>> Both policy and the feedback loop are actions taken on the basis of
> verification of the identity (or lack thereof). They do not establish the
> identity themselves.
>
>
> Not only that, but DMARC is the only one of the three that is necessarily
> tied to the domain in the (usually) visible in the MUA From header.
>
> That comes back to the question of whether the domain in the From header
> is visible in the MUA, and if visible, does it alter user behavior (e.g.,
> discourage users from clicking phish links). Different people have
> different opinions on that. A couple of messages back on this thread, the
> blocking of email was discussed and that does not relate to visibility of
> the domain in the MUA.
>
>
>
Dave Crocker wrote:

> There is no evidence that end-users are relevant to
> manipulated/fraudulent From: fields or that DMARC's "certifying" the
> domain name of the From: field is relevant to reducing end-user
> vulnerability.
> There is quite a bit of evidence that improving trust signals to end
> users has no significant effect.


Nowhere have I made any claim regarding the alteration of user behavior; I
am speaking solely to the idea of DMARC being used to verify an identity,
specifically the domain in the From header. It's my assumption that this
verification is likely to be done by someone other than the user,
specifically their mailbox provider, whom I further assume will make
acceptance and folder placement decisions for a message based on a
combination of factors, including, but definitely not limited to, the
results of all applicable authentication checks. We don't ask users to
perform SPF or DKIM validation checks, so I don't believe that my
assumptions are inconsistent here.

While it's true to say a verified identity is established by DKIM and/or
SPF, which identity is established by these protocols? I've got mail in my
inbox right now that has:

   - in.constantcontact.com as the Return-Path domain; SPF verdict was
   pass, so in.constantcontact.com was verified as being authorized to send
   from the host that originated the message; if we want to call this the
   verification of an identity, so be it.
   - auth.ccsend.com as the DKIM signing domain; DKIM verdict was pass, so
   auth.ccsend.com was verified as the signer, but definitely not the
   purported author, per RFC 6376, section 1.2
   - $MYGOLFCLUB.com as the From domain; no DMARC policy published, so the
   identity was not verified, but I can tell from the content of the message
   that it's legitimate

Now, this mail was wanted mail, so I'm thankful in this case that the
domain doesn't publish a DMARC policy, or else I might not have gotten the
message. Maybe if they did, Constant Contact would enforce a policy of DKIM
signing with $MYGOLFCLUB.com; I don't know how things work at CC. However,
such a tuple of three unaligned domains isn't unheard of, and it is to me a
textbook case of the need for some mechanism for receiving domains to use
to verify the identity associated with the From header. Without such a
mechanism, then there is nothing, save the Acceptable Usage Policy enforced
by my connectivity provider, to prevent me from sending an unlimited amount
of mail using $MYGOLFCLUB.com in the From domain, along with those
disposable domains mentioned upthread for SPF and DKIM. (Whether or not
such messages reach their destination is an open question, based on the
filtering policies in place at the target domains.)

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:*


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] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/19/2020 11:22 AM, Jim Fenton wrote:
That comes back to the question of whether the domain in the From 
header is visible in the MUA, and if visible, does it alter user 
behavior (e.g., discourage users from clicking phish links). Different 
people have different opinions on that. 



A small point that keeps being ignored is that there is quite a bit of 
objective information showing that it does NOT have an effect.  As far 
as I'm aware, there is no objective data that it DOES have an effect.


So, no, this is not just a matter of differing 'opinions'.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/19/2020 10:41 AM, Todd Herr wrote:
Not only that, but DMARC is the only one of the three that is 
necessarily tied to the domain in the (usually) visible in the MUA 
From header.


Todd,

There is no evidence that end-users are relevant to 
manipulated/fraudulent From: fields or that DMARC's "certifying" the 
domain name of the From: field is relevant to reducing end-user 
vulnerability.


There is quite a bit of evidence that improving trust signals to end 
users has no significant effect.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/19/20 10:41 AM, Todd Herr wrote:
> On Fri, Jun 19, 2020 at 1:23 PM Dotzero  > wrote:
>
>
>
> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton  > wrote:
>
> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> > DMARC helps establish a verified identity.  Delivery is based on
> > reputation.  The two are very different. 
> >
> > Unwanted mail with DMARC validation will be blocked on the
> same basis
> > is unwanted mail without it.
> >
> > But a verified identity is helpful for ensuring that wanted
> mail is
> > not blocked.
>
> A verified identity is established by DKIM and/or SPF. What is
> DMARC
> adding in this respect?
>
> Policy expressed by the  domain owner/administrator based on some
> combination of DKIM and/or SPF and the feedback loop.
>
Both policy and the feedback loop are actions taken on the basis of
verification of the identity (or lack thereof). They do not establish
the identity themselves.
>
> Not only that, but DMARC is the only one of the three that is
> necessarily tied to the domain in the (usually) visible in the MUA
> From header.
>
That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.

-Jim


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Laura Atkins]

> On 19 Jun 2020, at 18:08, Jim Fenton  wrote:
> 
> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
>> DMARC helps establish a verified identity.  Delivery is based on
>> reputation.  The two are very different. 
>> 
>> Unwanted mail with DMARC validation will be blocked on the same basis
>> is unwanted mail without it.
>> 
>> But a verified identity is helpful for ensuring that wanted mail is
>> not blocked.
> 
> A verified identity is established by DKIM and/or SPF. What is DMARC
> adding in this respect?

It’s pushing the verified identity out to bits of the email that the end user 
(sometimes) sees. 

laura 

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

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

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







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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Todd Herr]

On Fri, Jun 19, 2020 at 1:23 PM Dotzero  wrote:

>
>
> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton  wrote:
>
>> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
>> > DMARC helps establish a verified identity.  Delivery is based on
>> > reputation.  The two are very different.
>> >
>> > Unwanted mail with DMARC validation will be blocked on the same basis
>> > is unwanted mail without it.
>> >
>> > But a verified identity is helpful for ensuring that wanted mail is
>> > not blocked.
>>
>> A verified identity is established by DKIM and/or SPF. What is DMARC
>> adding in this respect?
>>
>> Policy expressed by the  domain owner/administrator based on some
> combination of DKIM and/or SPF and the feedback loop.
>
>
Not only that, but DMARC is the only one of the three that is necessarily
tied to the domain in the (usually) visible in the MUA From header.


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:*


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] Header munging, not ARC, can solve the mailing list problem

[Dotzero]

On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton  wrote:

> On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> > DMARC helps establish a verified identity.  Delivery is based on
> > reputation.  The two are very different.
> >
> > Unwanted mail with DMARC validation will be blocked on the same basis
> > is unwanted mail without it.
> >
> > But a verified identity is helpful for ensuring that wanted mail is
> > not blocked.
>
> A verified identity is established by DKIM and/or SPF. What is DMARC
> adding in this respect?
>
> Policy expressed by the  domain owner/administrator based on some
combination of DKIM and/or SPF and the feedback loop.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

Pete;you have not explained how my inbox filter recignizes a legitimate 
forward of a legitimate message instead of an illegitimate forward or a 
fraudulently manufactured Received-header sequence.

We only have this problem 
with lists that alter the original to destroy DKIM validity.   When this is 
done, the list becomes the author snd the headers should reflect as much.

The referenced spam analysis article notes that infequently seen message 
sources are high probability spam.   If the list postings are from many 
individuals instead of one IETF address, the likelihood of blocked posts is 
significant.  Thus should ne a concern whether DJIM is preserved or not.

On Jun 19, 2020 12:46 PM, Pete Resnick  wrote:On 19 
Jun 2020, at 11:40, Pete Resnick wrote:

> The presumption of all Mediator-type transactions was that the 
> receiving email client was to deal with the message (the thing with 
> the identical Message-ID) with its original semantics, adding only 
> Resent-*: or List-*: fields to add the semantic of the mediation 
> event.

That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:

"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
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] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> DMARC helps establish a verified identity.  Delivery is based on
> reputation.  The two are very different. 
>
> Unwanted mail with DMARC validation will be blocked on the same basis
> is unwanted mail without it.
>
> But a verified identity is helpful for ensuring that wanted mail is
> not blocked.

A verified identity is established by DKIM and/or SPF. What is DMARC
adding in this respect?


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Pete Resnick]

On 19 Jun 2020, at 11:40, Pete Resnick wrote:

The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with 
the identical Message-ID) with its original semantics, adding only 
Resent-*: or List-*: fields to add the semantic of the mediation 
event.


That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:


"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."



--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Pete Resnick]

On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:


consider a mailing list as a publishing organization, which is what it
is.


No, it isn't. It is a Mediator. See RFC 5598.


If article submission happened via HTTP, say, like in web fora,
there would be no reason to talk about From: rewriting.


Take my particular case: I don't get SMTP email from IETF mailing lists. 
I point my email client to imap.ietf.org and read the messages directly 
out of the mailboxes there. As people send email to the list, the 
messages are deposited into the appropriate IMAP mailbox for the list. 
Some of the messages (mistakenly IMO) have their Subject's munged, but 
not on all lists, and certainly not on the main IETF list. Usually, only 
trace info (Received: fields), a set of List-*: fields, an Archived-At: 
field, and similar are added, but otherwise, the contents of the message 
(including the normal headers) are unadulterated. That's good: I can 
reply to the author directly, reply to the list, or reply all as I see 
fit, or I can check S/MIME signatures, or I can use the "Add person to 
my address book" feature of my client, etc. It all works because nothing 
is munged. It is as it should be.



The
fortuitous circumstance that both article submission and the final
distribution happen through SMTP generated the current conundrum.


Why should using SMTP for *message* (not "article") distribution change 
anything in the example above?


And let's not pretend that it is just mailing lists that have this 
problem. The "resend" feature on my email client breaks if servers honor 
p=reject and can't be bothered to check the Resent-*: fields and realize 
that I am a legit sender. Alias expansion breaks. The problem is that a 
whole set of legitimate and documented features in email were simply 
dismissed as unimportant to keep in the first round of DMARC (or, more 
fairly, probably weren't properly considered).



It presumably seemed to be easier or less intrusive to tag the
Subject: and leave the From: unaltered.


No, that's rewriting history. The presumption of all Mediator-type 
transactions was that the receiving email client was to deal with the 
message (the thing with the identical Message-ID) with its original 
semantics, adding only Resent-*: or List-*: fields to add the semantic 
of the mediation event. Even rewriting Subject: is a problematic hack 
which the List-*: fields were created to avoid.



The correct approach should
have been to use the publishing organization's own From:, possibly
adding the author's name or initials to the Subject:.  We only realize
that mistake now, after the introduction of email authentication.

Yes, we kept using the wrong arrangement for 40+ years.  That is not a
good reason to persevere.


No, sorry, you've got the history entirely on its head. For 40+ years, 
we had a set of features of the email system which allowed an email 
message to be copied and/or moved around in loads of different ways (in 
archives, in IMAP stores, in mail clients), and one of those ways was 
always "reintroduce the message back into the transport system" using 
trace info in the message header to see the details of that 
reintroduction. DMARC came along and decided that that particular set of 
features was not worth addressing, or too hard to address, or maybe 
didn't realize that such features were going to be a problem.


Maybe it's time to abandon that set of features. I personally don't 
think so, but I could be in the rough part of the rough consensus. But I 
do think that set of features can be preserved with a bit of work, and I 
think that work is worth doing. But if we are going to abandon those 
features, a better argument will need to be made than "Oh, in retrospect 
we realize that email was doing it wrong for 40+ years." That argument 
is bogus.


pr


On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote:

Alessandro,

There are long time solid reasons why the "Local.From" field needs to
be stable. In particular, with local messaging, unless the local
system allows for anonymous entry of the Local.From field when
creating a Local message, there is a MUST for a 1 to 1 association
with the account.

If local mail is exported for a external network, it doesn't matter
what mail network it is, you really don't want to introduce the idea
of allowing the changing of the Network.from field and making it
anonymous or disassociated with the original source. The domain is
associated with the source of the message, and the user part of the
address reflects the user account at the domain.  There are good
reasons for that.   Lets say the user is causing a problem on a 
remote

system. Using the network.From, the remote system could contact the
original system and issue a complaint.  If we were "free" to remove
that idea, it be would harder to trace it.   DKIM allows you to 
lock

that field down so that it can't be tampered with.

You have to understand the long time pov of developers that have 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins 
wrote:

> On 19 Jun 2020, at 07:59, Murray S. Kucherawy  wrote:
>
> So to those of you with access to such (e.g., M3AAWG regulars among
> us), is there evidence in the wild of spammers and phishers using
> discardable (ahem) domains to achieve alignment and improve their
> delivery success stories?
>
>
> There is certainly ample evidence that spammers are: sing disposable
> domains / rotating through domains and aligning authentication so that they
> will pass DMARC.
>

Here's an article citing exactly such an example from today's headlines:
https://threatpost.com/bofa-phish-gets-around-dmarc-other-email-protections/156688/
Sadly, the explanation of what DMARC is/does is botched. (related original
article:
https://www.armorblox.com/blog/blox-tales-7-bank-of-america-credential-phishing/
which details the specifics of the phishing attack - sent from Yahoo,
misleading display name, misleading newly registered domain and URL)

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

Hector,

consider a mailing list as a publishing organization, which is what it
is.  If article submission happened via HTTP, say, like in web fora,
there would be no reason to talk about From: rewriting.  The
fortuitous circumstance that both article submission and the final
distribution happen through SMTP generated the current conundrum.

It presumably seemed to be easier or less intrusive to tag the
Subject: and leave the From: unaltered.  The correct approach should
have been to use the publishing organization's own From:, possibly
adding the author's name or initials to the Subject:.  We only realize
that mistake now, after the introduction of email authentication.

Yes, we kept using the wrong arrangement for 40+ years.  That is not a
good reason to persevere.


Best
Ale
-- 


On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote:
> Alessandro,
> 
> There are long time solid reasons why the "Local.From" field needs to
> be stable. In particular, with local messaging, unless the local
> system allows for anonymous entry of the Local.From field when
> creating a Local message, there is a MUST for a 1 to 1 association
> with the account.
> 
> If local mail is exported for a external network, it doesn't matter
> what mail network it is, you really don't want to introduce the idea
> of allowing the changing of the Network.from field and making it
> anonymous or disassociated with the original source. The domain is
> associated with the source of the message, and the user part of the
> address reflects the user account at the domain.  There are good
> reasons for that.   Lets say the user is causing a problem on a remote
> system. Using the network.From, the remote system could contact the
> original system and issue a complaint.  If we were "free" to remove
> that idea, it be would harder to trace it.   DKIM allows you to lock
> that field down so that it can't be tampered with.
> 
> You have to understand the long time pov of developers that have been
> at this for 40 years.  Every system I have worked, the different
> networks, it was the same thing -- leave the from field alone! Do not
> make it "anonymous" or capable of being an "unknown."
> 
> Its the same for Instant Messaging, for Chatting, the TELEPHONE, the
> Caller ID, etc, it is a TABOO to change the "From" entity.
> 
> If you want to continue your line of logic to rationalize Rewriting,
> then you need to make it "protocol complete"  to help keep the
> association of the From field with the original source intact. But
> more importantly, it should have get permission from the original
> domain in order to rewrite. This can be done with a DMARC tag extension:
> 
> DMARC p=reject|quarantine ... rewrite=0|1
> 
> The default sides with highest security -- No Rewriting. But if the
> domain wishes to allow for rewriting, then it should explicitly state
> it in this policy record, rewrite=1.
> 
> This is something I could possibly support IFF the originating domain
> allows it. There would other things to consider to tie the loose ends,
> but the #1, would be the rewrite=1 tag.
> 

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Todd Herr]

On Fri, Jun 19, 2020 at 9:13 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:

> DMARC helps establish a verified identity.  Delivery is based on
> reputation.  The two are very different.
>

Laura Atkins wrote:

> DMARC alignment alone is not sufficient for reaching the inbox. Ask all of
> my non spamming clients who manage to screw up their delivery.


I cannot agree more with both of these statements.

There are countless entities in the email ecosystem, both legit senders and
bad actors, who believe that authentication alone is enough to earn the
privilege of delivery to the inbox, and they continue to be misinformed on
that point.

Authentication allows the receiving entity to reliably apply to the message
in question any reputation information that the receiving entity has
accumulated for the verified identity.

A published DMARC policy allows the domain owner to request treatment by
the receiving entity for mail that does not pass authentication checks; the
receiving entity can honor this request or not based on their own local
policies.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:*


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] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

DMARC helps establish a verified identity.  Delivery is based on 
reputation.  The two are very different. 

Unwanted mail with DMARC validation will be blocked on the same basis is 
unwanted mail without it.

But a verified identity is helpful for ensuring that wanted mail is not 
blocked.

There is no vulnerability created by DMARC.

On Jun 19, 2020 1:17 AM, Jim Fenton  wrote:On 
6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to an
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.


___
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] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/18/2020 10:16 PM, Jim Fenton wrote:

On 6/18/20 7:35 PM, Dave Crocker wrote:
vulnerability? 

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.



Thanks for explaining what vulnerability means, but my question was 
meant to prod you to explain what vulnerability you claim is there.


I've looked over your postings of the last few days and somehow I'm not 
seeing that described.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Murray S. Kucherawy]

On Thu, Jun 18, 2020 at 3:24 PM Jim Fenton  wrote:
> We need to consider not just what's a useful correlation today, but what
> will continue to be so. As soon as the {spammers, phishers, etc.} catch
> on that they can achieve alignment at will, it will cease to be a useful
> correlation. History teaches us that will happen quickly.

RFC 7489 was published just over five years ago now.  I would imagine
that if Jim is correct, we would see evidence of it by now.

So to those of you with access to such (e.g., M3AAWG regulars among
us), is there evidence in the wild of spammers and phishers using
discardable (ahem) domains to achieve alignment and improve their
delivery success stories?

-MSK, sans chapeau

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to an
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/18/2020 6:28 PM, Tim Wicinski wrote:

On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker wrote:


Oh good.  Let's predict the future.  That should be fun.


Have to agree with Dave here.   We have to accept it's a
constantly moving target.


We, as engineers, do believe we are making the proper decisions, and a 
good bit of the time, we are correct, otherwise we are worthless.


Its called IETF Engineering. I also called it striving to "Getting it 
Right ... the First Time." -- old Westinghouse QA Engineering motto, 
not about perfection but just at least to do it correct and fairly to all.


We have allowed for some real bad decisions to take place within the 
IETF-DKIM work in the last 15+ years.


That is my assessment.

I am seriously hoping through this IETF/DMARC work rendition some real 
solid outcomes can be reached that the entire IETF community, not just 
the self-interest groups behind the scenes, benefit.


No offense to anyone, 15 yrs on this, is not a good thing.

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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/18/2020 4:01 PM, Jim Fenton wrote:

It would be remarkable for IETF to achieve rough consensus on a
specification with a known vulnerability while we "wait for the bad
actors to catch on." Particularly when that vulnerability relates to an
aspect of the specification that has caused widespread deployment problems.


vulnerability?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/17/2020 3:11 PM, Pete Resnick wrote:

On 17 Jun 2020, at 13:27, Dave Crocker wrote:



The nature of the hack that mailing lists do, when altering the
From: field, makes this clear:  They alter information about the
operator handling the message, destroying the original information
about content authorship.


Mailing lists that make other choices (throwing away messages from
DMARC reject senders, denying subscriptions from them, or simply
ignoring them and ending up with bad consequences) have obviously not
gone along with the certain forms of the semantic change.



+1.

I preferred the "let's honor the policy" list system adaption 
approach.  It was the simplest, less programmatic approach. I did get 
some initial complaints from users who wanted to continue using their 
"junk" ESP email addresses like yahoo.com, aol.com and now icloud.com 
accounts and other larger esp domain accounts with restrictive mail 
policies who switched to restrictive policies. They understood the 
dilemma and used other domains - problem solved.



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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/18/20 3:42 PM, Dave Crocker wrote:
>
> And now I'll note that when DMARC moved from being a way to
> authenticate a tightly controlled mail stream, as was originally
> discussed during its development, into its broader role, I expressed
> the same concern that a correlation not inherently tied to the
> misbehavior is one easily routed around. 
>
> However, there is too much industry force behind this broader use of
> DMARC for such simple logic to have any useful effect.  Rather, we'll
> just have to wait for the bad actors to catch on. 
>

It would be remarkable for IETF to achieve rough consensus on a
specification with a known vulnerability while we "wait for the bad
actors to catch on." Particularly when that vulnerability relates to an
aspect of the specification that has caused widespread deployment problems.


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/18/20 2:29 PM, Dave Crocker wrote:
> On 6/18/2020 2:10 PM, Jim Fenton wrote:
>> On 6/17/20 12:11 PM, Pete Resnick wrote:
>>> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
 DMARC has nothing to do with display of author information to a
 recipient, and everything to do with differential handling by a
 receiving filtering engine.  Were the Sender: field always present,
 that would be the one that DMARC should have used.
>>> It could have chosen the more complicated, "Sender unless not present,
>>> in which case From". But yes, this bit I get. That said, there are
>>> people who have argued that From: was chosen because Sender: was not
>>> displayed. I think that's a silly argument, but it's one that people
>>> still believe.
>> I'm trying to understand why alignment to any header field is important
>> to DMARC in that case.
>
>
> Because operators have found useful correlations in distinguishing
> between messages that are aligned and being 'genuine' versus ones that
> are not aligned.
>
> In the abstraction of theory, you are correct that it shouldn't
> matter.  In the brutality of practice, it appears that it does.
>
We need to consider not just what's a useful correlation today, but what
will continue to be so. As soon as the {spammers, phishers, etc.} catch
on that they can achieve alignment at will, it will cease to be a useful
correlation. History teaches us that will happen quickly.


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/18/2020 2:10 PM, Jim Fenton wrote:

On 6/17/20 12:11 PM, Pete Resnick wrote:

On 17 Jun 2020, at 13:27, Dave Crocker wrote:

DMARC has nothing to do with display of author information to a
recipient, and everything to do with differential handling by a
receiving filtering engine.  Were the Sender: field always present,
that would be the one that DMARC should have used.

It could have chosen the more complicated, "Sender unless not present,
in which case From". But yes, this bit I get. That said, there are
people who have argued that From: was chosen because Sender: was not
displayed. I think that's a silly argument, but it's one that people
still believe.

I'm trying to understand why alignment to any header field is important
to DMARC in that case.



Because operators have found useful correlations in distinguishing 
between messages that are aligned and being 'genuine' versus ones that 
are not aligned.


In the abstraction of theory, you are correct that it shouldn't matter.  
In the brutality of practice, it appears that it does.



d/

--

Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

There are some basic principles that need to be considered:.

DMARC did not break mailing list privileges, unwanted mail did.

A fully legitimate message has these characteristics:
Intended by the originatorAcceptable to the policies of the domain owner, which 
are partially implemented in its outbound mail filterDesired by the 
recipientAcceptable to the recipient domain owner, as partially implemented in 
its inbound mail filter.
One example of a message that is not acceptable to the originator is a message 
spoofed by an authorized server.   This is one of the problems addressed by 
DMARC.

More specifically, what characteristics make a message acceptable to the 
recipient:
A recognized / trusted senderA message which looks like previous-good messagesA 
message with no identifiable risk factors.
To elaborate, incoming mail filters separate mail into three buckets:
Probably unwantedUnknown and hopefully harmlessDefinitely wanted

The administrators of the incoming mail filter will be continually seeking to 
move traffic from bucket 2 to bucket 1 or bucket 3, so a strategy based on 
bucket 2 is not guaranteed to work indefinitely.

>From the viewpoint of the inbound mail filter, forwarded mail is 
>indistinguishable from spoofed mail using an open relay.   In a world where 
>all mail was wanted mail, mailing lists could do what they want.  But we are 
>not on Arpanet anymore, and unwanted mail is a huge problem.

If a mailing list is violating DMARC, it is likely to be put in bucket 1.   
Once one message ends up in bucket 1, all messages from that source are likely 
to be blocked as well.

For a sender to be promoted from bucket 1 to bucket 2, messages need to 
distinguish themselves from untrusted email.   Preserving DKIM signatures is 
one way of doing so.  Header munging is another way of doing so.

To move into bucket 3, the forwarder needs to obtain a sponsor to negotiate 
with the recipient organization's email security team..

For two messages from the same forwarder to land in the same bucket, both 
messages must have similar qualifying characteristics.

An Example

Consider the risk profile of a request to auto-forward from UserA@DomainA to 
UserB@DomainB

This request could reflect a range of behaviors from low risk to high risk.
UserB actually wants the forward to occur.UserB is the accidental victim of a 
typing error.UserA is going to be used as a proxy to attack UserB.Forwarding to 
UserB is contrary to DomainA policy because it is likely to permit violation of 
DomainA's regulatory obligations under GDPR, PCI DSS, HIPPA, Sarbanes-Oxley or 
something else.Forwarding to UserB is in conflict with DomainB policy for 
whatever reason.UserA is an inside attacker seeking to exfiltrate data to an 
external accomplice.
So both DomainA and DomainB administration have reasons to be involved in this 
request.   Even for legitimate requests, DomainA does not want to forward 
traffic to DomainB if it is unwanted, since unwanted mail may impact the 
reputation of DomainA, and likely cause unwanted blacklisting of other messages.

Therefore, the wisest procedure is as follows:
DomainA detects the forward request and begins an approval workflow.DomainA 
reviews the request to see if they are willing to grant internal 
approval.Postmaster@DiomainA contacts UsersB@DomainB asking them to submit the 
request to their email security team for approval.Administrators for DomainA 
and DomainB communicate to discuss the administrative controls at DomainA as 
well as the fingerprint characteristics of the incoming mail.Upon approval, 
DomainB administration gives DomainA administration permission to proceed.  
DomainA activates the forwarding and notifies the user.DomainA monitors the 
outbound mailstream for deliverability and terminates the forwarding if 
repeated failures occur, or upon request from DomainB administration or 
UserB@DomainB.
I suspect most mailing systems would need a lot of new code to implement a 
workflow like this, but my perspective is limited and may be wrong.

The mailing list scenario is not much different, except that the request 
process begins when UserB@DomainB attempts to subscribe to the mailing list, 
and the approval process involves both the handling of messages coming from the 
list as well as messages going to the list.

The process may be limited by the features of the DomainB email filter.   
Without header munging, fingerprinting the mailing list will require combining 
the list headers with forward confirmed host names, or something along those 
lines.Low-end email filters may be unable to filter on list name, or filter 
on multiple attributes together.

Getting prior approval will be a lot of work, and i wonder how many lists will 
be willing to try. In the absence of prior approval, I see no solution 
better than header munging.   Header munging is an inferior solution because 
neither sender policies nor receiver policies are evaluated or respected, but 
it is 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/17/20 12:11 PM, Pete Resnick wrote:
> On 17 Jun 2020, at 13:27, Dave Crocker wrote:
>
>> DMARC has nothing to do with display of author information to a
>> recipient, and everything to do with differential handling by a
>> receiving filtering engine.  Were the Sender: field always present,
>> that would be the one that DMARC should have used.
>
> It could have chosen the more complicated, "Sender unless not present,
> in which case From". But yes, this bit I get. That said, there are
> people who have argued that From: was chosen because Sender: was not
> displayed. I think that's a silly argument, but it's one that people
> still believe.


I'm trying to understand why alignment to any header field is important
to DMARC in that case. If whatever it's aligning to is not visible, the
sender can trivially achieve alignment by choosing the From: (or
Sender:, whatever) address to match the domain of the DKIM signature
and/or envelope-from address. I don't see how that contributes at all to
differential handling by a receiving filtering engine. If it's because
From: is visible, the address part of From is getting to be a lot less
visible, plus typical users will ignore the address anyway.

And if From: alignment doesn't matter, the mailing list can just sign
the message and no rewriting is needed.

-Jim



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

Alessandro,

There are long time solid reasons why the "Local.From" field needs to 
be stable. In particular, with local messaging, unless the local 
system allows for anonymous entry of the Local.From field when 
creating a Local message, there is a MUST for a 1 to 1 association 
with the account.


If local mail is exported for a external network, it doesn't matter 
what mail network it is, you really don't want to introduce the idea 
of allowing the changing of the Network.from field and making it 
anonymous or disassociated with the original source. The domain is 
associated with the source of the message, and the user part of the 
address reflects the user account at the domain.  There are good 
reasons for that.   Lets say the user is causing a problem on a remote 
system. Using the network.From, the remote system could contact the 
original system and issue a complaint.  If we were "free" to remove 
that idea, it be would harder to trace it.   DKIM allows you to lock 
that field down so that it can't be tampered with.


You have to understand the long time pov of developers that have been 
at this for 40 years.  Every system I have worked, the different 
networks, it was the same thing -- leave the from field alone! Do not 
make it "anonymous" or capable of being an "unknown."


Its the same for Instant Messaging, for Chatting, the TELEPHONE, the 
Caller ID, etc, it is a TABOO to change the "From" entity.


If you want to continue your line of logic to rationalize Rewriting, 
then you need to make it "protocol complete"  to help keep the 
association of the From field with the original source intact. But 
more importantly, it should have get permission from the original 
domain in order to rewrite. This can be done with a DMARC tag extension:


DMARC p=reject|quarantine ... rewrite=0|1

The default sides with highest security -- No Rewriting. But if the 
domain wishes to allow for rewriting, then it should explicitly state 
it in this policy record, rewrite=1.


This is something I could possibly support IFF the originating domain 
allows it. There would other things to consider to tie the loose ends, 
but the #1, would be the rewrite=1 tag.


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


On 6/18/2020 3:46 AM, Alessandro Vesely wrote:

On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:

On 17 Jun 2020, at 13:27, Dave Crocker wrote:

On 6/17/2020 9:56 AM, Pete Resnick wrote:

No, the semantics of From: have not changed generally. [...]



So, really, DMARC has altered the semantics of the From: field to
be the Sender: field.


Wait a minute: I think this point needs some clarification. We know
that the pre-DMARC semantics of the From: field are "the entity that
authored the message".



"Authoring" can have subtly different acceptations, though.  The exact
sentence is:

  The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message.
[https://tools.ietf.org/html/rfc5322#section-3.6.2]

That is not so far from real.  The term "writing" sounds ambiguous, as
it is not clear whether it means "typing" or "publishing", in the case
of public mailing lists.  Given that Sender: is dedicated to the
typist, I'd opt for the latter interpretation.

For a newspaper, if you pardon the analogy, the masthead is more
visible than columnist signatures at the end of the articles.  For a
mailing list, publisher visibility used to be provided by subject
tags, leaving the From: intact.  Why?  Presumably, because it just
worked that way.  However, if the MLM is the system responsible for
writing, not modifying From: should be considered a violation.



My understanding of the meaning that DMARC added was, "The author of
this
message, as expressed in the From: field, always has their messages
properly
signed by the domain in the From: address." You seem to be saying
that, no,
what DMARC did was changed the semantic to be, "The From: field now
represents the transmitter of the message (as used to be expressed
in the
Sender: field when present), not the author, and that transmitter
always has
their messages properly signed by the domain in the From: address".


Sender: was not meant to be the transmitter in that sense.  It was
meant to be the secretary who writes on behalf of a responsible person
or system.  It never had traction, AFAIK.  Most clients don't allow
secretaries to add their mailbox to the messages they write.  Google
«How do I change the sender in Outlook?»

Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to
introduce the concept of an entity responsible for the last hop.
DMARC requires that the last hop is also the first one, or else that
the forwarding is mechanically smooth, an unparticipated transmission
which breaks no signatures.

Mailing lists match neither case.  Couldn't we consider From:
rewriting a sort of 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:

On 17 Jun 2020, at 13:27, Dave Crocker wrote:

On 6/17/2020 9:56 AM, Pete Resnick wrote:

No, the semantics of From: have not changed generally. [...]


So, really, DMARC has altered the semantics of the From: field to be the 
Sender: field.


Wait a minute: I think this point needs some clarification. We know that the 
pre-DMARC semantics of the From: field are "the entity that authored the 
message".



"Authoring" can have subtly different acceptations, though.  The exact sentence 
is:

 The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.
   [https://tools.ietf.org/html/rfc5322#section-3.6.2]

That is not so far from real.  The term "writing" sounds ambiguous, as it is 
not clear whether it means "typing" or "publishing", in the case of public 
mailing lists.  Given that Sender: is dedicated to the typist, I'd opt for the 
latter interpretation.


For a newspaper, if you pardon the analogy, the masthead is more visible than 
columnist signatures at the end of the articles.  For a mailing list, publisher 
visibility used to be provided by subject tags, leaving the From: intact.  Why? 
 Presumably, because it just worked that way.  However, if the MLM is the 
system responsible for writing, not modifying From: should be considered a 
violation.




My understanding of the meaning that DMARC added was, "The author of this
message, as expressed in the From: field, always has their messages properly
signed by the domain in the From: address." You seem to be saying that, no,
what DMARC did was changed the semantic to be, "The From: field now
represents the transmitter of the message (as used to be expressed in the
Sender: field when present), not the author, and that transmitter always has
their messages properly signed by the domain in the From: address".


Sender: was not meant to be the transmitter in that sense.  It was meant to be 
the secretary who writes on behalf of a responsible person or system.  It never 
had traction, AFAIK.  Most clients don't allow secretaries to add their mailbox 
to the messages they write.  Google «How do I change the sender in Outlook?»


Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to introduce 
the concept of an entity responsible for the last hop.  DMARC requires that the 
last hop is also the first one, or else that the forwarding is mechanically 
smooth, an unparticipated transmission which breaks no signatures.


Mailing lists match neither case.  Couldn't we consider From: rewriting a sort 
of message/rfc822-wrap lite?


It may well be that X-Original-From: is not a good convention.  There's a bunch 
of questions to clarify, such as whether users see the domain part of a mailbox 
address, whether they can tell authenticated messages, or whether they should 
be trusted at all.  However, unlike Sender ID, DMARC seems to have enough 
success to cause a semantic shift.  If it can result in a simplified filtering, 
I'd accept it.


RFC 5322 says display names are "associated" to a mailbox.  Certainly, changing 
just the addr-spec breaks the association and wreaks havoc to address books. 
The convention to write "MLM on behalf of" seems sound, but it takes sixteen 
columns of real estate in the folder view.  Can't we do better?



Best
Ale
--




































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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Pete Resnick]

On 17 Jun 2020, at 13:27, Dave Crocker wrote:


On 6/17/2020 9:56 AM, Pete Resnick wrote:
No, the semantics of From: have not changed generally. It's that some 
mailing lists have to change the semantics of From: in the face of 
the inability of DMARC to express the semantics that they want.


The two sentences seem to be in conflict. If there is a degree of 
practice that creates a different semantic for the field, then its 
semantics have changed, at least for the portion of email traffic.


You'll note the word "generally". Most of my email carries the same 
semantics it always has in From:. There is a small subset that doesn't. 
But (and not to get too philosophical here), even when the semantics 
aren't the same, it is often a surprise: I find that something didn't 
match my expectations, only to discover that the originator of the email 
didn't use the same semantics I was expecting as recipient. That doesn't 
necessarily constitute a change in semantics for the email, but a 
mismatch: The originator said "sunny" and I thought that meant "without 
clouds". Even if I figure out the mismatch, I might not agree to "the 
semantics changed"; I might prefer to go with, "The originator made a 
mistake." In the present case, some mailing lists are using the same old 
semantics and some are using a new set; that doesn't convince me that we 
have an interoperable semantics to which we have "changed".


Here's a simple operational test:  MUAs typically can aggregate 
messages 'from' the same author.  After all, that's always been the 
primary role of From, to indicate who created the content. Such 
aggregation is usually found to be helpful.


Historically -- for 40+ odd years -- this has worked for mail going 
through mailing lists.  Now it usually doesn't. I'd appreciate an 
explanation of how that does not constitute a change in semantics.


Of course, I'd be interested in the "usually" part. It's not true of my 
mailstore, but my mailstore is far from average. I do know that even on 
the local non-profit board to which I belong (and had no hand in setting 
up), the Outlook server uses the semantics to which I am accustomed, 
though maybe having a smaller list where most people using their gmail 
addresses makes it equally "not average".


Have a folder with a variety of messages from correspondents, where 
some of a person's messages are sent directly to you and some of their 
messages are sent through mailing lists that adapt the From: field 
content in order to avoid DMARC rejection.  The MUA will handle mail 
from the same person, but that went through these two different paths, 
as being from different sources.


I'm sure that happens.

DMARC relies on From: because it is the only field with an identifier 
that is always present. Sender is not reliably present, except 
virtually.  The nature of what DMARC is actually doing looks more 
like relying on the operations-related Sender: field than the 
author-related From: field.


DMARC has nothing to do with display of author information to a 
recipient, and everything to do with differential handling by a 
receiving filtering engine.  Were the Sender: field always present, 
that would be the one that DMARC should have used.


It could have chosen the more complicated, "Sender unless not present, 
in which case From". But yes, this bit I get. That said, there are 
people who have argued that From: was chosen because Sender: was not 
displayed. I think that's a silly argument, but it's one that people 
still believe.


So, really, DMARC has altered the semantics of the From: field to be 
the Sender: field.


Wait a minute: I think this point needs some clarification. We know that 
the pre-DMARC semantics of the From: field are "the entity that authored 
the message". Originators were expressing that meaning and recipients 
were interpreting that meaning. My understanding of the meaning that 
DMARC added was, "The author of this message, as expressed in the From: 
field, always has their messages properly signed by the domain in the 
From: address." You seem to be saying that, no, what DMARC did was 
changed the semantic to be, "The From: field now represents the 
transmitter of the message (as used to be expressed in the Sender: field 
when present), not the author, and that transmitter always has their 
messages properly signed by the domain in the From: address". Do I have 
that right? (And I presume that either way, these are de facto 
semantics, not intentional ones that are documented anywhere, right?)


The nature of the hack that mailing lists do, when altering the From: 
field, makes this clear:  They alter information about the operator 
handling the message, destroying the original information about 
content authorship.


Mailing lists that make other choices (throwing away messages from DMARC 
reject senders, denying subscriptions from them, or simply ignoring them 
and ending up with bad consequences) have obviously not gone along with 
the 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/17/2020 9:56 AM, Pete Resnick wrote:
No, the semantics of From: have not changed generally. It's that some 
mailing lists have to change the semantics of From: in the face of the 
inability of DMARC to express the semantics that they want. 



The two sentences seem to be in conflict. If there is a degree of 
practice that creates a different semantic for the field, then its 
semantics have changed, at least for the portion of email traffic.



Here's a simple operational test:  MUAs typically can aggregate messages 
'from' the same author.  After all, that's always been the primary role 
of From, to indicate who created the content. Such aggregation is 
usually found to be helpful.


Historically -- for 40+ odd years -- this has worked for mail going 
through mailing lists.  Now it usually doesn't. I'd appreciate an 
explanation of how that does not constitute a change in semantics.


Have a folder with a variety of messages from correspondents, where some 
of a person's messages are sent directly to you and some of their 
messages are sent through mailing lists that adapt the From: field 
content in order to avoid DMARC rejection.  The MUA will handle mail 
from the same person, but that went through these two different paths, 
as being from different sources.



DMARC relies on From: because it is the only field with an identifier 
that is always present. Sender is not reliably present, except 
virtually.  The nature of what DMARC is actually doing looks more like 
relying on the operations-related Sender: field than the author-related 
From: field.


DMARC has nothing to do with display of author information to a 
recipient, and everything to do with differential handling by a 
receiving filtering engine.  Were the Sender: field always present, that 
would be the one that DMARC should have used.


So, really, DMARC has altered the semantics of the From: field to be the 
Sender: field.  The nature of the hack that mailing lists do, when 
altering the From: field, makes this clear:  They alter information 
about the operator handling the message, destroying the original 
information about content authorship.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article <0f22234a-5a43-4473-8e67-b76c01cda...@episteme.net> you write:
>No, the semantics of From: have not changed generally. It's that some 
>mailing lists have to change the semantics of From: in the face of the 
>inability of DMARC to express the semantics that they want. ...

I'm with Pete here.  Please leave this bunch of worms in the can.

R's,
John

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/17/20 4:23 AM, Alessandro Vesely wrote:
> On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote:
>> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
>>
>>> Even if you ignore my line of reasoning, I think that Ale made in the OP a
>>> compelling case that the practice of From rewriting is here to stay.
>>
>> As a practical matter, that's certainly true for the short to medium term, 
>> but
>> it doesn't follow that the IETF should standardize the practice.
> 
> 
> There are a few shortcomings of From: rewriting, which could be mitigated 
> adopting suitable conventions.  For example, MUAs' replying to author, or 
> storing rewritten addresses in address books.
> 
> As evidenced in the page cited[*], methods 1.* are characterized by being MLM 
> side workarounds[†].  That is, they can be applied unilaterally, without 
> collaboration nor mutual support.  A state of affairs dictated by the lack of 
> standardization.
> 
> Now, if we make a semantic effort, we must recognize that the address of 
> From: as a matter of fact refers to the "managing editor" of the 
> corresponding mail flow, whereas the display name may indicate the actual 
> author.  To say nothing of the Sender: field, which wasn't designed for that 
> role anyway.  That's how email has evolved after introducing authentication.  
> I'd hope rfc5322bis will recognize those changes.  Meanwhile, if we gather 
> consensus on how to do it better, it'd be fair to write it down, no?

There at least needs to be a consensus and an official-looking place that we 
can point intermediaries when they're getting hit by the DMARC train; as policy 
publication and enforcement accelerates.  A M3AAWG BCP, perhaps?

Some MLM operators think that setting the Sender header is recommended/good 
enough.  Some MUAs display the Sender instead of the From if it's set, which is 
why I think some people think it's equivalent to changing the From header.  
That wiki[*] doesn't even mention the Sender header, so it doesn't really serve 
as a mechanism to dissuade the notion.

If there is no consensus on a single recommendation, then perhaps there needs 
to be more than one recommendation articulated in a preferential, guided, 
fashion:
1) If 100% of receivers will trust ARC from the intermediary - do X
2) If DKIM signing and intermediary survival is 100% - do Y
3) Else, do Z
etc...
Along with recommendations for each party regarding what they should do in each 
situation. 

Those of us who are opinionated about this topic can focus our arguments on the 
order/criteria/nuances of the recommendations rather than trying to agree on a 
single one.

The main benefit to making the recommendation(s) more standard is that it will 
serve to help intermediaries configure things in a "DMARC compatible" fashion 
and justify any change as necessary to skeptical stakeholders.  It will also 
serve as a way for IT staff to evaluate alternative software/services if they 
are considering upgrades vs. replacement.


> [†] Hm... except for 1.9 TPA.  It should be moved downward, methinks. 

Seems in the Cooperative category.  Maybe there needs to be a distinction 
between Sending (user/MSA vs domain owner?) vs Intermediary solutions?  Or a 
matrix to capture different qualities.  I don't know, there's a lot about that 
doc that makes it hard for an average person even know where to start tackling 
the problem.  Most people don't have years of experience in the email domain to 
understand all of the nuances.

Jesse

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Pete Resnick]

On 17 Jun 2020, at 4:23, Alessandro Vesely wrote:

There are a few shortcomings of From: rewriting, which could be 
mitigated adopting suitable conventions.  For example, MUAs' replying 
to author, or storing rewritten addresses in address books.


As soon as you start down that path, you have eliminated one of the 
purported values of From: alignment: MUAs will start using those 
conventions (X-Original-From:, decoding encoded Froms) and display that 
information to the user instead of what's in the From: field, in which 
case you're going to need X-Original-From: alignment, and down the 
spiral we go. (For those who are amused by such things, do a web search 
for "X-X-Sender".) I am not convinced by many of the arguments for From: 
alignment, and think the problems lie with the lack of semantics able to 
be conveyed by a DMARC record in these cases, but I seem to be in the 
rough on these points. But there is no magic bullet in "suitable 
conventions".


Now, if we make a semantic effort, we must recognize that the address 
of From: as a matter of fact refers to the "managing editor" of the 
corresponding mail flow, whereas the display name may indicate the 
actual author.


No, the semantics of From: have not changed generally. It's that some 
mailing lists have to change the semantics of From: in the face of the 
inability of DMARC to express the semantics that they want. I can get 
together with a group of my friends and decide that the word "sunny" 
really means "cloudy", but unless the whole English-speaking world is on 
board with me, communication is bound to have problems.


To say nothing of the Sender: field, which wasn't designed for that 
role anyway.


Sender: has had pretty much the same definition back to RFC 733. It was 
perfectly designed for "the thing that sent the message, independent of 
the author."



That's how email has evolved after introducing authentication.


For most email, the meanings haven't changed at all. For a certain class 
of mail, authentication of a certain sort has forced arbitrary changes 
that have made the semantics ambiguous as compared to the past.



I'd hope rfc5322bis will recognize those changes.


I sure hope not.

Meanwhile, if we gather consensus on how to do it better, it'd be fair 
to write it down, no?


Assuming you can gather consensus. I'm not convinced you can.

pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote:

On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:


Even if you ignore my line of reasoning, I think that Ale made in the OP a
compelling case that the practice of From rewriting is here to stay.


As a practical matter, that's certainly true for the short to medium term, but
it doesn't follow that the IETF should standardize the practice.



There are a few shortcomings of From: rewriting, which could be mitigated 
adopting suitable conventions.  For example, MUAs' replying to author, or 
storing rewritten addresses in address books.


As evidenced in the page cited[*], methods 1.* are characterized by being MLM 
side workarounds[†].  That is, they can be applied unilaterally, without 
collaboration nor mutual support.  A state of affairs dictated by the lack of 
standardization.


Now, if we make a semantic effort, we must recognize that the address of From: 
as a matter of fact refers to the "managing editor" of the corresponding mail 
flow, whereas the display name may indicate the actual author.  To say nothing 
of the Sender: field, which wasn't designed for that role anyway.  That's how 
email has evolved after introducing authentication.  I'd hope rfc5322bis will 
recognize those changes.  Meanwhile, if we gather consensus on how to do it 
better, it'd be fair to write it down, no?



Best
Ale
--

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

[†] Hm... except for 1.9 TPA.  It should be moved downward, methinks.




























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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Scott Kitterman]

On Tuesday, June 16, 2020 2:53:22 PM EDT ned+dm...@mrochek.com wrote:
> > In article 
 you 
write:
> > >I for one am always amazed how much people use web forums, which are
> > >almost
> > >all universally worse at providing a reading interface or keeping people
> > >up-to-date on new messages... which might be why most of the one's I look
> > >at are nearly dead, maybe there are better ones that are active.
> > 
> > Well, there's Reddit, and um, er.  Flyertalk, I guess.
> > 
> > One thing web forum fans seem to miss is how poorly they scale. I
> > subscribe to at least 150 mailing lists, most of which are only active
> > occasionally. As mailing lists, that works fine. The busier ones go
> > into separate folders, less busy into a general folder, and MUAs tell
> > me which folders have new messages so I can scan through all of my
> > list mail about as fast as I can hit the tab key to move on to the
> > next message. This works equally well for public and private lists.
> > 
> > In theory RSS or Atom does this for web forums, in practice, it's
> > amazing how lousy their RSS support is and how lame RSS readers are
> > for public fora, and hopeless for private ones where you have to log in.
> 
> And that assumes the site supports RSS/Atom. Many don't.
> 
> The other problem with all of these tools is that someone else gets to
> decide how to organize your life. If you decide that two different fora
> should be grouped together, good luck getting your reader to do that for
> you.
> 
> But Slack is the true nadir of usability in this regard. I have dozens of
> channels I need to monitor, the breakdown of same is not remotely aligned
> with how I would prefer to consume them. Add in a complete crap UI, and I
> honestly can't think of a mail UI I've used that's worse. Not ever.

It's like someone took IRC and decided to actively worsen it.

Scott K



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[ned+dmarc]

> In article 
>  you 
> write:
> >I for one am always amazed how much people use web forums, which are almost
> >all universally worse at providing a reading interface or keeping people
> >up-to-date on new messages... which might be why most of the one's I look
> >at are nearly dead, maybe there are better ones that are active.

> Well, there's Reddit, and um, er.  Flyertalk, I guess.

> One thing web forum fans seem to miss is how poorly they scale. I
> subscribe to at least 150 mailing lists, most of which are only active
> occasionally. As mailing lists, that works fine. The busier ones go
> into separate folders, less busy into a general folder, and MUAs tell
> me which folders have new messages so I can scan through all of my
> list mail about as fast as I can hit the tab key to move on to the
> next message. This works equally well for public and private lists.

> In theory RSS or Atom does this for web forums, in practice, it's
> amazing how lousy their RSS support is and how lame RSS readers are
> for public fora, and hopeless for private ones where you have to log in.

And that assumes the site supports RSS/Atom. Many don't.

The other problem with all of these tools is that someone else gets to
decide how to organize your life. If you decide that two different fora
should be grouped together, good luck getting your reader to do that for
you.

But Slack is the true nadir of usability in this regard. I have dozens of
channels I need to monitor, the breakdown of same is not remotely aligned with
how I would prefer to consume them. Add in a complete crap UI, and I honestly
can't think of a mail UI I've used that's worse. Not ever.

Ned

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article  
you write:
>I for one am always amazed how much people use web forums, which are almost
>all universally worse at providing a reading interface or keeping people
>up-to-date on new messages... which might be why most of the one's I look
>at are nearly dead, maybe there are better ones that are active.

Well, there's Reddit, and um, er.  Flyertalk, I guess.

One thing web forum fans seem to miss is how poorly they scale. I
subscribe to at least 150 mailing lists, most of which are only active
occasionally. As mailing lists, that works fine. The busier ones go
into separate folders, less busy into a general folder, and MUAs tell
me which folders have new messages so I can scan through all of my
list mail about as fast as I can hit the tab key to move on to the
next message. This works equally well for public and private lists.

In theory RSS or Atom does this for web forums, in practice, it's
amazing how lousy their RSS support is and how lame RSS readers are
for public fora, and hopeless for private ones where you have to log in. 

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Header munging, not ARC, can solve the mailing list problem

[Brandon Long]

On Mon, Jun 15, 2020 at 11:01 PM Murray S. Kucherawy 
wrote:

> On Sun, Jun 14, 2020 at 7:09 AM  wrote:
> > Thanks for you honesty. Then the relevant question is whether open and
> > interoperable standards still matter, or if they should be replaced by
> > proprietary web apps one feature at a time.
>
> Both have been around for a long time now and I've seen no evidence
> that the Internet public at large is keen to make such a wholesale
> migration.
>
> We apparently really, really like our mailing lists.
>

I for one am always amazed how much people use web forums, which are almost
all universally worse at providing a reading interface or keeping people
up-to-date on new messages... which might be why most of the one's I look
at are nearly dead, maybe there are better ones that are active.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Murray S. Kucherawy]

On Sun, Jun 14, 2020 at 7:09 AM  wrote:
> Thanks for you honesty. Then the relevant question is whether open and
> interoperable standards still matter, or if they should be replaced by
> proprietary web apps one feature at a time.

Both have been around for a long time now and I've seen no evidence
that the Internet public at large is keen to make such a wholesale
migration.

We apparently really, really like our mailing lists.

-MSK, hatless

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

Other uses of indirect mail:

My university offered an alumni account implemented as a relay to whatever 
hosting service I was using at the moment.   Never took them up on it, and glad 
that I did not.   Perhaps RFC 7960 talked about that scenario, because I think 
I have seen it mentioned in an IETF document.

Header munging vs Alternatives:

Header munging vs.  Perfect author attribution

I have been considering an alternative world where header munging is eliminated 
because author content is not modified and therefore author identified is fully 
verifiable using DKIM and DMARC.   Several concerns come to mind:

We do a fair amount of geographic filtering, so some of the postings to this 
list would be blocked, because of coming from countries where we do not do 
business.  Header munging provides a single point of origin; if one message is 
allowed through the geographic filters, then all messages will be allowed 
through.   If an exception is needed, the list member and system manager can be 
confident that only a single exception is necessary.

One of the reasons that IETF breaks DKIM is because it converts everything to a 
plain text.   This is a significant security benefit, by lowering the threat 
potential of the message.  It makes the IETF messages more trustworthy than if 
they came to me directly from the author.   Other mailing lists may use other 
criteria, but they should all use some sort of filtering to protect their 
reputation and their members.  Header munging allows me to distinguish between 
IETF-filtered traffic and other traffic.

As an extension of that point, successful sender authentication establishes 
identity, but it does not establish trust.   Trust is assigned by the 
recipient, largely based on experience, so message from unrecognized senders is 
given a low trust level by default.I know how to trust IETF.   I do not 
know whether to trust the next random person who contributes to this mailing 
list.

ARC assumes that after a user subscribes to a mailing list, he negotiates with 
his I.T. staff to have the mailing list operator authorized.   I expect this to 
be problematic for many users.
To mitigate these concerns, the non-munging solution would presume that 
recipient systems have the ability to filter differently between ( unknown 
sender + known mailing list ) and ( unknown sender without mailing list ).
To prevent spoofing of the mailing list, list identity would need to be 
verified as well as author identity.   As we add complexity to the inbound mail 
process design, some extra processing logic is applied to all messages, not 
just the mailing list messages.   How many filtering solutions will be unable 
or unwilling to add this complexity?

Others have already noted that the mailing list operator must choose a 
configuration without knowledge of what capabilities will exist in the 
receiving system message filter.   This seems to limit the range of possible 
solutions.

Given all of that, I think a non-munging solution would be more problematic for 
me than what IETF is already doing.

DF


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski  wrote:

>
> On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
> wrote:
>
>>
>> To follow-up on Brandon's note about Google's use of ARC, it's bigger
>> than
>> mailing lists and so is this problem.  It's any intermediary that
>> modifies a
>> message in such a manner that DKIM fails (SPF is only useful for direct
>> source
>> ADMD to destination ADMD tranmissions).
>>
>> I suspect that by hyper focusing on mailing lists, we're missing part of
>> the
>> problem.
>>
>> Scott K
>>
>>
> I think the mailing list issue looms so large as to block out everything
> else.  We (probably the chairs) should make sure we don't miss the the
> non-mailing list part of this problem.
>

That's what RFC 7960 (the first work product from this group) was all about.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Tim Wicinski]

On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
wrote:

>
> To follow-up on Brandon's note about Google's use of ARC, it's bigger than
> mailing lists and so is this problem.  It's any intermediary that modifies
> a
> message in such a manner that DKIM fails (SPF is only useful for direct
> source
> ADMD to destination ADMD tranmissions).
>
> I suspect that by hyper focusing on mailing lists, we're missing part of
> the
> problem.
>
> Scott K
>
>
I think the mailing list issue looms so large as to block out everything
else.  We (probably the chairs) should make sure we don't miss the the
non-mailing list part of this problem.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Scott Kitterman]

On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
> On 6/15/20 12:44 PM, John Levine wrote:
> > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write:
> > They both claim they're working on ARC.
> > 
> >> So, solution 1.3 has been naturally selected.  Does it need to be
> >> standardized, or is a BCP good enough? I'd still like to see a solution
> >> for receivers to "un-munge" trustworthy messages in a safe and
> >> consistent way.  Is that where ARC comes in?
> > 
> > No.  ARC lets mail systems accept list mail without munging.
> 
> How will a random intermediary know if random destination has implemented
> ARC and will trust their claim?  Even domains hosted by SaaS providers will
> have their own ARC reputation to manage, and might have to do things like
> configure munging on a per-recipient/domain basis, assuming the SaaS
> provider grants that level of control.  It's safer and easier to munge
> everything.

They won't.  Bypassing DMARC based on ARC requires some level of trust in the 
source of the message.

> Even if you ignore my line of reasoning, I think that Ale made in the OP a
> compelling case that the practice of From rewriting is here to stay.

As a practical matter, that's certainly true for the short to medium term, but 
it doesn't follow that the IETF should standardize the practice.

To follow-up on Brandon's note about Google's use of ARC, it's bigger than 
mailing lists and so is this problem.  It's any intermediary that modifies a 
message in such a manner that DKIM fails (SPF is only useful for direct source 
ADMD to destination ADMD tranmissions).

I suspect that by hyper focusing on mailing lists, we're missing part of the 
problem.

Scott K


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Tim Wicinski]

(no hats)

On Mon, Jun 15, 2020 at 2:18 PM Brandon Long  wrote:

>
> We sometimes use a different solution that isn't listed, which is
> basically where internal groups have access to the
> domain DKIM key, so they just re-sign.  Those aren't really an interesting
> case, though.
>
>
I used to encourage creating CNAMEs to DKIM keys that internal groups
managed themselves.
(DNS things like that are like nice BCP for DMARC deployment.)

Large corporations with legacy domains and multiple business units
operating semi-independently
are the same problem space as Jesse's University case.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/15/20 12:44 PM, John Levine wrote:
> In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write:
> They both claim they're working on ARC.
> 
>> So, solution 1.3 has been naturally selected.  Does it need to be 
>> standardized, or is a BCP good enough? 
>> I'd still like to see a solution for receivers to "un-munge" trustworthy 
>> messages in a safe and
>> consistent way.  Is that where ARC comes in?
> 
> No.  ARC lets mail systems accept list mail without munging.

How will a random intermediary know if random destination has implemented ARC 
and will trust their claim?  Even domains hosted by SaaS providers will have 
their own ARC reputation to manage, and might have to do things like configure 
munging on a per-recipient/domain basis, assuming the SaaS provider grants that 
level of control.  It's safer and easier to munge everything.  

Even if you ignore my line of reasoning, I think that Ale made in the OP a 
compelling case that the practice of From rewriting is here to stay.

Jesse

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write:
>On 6/15/20 2:33 AM, Alessandro Vesely wrote:
>> Let me quote a list of nineteen usable solutions:
>>     1.2 Turn off all message modifications
>>     1.3 Replace address with a generic one
>>     1.5 Rewrite addresses to forwarding addresses

>> That page hasn't been updated since 2016.  I don't think we can devise any 
>> new solution now.  There's
>been a natural selection.  Solution 1.3 prevailed, with a minority of lists 
>opting for 1.2.  Let's face
>facts.

Here in the IETF we use 1.5 but, yes.

>Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
>Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

They both claim they're working on ARC.

>So, solution 1.3 has been naturally selected.  Does it need to be 
>standardized, or is a BCP good enough? 
>I'd still like to see a solution for receivers to "un-munge" trustworthy 
>messages in a safe and
>consistent way.  Is that where ARC comes in?

No.  ARC lets mail systems accept list mail without munging.

R's,
John

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/15/20 2:33 AM, Alessandro Vesely wrote:
> Let me quote a list of nineteen usable solutions:
> 
>     1 Sending side workarounds
>     1.1 Exclude domains that require alignment
>     1.2 Turn off all message modifications
>     1.3 Replace address with a generic one
>     1.4 Add fixed string such as .invalid to addresses
>     1.5 Rewrite addresses to forwarding addresses
>     1.6 Message wrapping
>     1.7 Mandatory digests
>     1.8 Ignore DMARC bounces
>     1.9 Third Party Authorization
>     2 Recipient workarounds
>     2.1 Forwarder whitelist
>     3 Cooperative solutions
>     3.1 Shared whitelist
>     3.2 Per sender whitelist
>     3.3 Original-Authentication-Results header
>     3.4 Forwarding token
>     4 Authorization approaches
>     4.1 Authenticated Received Chain (ARC)
>     4.2 Signing key delegation
>     4.3 Relay through author domain server
>     4.4 Relay one copy through author domain server
>     4.5 Have author domains sign camera-ready posts
>     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]
> 
> That page hasn't been updated since 2016.  I don't think we can devise any 
> new solution now.  There's been a natural selection.  Solution 1.3 prevailed, 
> with a minority of lists opting for 1.2.  Let's face facts.

Precisely.  Let's work from a basis of reality.

I'm representing an EDU here.  Mailing lists are still heavily used in EDU for 
cross-institution and cross-sector collaboration.  They aren't going to be 
replaced by web forums or Yammer (or whatever corporate enterprise aspire to 
do) because faculty are open and collaborative by their nature.

We have over $1bn in research expenditures, most of which are funded by federal 
grants, and so we need to receive mail (sometimes indirectly) from federal 
agencies who are adhering to BOD 18-01.  A growing number of universities are 
publishing DMARC policies, and an unknown but presumably growing number of 
universities and agencies are enforcing DMARC policies for other domains.  It's 
becoming increasingly difficult to ignore DMARC.

Given that Microsoft and Google have essentially soaked up the entire EDU email 
market (hey, the price is right), let's say for sake of argument[*] that most 
EDUs are faced with 2 choices for their MLM:  Google Groups and Microsoft 365 
Groups.

Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

We can delve into *why*, but the reality is that we have failed with using 
Microsoft 365 Groups with external collaborators from domains that have adopted 
DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily 
use Microsoft 365 Groups for internal collaboration.  

Given that choice in this context, I believe that Google Groups will be chosen 
as their MLM by anyone taking DMARC into consideration.  I would not be 
surprised if Microsoft falls in line with solution 1.3.

So, solution 1.3 has been naturally selected.  Does it need to be standardized, 
or is a BCP good enough?  I'd still like to see a solution for receivers to 
"un-munge" trustworthy messages in a safe and consistent way.  Is that where 
ARC comes in?

Thanks,
Jesse

[*] Glossing over the fact that a university is not a single entity.  There are 
hundreds of entities within a university that all may individually choose their 
own solution.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article  you write:
>Let me quote a list of nineteen usable solutions:

I wouldn't call them all usable.  Proposed, perhaps.

> [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]
>
>That page hasn't been updated since 2016. 

If anyone has any new bright ideas, let me know and I'll send you a
password so you can update the wiki.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/14/2020 10:29 PM, Jim Fenton wrote:

On 6/13/20 8:17 PM, Dave Crocker wrote:

On 6/13/2020 7:53 PM, Jim Fenton wrote:

Alas, others do,

Other groups do all sorts of things.  They once mandated OSI, for
example.

Please explain how that is relevant, here and now.

The WG needs to consider the operational impact of DMARC deployment if
it is going to publish DMARC as a WG document.

Are you perhaps suggesting that the technical work of the IETF should
worry less about technical quality and more about possible use/abuse
by other agencies?

That is a false dilemma. We can (and should) consider possible use/abuse
of specifications we publish, but that does not imply worrying less
about technical quality.



Some people send spam.  We'd better deprecate all the email specifications.

Some agencies make silly or terrible rules.  And there are so many 
agencies. We'd better shut down the IETF because any specification can 
be abused and probably will be.


Perhaps you can offer a rather more focused, specific and deterministic 
concern?


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

On Sun 14/Jun/2020 19:18:43 +0200 Scott Kitterman wrote:

On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote:

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :

About this comment

If you teach users that "Joe User by Random Intermediary" is the same
as "Joe User", this expectation is doomed.> 
Based on the response to my previous post, "Trained User" is not a

meaningful concept, for purposes of this discussion [...]


That's not my point. My point is: this working group needs to make a
determination whether From addresses being displayed to the users
matters to DMARC or not, and then follow up consistently.

If it is, then don't break From addresses with munging.

If it is not, then use Sender field as a fallback for alignment, and
don't break From either.


I don't think that's the question at all.



+1, we're not going to reinvent DMARC, just elucidate it.



Whether user's knowledge of the from address has any bearing on anti-abuse
methods or not, it has plenty of value for other purposes.  DMARC is not all
of email.

 From rewriting is a gross hack that exists only due to dire necessity.  If
this working group can't move the space towards a more usable solution, I'm
not at all sure DMARCbis is worth the trouble.



Let me quote a list of nineteen usable solutions:

1 Sending side workarounds
1.1 Exclude domains that require alignment
1.2 Turn off all message modifications
1.3 Replace address with a generic one
1.4 Add fixed string such as .invalid to addresses
1.5 Rewrite addresses to forwarding addresses
1.6 Message wrapping
1.7 Mandatory digests
1.8 Ignore DMARC bounces
1.9 Third Party Authorization
2 Recipient workarounds
2.1 Forwarder whitelist
3 Cooperative solutions
3.1 Shared whitelist
3.2 Per sender whitelist
3.3 Original-Authentication-Results header
3.4 Forwarding token
4 Authorization approaches
4.1 Authenticated Received Chain (ARC)
4.2 Signing key delegation
4.3 Relay through author domain server
4.4 Relay one copy through author domain server
4.5 Have author domains sign camera-ready posts
[https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]

That page hasn't been updated since 2016.  I don't think we can devise any new 
solution now.  There's been a natural selection.  Solution 1.3 prevailed, with 
a minority of lists opting for 1.2.  Let's face facts.



Best
Ale
--







































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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/13/20 8:17 PM, Dave Crocker wrote:
> On 6/13/2020 7:53 PM, Jim Fenton wrote:
>> Alas, others do,
>
> Other groups do all sorts of things.  They once mandated OSI, for
> example.
>
> Please explain how that is relevant, here and now.
The WG needs to consider the operational impact of DMARC deployment if
it is going to publish DMARC as a WG document.
>
> Are you perhaps suggesting that the technical work of the IETF should
> worry less about technical quality and more about possible use/abuse
> by other agencies?

That is a false dilemma. We can (and should) consider possible use/abuse
of specifications we publish, but that does not imply worrying less
about technical quality.

-Jim



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Scott Kitterman]

On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote:
> Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
> > About this comment
> > 
> > If you teach users that "Joe User by Random Intermediary" is the same
> > as "Joe User", this expectation is doomed.> 
> > Based on the response to my previous post, "Trained User" is not a
> > meaningful concept, for purposes of this discussion [...]
> 
> That's not my point. My point is: this working group needs to make a
> determination whether From addresses being displayed to the users
> matters to DMARC or not, and then follow up consistently.
> 
> If it is, then don't break From addresses with munging.
> 
> If it is not, then use Sender field as a fallback for alignment, and
> don't break From either.

I don't think that's the question at all.

Whether user's knowledge of the from address has any bearing on anti-abuse 
methods or not, it has plenty of value for other purposes.  DMARC is not all 
of email.

>From rewriting is a gross hack that exists only due to dire necessity.  If 
this working group can't move the space towards a more usable solution, I'm 
not at all sure DMARCbis is worth the trouble.

Scott K



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman 
wrote:

>
> On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" 
> wrote:
> >I would like to understand what you mean by:
> >
> >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
> >wrote:
> >
> >> . . . ARC chains can be forged.
>
> Not sure what is confusing about that.  There's no requirement that
> signatures from previous hops still verify, so anyone can build an ARC
> chain that claims they got something from an arbitrary source.  ARC is only
> usable if you know you trust the source.
>

Perhaps we are debating semantics here, but a wholesale replacement of the
message content within the bounds of an ARC-chain-span is not what I would
call "forgery". One can not simply "build an ARC chain" because each
ARC-Seal header is cryptographically created by the entities which control
the respective private keys.

Trust matters, but really has nothing to do with the interoperability or
validity of the chain itself.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[devel2020]

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :

About this comment
 
If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed.


Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this 
discussion [...]


That's not my point. My point is: this working group needs to make a 
determination whether From addresses being displayed to the users 
matters to DMARC or not, and then follow up consistently.


If it is, then don't break From addresses with munging.

If it is not, then use Sender field as a fallback for alignment, and 
don't break From either.


[...] > I suggest that the "Mailing List Problem" is a problem that does not 
need to be solved (and evidence suggests that it> cannot be solved.)   I 
can think of no purpose served by a public mailing list, like this one, 
which is not be better > solved by a community forum website with user 
login.


Thanks for you honesty. Then the relevant question is whether open and 
interoperable standards still matter, or if they should be replaced by 
proprietary web apps one feature at a time.


Cheers,
Baptiste

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/13/2020 11:17 PM, Dave Crocker replied to Jim Fenton wrote:


Are you perhaps suggesting that the technical work of the IETF should
worry less about technical quality and more about possible use/abuse
by other agencies?


Dave,

It didn't look good when the IETF officially abandoned the ADSP 
protocol citing technical quality issues, yet helped a special 
interest group reintroduce "Super ADSP" under a different name with 
the same exact technical quality issues and fast tracked it as an 
informational RFC proposal.



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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Dave Crocker]

On 6/13/2020 7:53 PM, Jim Fenton wrote:

Alas, others do,


Other groups do all sorts of things.  They once mandated OSI, for example.

Please explain how that is relevant, here and now.

Are you perhaps suggesting that the technical work of the IETF should 
worry less about technical quality and more about possible use/abuse by 
other agencies?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/13/20 1:13 PM, John Levine wrote:
> In particular, there is no chance whatsoever that any DMARC policy
> will become mandatory, because the IETF doesn't do mandatory. 

Alas, others do, apparently because they see that DMARC has an RFC
number (even though it's informational). For example, in
https://cyber.dhs.gov/bod/18-01/ :

"All agencies are required to...enhance email security by...Within one
year after issuance of this directive, setting a DMARC policy of
“reject” for all second-level domains and mail-sending hosts."


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Benny Pedersen]

On 2020-06-13 22:13, John Levine wrote:
In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you 
write:
The "mailing list problem" was introduced into this discussion as an 
objection to DMARCs
progress, by implication suggesting that DMARC must be delayed until a 
solution is found which

creates no inconvenience to mailing list operators.


At this point I truly have no idea what your point is. The fact that
DMARC screws up mailing lists is enough of a problem that a lot of
people have put considerable time and money into inventing and
implementing ARC.


even if ietf tribble dkim sign mails it still gives

X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on 
localhost.junc.eu

X-Spam-Status: No, score=-9.3, required=5.0, Autolearn=unavailable
autolearn_force=no, LastExt=4.31.198.44
X-Spam-Rules_score: DKIM_INVALID=0.1,DKIM_SIGNED=-0.1,
HEADER_FROM_DIFFERENT_DOMAINS=0.25,LOCAL_WHITELIST_URI=-0.5,
MAILING_LIST_MULTI=-10.1,SPF_HELO_NONE=1.1,SPF_PASS=-0.1

hmm

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Benny Pedersen]

On 2020-06-13 18:42, John Levine wrote:
In article  you 
write:
I suggest that the "Mailing List Problem" is a problem that does not 
need to be solved (and evidence suggests that it cannot be solved.)   
I
can think of no purpose served by a public mailing list, like this 
one, which is not be better solved by a community forum website with 
user

login. ...


That's OK, the rest of us can.


if no one breaked dkim then arc would not even be needed

IMHO ietf is gone to far of fixing problems

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write:
>The "mailing list problem" was introduced into this discussion as an objection 
>to DMARCs
>progresss, by implication suggesting that DMARC must be delayed until a 
>solution is found which
>creates no inconvenience to mailing list operators.

At this point I truly have no idea what your point is. The fact that
DMARC screws up mailing lists is enough of a problem that a lot of
people have put considerable time and money into inventing and
implementing ARC.

More than that, DMARC exists, it's deployed, it's not going to change
beyond minor tweaks to clarify unclear parts of the spec, perhaps to
deprecate minor parts that don't work the way we anticipated, and
perhaps minor additions like https reporting.

In particular, there is no chance whatsoever that any DMARC policy
will become mandatory, because the IETF doesn't do mandatory. The word
MUST only means "do this to interoperate with other systems", not do
this or else.

R's,
John

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

The "mailing list problem" was introduced into this discussion as an objection 
to DMARCs progresss, by implication suggesting that DMARC must be delayed until 
a solution is found which creates no inconvenience to mailing list operators.

That concerns me, First, a a new solution has not really been proposed; all of 
the discussed options are already available to mailing list operators.  
Secondly, articulating a required mailing list operational mechanism is 
unlikely to produce rapid or uniform adoption.   The supposed problem is not 
big enough to warrant that much control over this initiative.




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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[John Levine]

In article  you write:
>I suggest that the "Mailing List Problem" is a problem that does not need to 
>be solved (and evidence suggests that it cannot be solved.)   I
>can think of no purpose served by a public mailing list, like this one, which 
>is not be better solved by a community forum website with user
>login. ...

That's OK, the rest of us can.

R's,
John

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

About this comment

 If you teach users that "Joe User by Random Intermediary" is the same 
as "Joe User", this expectation is doomed.

Based on the response to my previous post, "Trained User" is not a meaningful 
concept, for purposes of this discussion.   However, a user who subscribes to a 
mailing list should be able to recognize its distinctive message 
characteristics, so I think training is not a significant issue.   I have had 
fun looking at the different ways that IETF mailing list entries are presented 
in my different MUAs.

More to the point:

I suggest that the "Mailing List Problem" is a problem that does not need to be 
solved (and evidence suggests that it cannot be solved.)   I can think of no 
purpose served by a public mailing list, like this one, which is not be better 
solved by a community forum website with user login.   Even in its heyday, I 
think mailing list subscribers were a narrow subset of email users, heavily 
skewed toward Unix-oriented technology people.   Solving the mailing list 
problem seems like saying, "I want a secure and reliable way to order my 
Walmart groceries using the text feature of my flip-phone."  It is time for a 
different technology.

There are other indirect mail scenarios that are problematic, but these seem 
well understood and I do not see that any improvement is available.   These 
include:
DKIM (configured at the sender), SRS Encoding (configured at the forwarder), 
and Trusted forwarder registration or another exception mechanism (configured 
at the recipient filter).Incoming email filters have inadequacies when 
looking backward on a forwarded message, but this mailing list is not concerned 
with specifying the desired features of incoming mail filters.
DF


From: devel2...@baptiste-carvello.net
Sent: 6/13/20 8:04 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list 
problem
Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or
consensual solution. Header munging is inadequate because:

1) It makes the wrong tradeoffs. DMARC started as a solution for a very
specific problem (phishing targetting high impact domains) and made
tradeoffs accordingly. Now that it is deployed as a general anti-spam
tool, the appropriate tradeoffs are different: most users are willing to
live with some degree of spam rather than have their communication
tampered with and their name associated with random intermediaries.
"Fait accompli" is not acceptable, even if you call it "de-facto standard".

2) It buys you nothing. As was discussed last week, DMARC by design
relies on the expectation that users (or their MUA's adress book) will
recognize legitimate From addresses. If you teach users that "Joe User
by Random Intermediary" is the same as "Joe User", this expectation is
doomed.

Cheers,
Baptiste

Le 12/06/2020 à 10:02, Alessandro Vesely a écrit :
> Hi all,
> I'm sorry I didn't queue to talk yesterday. After so many months without
> speaking one word of English, I really didn't feel like...
>
>
> *Why ARC cannot solve the mailing list problem*
> ===
>
> Assume all mailing lists in the world duly did ARC. Somewhat
> science-fictitious, given that some of them are not even able to add valid 
> DKIM
> signatures. Let's hypothesize they all did ARC, anyway. Would the mailing
> list problem be solved? No, because recipients cannot blindly accept DMARC
> failures just because there is an ARC-chain claiming authenticity. Doing so
> would completely defeat DMARC, because ARC chains can be forged.
>
> In order to safely override a reject or quarantine policy based on ARC, a
> receiver needs a complete list of legitimate mailing lists. Conversely, having
> such a list, a receiver can override DMARC failures also based on DKIM or SPF
> authentication. ARC adds nothing to the mailing list problem. (However, huge
> mailbox providers do have a complete list of legitimate MTAs. That's where ARC
> is useful, AIUI.)
>
>
> *From rewriting is the real thing*
> ==
>
> Rewriting From: is the de-facto standard. In a (science-fictitious) scenario
> where all mailing lists rewrite the From: header field, DMARC would just work
> smoothly.
>
> Hence, we have to specify an acceptable way to rewrite From:.
>
>
> I'd have said so.
>
> Best
> Ale
>

___
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] Header munging, not ARC, can solve the mailing list problem

[devel2020]

Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or 
consensual solution. Header munging is inadequate because:


1) It makes the wrong tradeoffs. DMARC started as a solution for a very 
specific problem (phishing targetting high impact domains) and made 
tradeoffs accordingly. Now that it is deployed as a general anti-spam 
tool, the appropriate tradeoffs are different: most users are willing to 
live with some degree of spam rather than have their communication 
tampered with and their name associated with random intermediaries. 
"Fait accompli" is not acceptable, even if you call it "de-facto standard".


2) It buys you nothing. As was discussed last week, DMARC by design 
relies on the expectation that users (or their MUA's adress book) will 
recognize legitimate From addresses. If you teach users that "Joe User 
by Random Intermediary" is the same as "Joe User", this expectation is 
doomed.


Cheers,
Baptiste

Le 12/06/2020 à 10:02, Alessandro Vesely a écrit :

Hi all,
I'm sorry I didn't queue to talk yesterday.  After so many months without
speaking one word of English, I really didn't feel like...


*Why ARC cannot solve the mailing list problem*
===

Assume all mailing lists in the world duly did ARC.  Somewhat
science-fictitious, given that some of them are not even able to add valid DKIM
signatures.  Let's hypothesize they all did ARC, anyway.  Would the mailing
list problem be solved?  No, because recipients cannot blindly accept DMARC
failures just because there is an ARC-chain claiming authenticity.  Doing so
would completely defeat DMARC, because ARC chains can be forged.

In order to safely override a reject or quarantine policy based on ARC, a
receiver needs a complete list of legitimate mailing lists.  Conversely, having
such a list, a receiver can override DMARC failures also based on DKIM or SPF
authentication.  ARC adds nothing to the mailing list problem.  (However, huge
mailbox providers do have a complete list of legitimate MTAs.  That's where ARC
is useful, AIUI.)


*From rewriting is the real thing*
==

Rewriting From: is the de-facto standard.  In a (science-fictitious) scenario
where all mailing lists rewrite the From: header field, DMARC would just work
smoothly.

Hence, we have to specify an acceptable way to rewrite From:.


I'd have said so.

Best
Ale



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely]

On Sat 13/Jun/2020 07:19:21 +0200 Hector Santos wrote:

On 6/12/2020 4:02 AM, Alessandro Vesely wrote:


*From rewriting is the real thing*
==

Rewriting From: is the de-facto standard.


I don't support it.


In a (science-fictitious) scenario where all mailing lists
rewrite the From: header field, DMARC would just work
smoothly.


Occam's razor. The simplest and most honorable protocol solution is to follow 
the specs.  DMARC will work just fine without tampering with headers if the 
list server simply honored the restrictive policy. It works greats!!


A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains, just like 
it is done here:


https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with 
restrictive domains. The existing subscriber becomes a read-only subscriber.



Restricting mailing list usage to domains with no DMARC policy is a hindrance 
to DMARC effectiveness.  Those mailing list cannot filter out unauthenticated 
spammers.




Hence, we have to specify an acceptable way to rewrite From:.


This is no acceptable way to tamper the mail in this way.  But I did suggest 
with following. For an example of what it did to my headers:


X-Original-From: Hector Santos 
From: Hector Santos 



Why is that unacceptable?

After all, the message comes from dmarc.ietf.org.  They are responsible for 
filtering.  The message comes from them.  You just authored it —compare with 
digest mode.


I like to see the author's name displayed in the folder view.  However, 
choosing how to rewrite should be an author's decision.


For another effect, if the list broadcasted messages maintaining the original 
From:, then isdg.net would receive an explosion of rows in the aggregate 
report, loosing the ability to match it with the mail they actually sent.



Best
Ale
--
























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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/13/2020 1:19 AM, Hector Santos wrote:

A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains,
just like it is done here:

https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with
restrictive domains. The existing subscriber becomes a read-only
subscriber.

We had very little complaints at the beginning. But the member, for is
own domain protection, had to use another list restrictive domain to
participate. Right now, it works this way and it works without
complaints.


That should be "another less restrictive or non-restricted domain"

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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Hector Santos]

On 6/12/2020 4:02 AM, Alessandro Vesely wrote:

Hi all,




*From rewriting is the real thing*
==

Rewriting From: is the de-facto standard.


I don't support it.


In a (science-fictitious) scenario where all mailing lists
rewrite the From: header field, DMARC would just work
smoothly.


Occam's razor. The simplest and most honorable protocol solution is to 
follow the specs.  DMARC will work just fine without tampering with 
headers if the list server simply honored the restrictive policy. It 
works greats!!


A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains, 
just like it is done here:


https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with 
restrictive domains. The existing subscriber becomes a read-only 
subscriber.


We had very little complaints at the beginning. But the member, for is 
own domain protection, had to use another list restrictive domain to 
participate. Right now, it works this way and it works without complaints.



Hence, we have to specify an acceptable way to rewrite From:.


This is no acceptable way to tamper the mail in this way.  But I did 
suggest with following. For an example of what it did to my headers:


X-Original-From: Hector Santos 
From: Hector Santos 

In order to close the loophole the rewriting has opened, in addition, 
to falsely associate my name with dmarc.ietf.org domain,  the rewriter 
needs to use a signer domain that matches the original protection.


dmarc.ietf.org is currently using::

v=DMARC1; p=none; 
rua=mailto:dmarc_agg@vali.email,mailto:dmarc-rep...@ietf.org


The dmarc.ietg.org policy should be, at a minimum, p=quarantine. 
dmarc.ietf.org is only used for rewriting when the submission has a 
restrictive author domain, so the dmarc.ietf.org should be restrictive.


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


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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Scott Kitterman]

On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)"  wrote:
>I would like to understand what you mean by:
>
>On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
>wrote:
>
>> . . . ARC chains can be forged.

Not sure what is confusing about that.  There's no requirement that signatures 
from previous hops still verify, so anyone can build an ARC chain that claims 
they got something from an arbitrary source.  ARC is only usable if you know 
you trust the source.

Which still leaves the question of what the value proposition is since if you 
trust the source, what more does ARC really do (I suspect that the answer is 
more tokens to run through your bayesian or whatever filter)?

Scott K

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

I would like to understand what you mean by:

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely  wrote:

> . . . ARC chains can be forged.
>

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