Re: [dmarc-ietf] Mediation

[Dave Crocker]

On 6/19/2020 5:48 PM, Murray S. Kucherawy wrote:

I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.


While I can imagine devising something that would look appealing, I 
believe it would have had a foundation of sand, in terms of operational 
realities, since none of what it would be relying on was documented 
standards and, again, there was (and I suspect remains) a view that 
mailing list operators did not make good candidates for reliable 
adherence to IETF 'standards'.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Mediation and controlled forwarding

[John R Levine]

On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:

There's a chance that it is possible to specify a small range of
modifications and arrange a style of signing that could survive them.



A number of drafts were floated, as I recall.  I had a couple.


There's always my conditional signing hack, in which one puts a very weak 
signature on the message which says it only counts if it's resigned by X, 
where X is the expected mediator.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Mediation

[Murray S. Kucherawy]

On Fri, Jun 19, 2020 at 5:09 PM John Levine  wrote:
> >There's a chance that it is possible to specify a small range of
> >modifications and arrange a style of signing that could survive them.
> >So for originating and mediating sites that conform to that range, a
> >'preserved' original authentication might be possible.
> >
> >However...
> >
> >I don't remember enough detail from the original dmarc discussions, so I
> >don't remember how much of this was discussed, but I vaguely think it
> >was covered.
>
> It definitely came up in DKIM.  It rapidly became clear that there
> are many things that lists do that have simple user semantics but
> are hopeless to describe in terms of bytes in the message, e.g.,
> reordering or deleting MIME parts.

A number of drafts were floated, as I recall.  I had a couple.

In one case, I think it was a new DKIM signature tag.  The idea was to
place a small annotation on the message of some kind that effectively
meant something like "MTA X asserts that it added '[foobar]' to the
Subject: field".  Another might be the usual "--" followed by a short
signature added to a plain text (or maybe non-MIME) body.  A validator
could then try undoing that and repeating validation to see if the
author signature then verified.  At the time, the feedback was that
this was too fragile to get right, but I don't think anyone ever
looked at it in the 80-20 sense.  I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.

-MSK

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

Re: [dmarc-ietf] Message-ID, was Mediation

[John Levine]

In article <4b20eff9-0979-4695-a984-133e330e9...@email.android.com> you write:
>Why is the state of the message-id important?   You have mentioned it twice.

A great deal of mail software assumes that if two messages have the
same message-ID, they're the same message. We use this to avoid
showing the user the same message twice, e.g., if one copy arrives
directly and another via a list.

This has been standard practice for decades. I'm surprised you're not
familiar with it.

-- 
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] Mediation

[John Levine]

In article <3efe1445-4a58-cdf2-9c06-d8ffb3ce1...@gmail.com> you write:
>There's a chance that it is possible to specify a small range of 
>modifications and arrange a style of signing that could survive them.  
>So for originating and mediating sites that conform to that range, a 
>'preserved' original authentication might be possible.
>
>However...
>
>I don't remember enough detail from the original dmarc discussions, so I 
>don't remember how much of this was discussed, but I vaguely think it 
>was covered.

It definitely came up in DKIM.  It rapidly became clear that there
are many things that lists do that have simple user semantics but
are hopeless to describe in terms of bytes in the message, e.g.,
reordering or deleting MIME parts.

>That leaves just a staged trust model, establishing a basis of 
>accountability (and reputation) for the mediator sequence. Hence, ARC.

Agreed, it seems unlikely we can do any better.

R's,
John

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

Re: [dmarc-ietf] Mediation

[Dave Crocker]

On 6/19/2020 3:13 PM, Brandon Long wrote:
There were several attempts to come up with alternative signing 
schemes that would
allow messages to pass through mailing lists and still be verified as 
"untampered" with,

and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, 
and that would have been
sufficient and a better solution than From header rewriting. Everyone 
has their opinion on the must
haves for mailing list message modification, and it becomes quickly 
intractable.



There's a chance that it is possible to specify a small range of 
modifications and arrange a style of signing that could survive them.  
So for originating and mediating sites that conform to that range, a 
'preserved' original authentication might be possible.


However...

I don't remember enough detail from the original dmarc discussions, so I 
don't remember how much of this was discussed, but I vaguely think it 
was covered.


Anyhow, there is a long track record of difficulties getting mailing 
list systems and operators to adopt external standards, and it isn't 
clear (to me) that the small range would be useful enough.  These risk 
factors do not encourage pursuing the complexities and costs of a global 
standard.


That leaves just a staged trust model, establishing a basis of 
accountability (and reputation) for the mediator sequence. Hence, ARC.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Mediation

[Dave Crocker]

On 6/19/2020 2:20 PM, Pete Resnick wrote:
Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.



A bigger concern should be with thinking that such paternalism is 
appropriate.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Brandon Long]

On Fri, Jun 19, 2020 at 12:03 PM Pete Resnick  wrote:

> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>
> > The description of what a Mediator might do is not incompatible with
> > also viewing it as having characteristics of a publisher:
> >>
> >> ### [5.3](). Mailing
> >> Lists
> >>
> >>
> >>...
> >>In addition to sending the new message to a potentially large
> >> number
> >>of new Recipients, the Mailing List can modify content, for
> >> example,
> >>by deleting attachments, converting the format, and adding
> >> list-
> >>specific comments.
>
> Fair enough, but as you mention below, in the case of the common mailing
> list, the intent is simply to redistribute the message with minimal
> change (hence the retention of the Message-ID: and the From:). That
> said, I do disagree with the reasoning given with regard to why
> 5321.MailFrom has changed: It's not because of the authorship, but
> rather because it is responsible for the submission onto the network,
> just as the ReSender is in 5.2.
>
> > Note that in terms of email transport, it is posting a new message.
>
> Strictly in terms of transport, yes. But in terms of the layer above
> (the 5322 layer), it is usually the same message; see the second Note:
> in RFC 5322 section 3.6.4:
>
>Note: There are many instances when messages are "changed", but
>those changes do not constitute a new instantiation of that
>message, and therefore the message would not get a new message
>identifier.  For example, when messages are introduced into the
>transport system, they are often prepended with additional header
>fields such as trace fields (described in section 3.6.7) and
>resent fields (described in section 3.6.6).  The addition of such
>header fields does not change the identity of the message and
>therefore the original "Message-ID:" field is retained.  In all
>cases, it is the meaning that the sender of the message wishes to
>convey (i.e., whether this is the same message or a different
>message) that determines whether or not the "Message-ID:" field
>changes, not any particular syntactic difference that appears (or
>does not appear) in the message.
>
> > Mediators really have complete freedom to do whatever they want.  If
> > describing the full range of what a publisher might do, it would cover
> > the same range.
>
> Well, "complete freedom" in the sense that no Internet police prevent
> such actions. But for most mediators, large substantive (for interesting
> definitions of "substantive") changes are outside of the scope of their
> definitions, and would probably invite someone to say, "That's not being
> a mediator." Certainly that would happen in the case of an alias or a
> resender.
>

And if we knew how to encode and verify that the mediator sticks to that,
we could
enforce it with policy.

There were several attempts to come up with alternative signing schemes
that would
allow messages to pass through mailing lists and still be verified as
"untampered" with,
and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, and
that would have been
sufficient and a better solution than From header rewriting.  Everyone has
their opinion on the must
haves for mailing list message modification, and it becomes quickly
intractable.

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

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

[Pete Resnick]

On 19 Jun 2020, at 15:05, Douglas E. Foster wrote:

Why is the state of the message-id important?   You have mentioned 
it twice.


So, we've been talking about the semantics of messages sent by a mailing 
list. My contention has been that for many mailing lists, and 
particularly the ones we've been talking about, the intent is that the 
mailing list is simply resending messages on to the subscribers to the 
list. The semantics of the message are revealed in the headers: The 
From: header indicates who the author of the message is. And the 
message-id is a way for the resender of a message to indicate that it is 
"the same message" as a previous one that it received, and can used when 
"threading" messages in a conversation view or deleting duplicates for 
display purposes.



It is not a required header.


Well, kinda sorta. My apologies if you already know this; perhaps useful 
to others:


Be careful about MUST/SHOULD/MAY in IETF documents. Of Message-ID:, RFC 
5322 says:


   Though listed as optional in the table in section 3.6, every message
   SHOULD have a "Message-ID:" field.  Furthermore, reply messages
   SHOULD have "In-Reply-To:" and "References:" fields as appropriate
   and as described below.

And if you have a look at RFC 2119:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Which is to say, "SHOULD" means "MUST unless you really know what you're 
doing". We don't do requirements the way other standards folks do. Also 
from 2119:


   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

We don't do "conformance" in IETF by using MUSTs and SHOULDs and MAYs. 
It's all about interoperability.


In this case, read the sentence as, "Use a Message-ID:, because if you 
don't you may screw up what the receiver of the message needs to do. 
That said, there might be circumstances where you simply can't produce 
one, and the recipient is going to have deal with that possibility, but 
you had better have a pretty good reason."



It often uses a domain portion that is not a registered name.


It needn't be registered to be useful; only unique. That said, I'm not 
sure about "often".


The recipient has no way to know whether or not it has been changed 
during forwarding.


It could be signed, could it not?

I have tried to imagine a way to use message-id in message evaluation, 
but have given up.


Back to your original question: My comment about Message-ID: was not 
about whether it was particularly useful for DKIM/DMARC, but more about 
how its semantics are reflected in mailing list email messages.


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] Mediation

[Pete Resnick]

On 19 Jun 2020, at 16:15, Pete Resnick wrote:


[Offlist]


Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.


(*Sigh*)

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] Mediation

[Pete Resnick]

[Offlist]

On 19 Jun 2020, at 15:07, Dave Crocker wrote:


Please re-read my text...


If there is a specification ... I apologize that I don't know what it 
is.


These little passive-aggressive turns of phrase are not useful habits to 
teach to others on the list.


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] Mediation

[Pete Resnick]

We seem to be having a discussion with some premises misunderstood, so 
let me attempt to answer your message upside down, in hopes of undoing 
that:


On 19 Jun 2020, at 15:07, Dave Crocker wrote:


On 6/19/2020 12:02 PM, Pete Resnick wrote:

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.


Except you seem to be pressing this as essentially a requirement they 
have


Ah, no, I think that's the crux of the misunderstanding: I was 
responding to Alessandro, who I interpreted to be saying that *all* 
mailing lists were, by definition, publishers, defining a publisher like 
a newspaper, where the true author of the content are the folks in the 
masthead, even though they acknowledge individual authors in the 
by-line. I disagree with that view. Indeed, I think for most of the 
mailing lists we have been referring to in this discussion, they are not 
publishers in Alessandro's sense, but rather view themselves as 
redistributors of author messages. As 5598 points out, there is variance 
in how much "editing" is done by any given mailing list, but again, for 
the discussion we've been having about how the From: field should be 
used, we've been talking about mailing lists which do the sort of 
minimal editing of messages.


(For mailing lists that do more substantial editing, I may not be as 
motivated to keep the From: field unchanged. If we get more deeply into 
the discussion, it might be useful to start drawing more distinct 
circles around types of mailing lists.)


So the purpose of pointing to 5598 was simply to explain to Alessandro 
that redistribution of messages through the transport system does not 
ipso facto make something a publisher.



whereas I'm pressing it as a business decision


I'm not really sure what that means or how it is relevant to the 
discussion, but again, I think we've been talking past eachother for the 
last two messages.



not something inherent in the nature of mailing list behavior.


No, sorry. I meant to simply point out the converse: That becoming a 
publisher is not in the nature of mailing list behavior.


That said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.


I did not anything about MailFrom, or for that matter anything about 
any field with an identifier.


I didn't say you had. I brought it up only because I re-read the section 
in 5598 on mailing lists, and it makes this claim. Just objecting in 
passing (because it seems to support Alessandro's view), not because I 
thought you were making some claim about it.


I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets 
handling error messages?  That issue and behavior predates DMARC by a 
lot.  Probably two decades. Maybe more.


I agree. Which is why I thought it relevant to the overall discussion. 
It was not directed at a particular statement of yours.


But in terms of the layer above (the 5322 layer), it is usually the 
same message; see the second Note: in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are 
"changed", but
  those changes do not constitute a new instantiation of 
that

  message,


Except that there are many instances when messages might be changed 
that DO constitute a new instantiation of that message, and 5322 gives 
no guidance about what determine one versus the other.


That's not true. In what you elided:

  In all
  cases, it is the meaning that the sender of the message wishes to
  convey (i.e., whether this is the same message or a different
  message) that determines whether or not the "Message-ID:" field
  changes, not any particular syntactic difference that appears (or
  does not appear) in the message.

It doesn't give any algorithmic guidance, if that's what you meant.

None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the 
messages it is re-posting.


Well, it seems exactly to that point. See above.

That most seek to preserve essentially all of the author's text is 
fine, but whether and how much is more of a 'business' decision than a 
technical one.


We appear to be in violent agreement, as the quip goes. Importantly, I 
think we agree that if a mailing list decides to preserve the original 
From: field, in an attempt to preserve all of the author's semantics, 
they are not "doing it wrong", as Alessandro's message appears to claim.


I didn't mean anything so nit-picky.  I mean that they are providing 
a value-added service to users and have their own agency to 

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

[Douglas E. Foster]

Why is the state of the message-id important?   You have mentioned it twice.It is not a required header.  It often uses a domain portion that is not a registered name.   The recipient has no way to know whether or not it has been changed during forwarding.  I have tried to imagine a way to use message-id in message evaluation, but have given up.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

[Dave Crocker]

On 6/19/2020 12:02 PM, Pete Resnick wrote:

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:


### [5.3](). 
Mailing Lists

   ...
   In addition to sending the new message to a potentially large 
number
   of new Recipients, the Mailing List can modify content, for 
example,

   by deleting attachments, converting the format, and adding list-
   specific comments.


Fair enough, but as you mention below, in the case of the common 
mailing list, the intent is simply to redistribute the message with 
minimal change (hence the retention of the Message-ID: and the From:). 


While, yes, that's the goal of some and probably most lists, that isn't 
quite what I said.


Please re-read my text, which notably did not contain the word 'minimal' 
and frankly had a different focus. That focus doesn't exclude 
minimality, but it wasn't the point.



That said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.


I did not anything about MailFrom, or for that matter anything about any 
field with an identifier.


I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets handling 
error messages?  That issue and behavior predates DMARC by a lot.  
Probably two decades. Maybe more.




Note that in terms of email transport, it is posting a new message.


Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are "changed", but
  those changes do not constitute a new instantiation of that
  message, 


Except that there are many instances when messages might be changed that 
DO constitute a new instantiation of that message, and 5322 gives no 
guidance about what determine one versus the other.


None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the messages 
it is re-posting.  That most seek to preserve essentially all of the 
author's text is fine, but whether and how much is more of a 'business' 
decision than a technical one.



Mediators really have complete freedom to do whatever they want.  If 
describing the full range of what a publisher might do, it would 
cover the same range.


Well, "complete freedom" in the sense that no Internet police prevent 
such actions.


I didn't mean anything so nit-picky.  I mean that they are providing a 
value-added service to users and have their own agency to decide what 
that service looks like. If they want to do assorted message 
modifications that are substantial, and if users of the service like the 
nature of those modification, the service is free to do them.  There is 
no specifications that dictate or even suggest, what one of the services 
must, or even should, do. So your reference to Internet police is 
ironic, because there is nothing to guide enforcement.



But for most mediators, large substantive (for interesting definitions 
of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not 
being a mediator." Certainly that would happen in the case of an alias 
or a resender.


If there is a specification that would move such a declaration out of 
people's personal opinions and into objective, technical assessment, I 
apologize that I don't know what it is.



But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.


Except you seem to be pressing this as essentially a requirement they 
have whereas I'm pressing it as a business decision, not something 
inherent in the nature of mailing list behavior.



The degree to which the mediator asserts itself more visibly to the 
recipient is probably the degree to which it looks more like a 
publisher and less like a simple relaying service.


And eventually, I would contend, less like a mediator.


I probably wouldn't like it either, but we don't have objective criteria 
for accurately and reliably applying or withholding the term, do we?


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

[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] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

[Pete Resnick]

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:


### [5.3](). Mailing 
Lists



   ...
   In addition to sending the new message to a potentially large 
number
   of new Recipients, the Mailing List can modify content, for 
example,
   by deleting attachments, converting the format, and adding 
list-

   specific comments.


Fair enough, but as you mention below, in the case of the common mailing 
list, the intent is simply to redistribute the message with minimal 
change (hence the retention of the Message-ID: and the From:). That 
said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.



Note that in terms of email transport, it is posting a new message.


Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are "changed", but
  those changes do not constitute a new instantiation of that
  message, and therefore the message would not get a new message
  identifier.  For example, when messages are introduced into the
  transport system, they are often prepended with additional header
  fields such as trace fields (described in section 3.6.7) and
  resent fields (described in section 3.6.6).  The addition of such
  header fields does not change the identity of the message and
  therefore the original "Message-ID:" field is retained.  In all
  cases, it is the meaning that the sender of the message wishes to
  convey (i.e., whether this is the same message or a different
  message) that determines whether or not the "Message-ID:" field
  changes, not any particular syntactic difference that appears (or
  does not appear) in the message.

Mediators really have complete freedom to do whatever they want.  If 
describing the full range of what a publisher might do, it would cover 
the same range.  


Well, "complete freedom" in the sense that no Internet police prevent 
such actions. But for most mediators, large substantive (for interesting 
definitions of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not being 
a mediator." Certainly that would happen in the case of an alias or a 
resender.


But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.

The degree to which the mediator asserts itself more visibly to the 
recipient is probably the degree to which it looks more like a 
publisher and less like a simple relaying service.


And eventually, I would contend, less like a mediator.

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

[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

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

[Dave Crocker]

On 6/19/2020 9:40 AM, Pete Resnick wrote:

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.



The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:




  5.3 . Mailing Lists

...
In addition to sending the new message to a potentially large number
of new Recipients, the Mailing List can modify content, for example,
by deleting attachments, converting the format, and adding list-
specific comments.


Note that in terms of email transport, it is posting a new message.

Mediators really have complete freedom to do whatever they want. If 
describing the full range of what a publisher might do, it would cover 
the same range.


But typical mediators are trying to maintain a sense and ability for the 
original author and the final recipient to experience an end-to-end 
message exchange.  The degree to which the mediator asserts itself more 
visibly to the recipient is probably the degree to which it looks more 
like a publisher and less like a simple relaying service.


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