Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/5/20 12:56 PM, John Levine wrote:


2) Last week someone was complaining about the expense of the
signatures in ARC seals, now multiple signatures don't hurt anything.
While I agree with the latter sentiment, what changed?

It means that you can't control somebody else's infrastructure. We can 
control whether standards are created carefully and thoughtfully.


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article  you write:
>> I dunno how special that case is, but there are lots of cases where mail 
>> passes
>> through multiple layers of ARC signing mutations.
>>
>> I routinely get mail from Microsoft's farm with an ARC seal or two
>> that has never been near a mailing list. Any time a MS user sends a
>> message to one of my lists, it'll emerge with at least two ARC
>> signatures.
>
>Getting multiple signatures from the originating domain doesn't hurt 
>anything. It's a little wasteful, but that's it.

a) The point of ARC seals is that the cv=pass in seal N tells you that
the signature in seal N-1 was good when the message arrived, so you
can do your filtering based on the state of the message each time it
was modified. DKIM doesn't do that.

2) Last week someone was complaining about the expense of the
signatures in ARC seals, now multiple signatures don't hurt anything.
While I agree with the latter sentiment, what changed?

R's,
John

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/5/20 10:29 AM, John Levine wrote:

In article  
you write:

mailing list to mailing list mail is very common in GSuite, but maybe we're
a special case.

I dunno how special that case is, but there are lots of cases where mail passes
through multiple layers of ARC signing mutations.

I routinely get mail from Microsoft's farm with an ARC seal or two
that has never been near a mailing list. Any time a MS user sends a
message to one of my lists, it'll emerge with at least two ARC
signatures.


Getting multiple signatures from the originating domain doesn't hurt 
anything. It's a little wasteful, but that's it.


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article  
you write:
>mailing list to mailing list mail is very common in GSuite, but maybe we're
>a special case. 

I dunno how special that case is, but there are lots of cases where mail passes
through multiple layers of ARC signing mutations.

I routinely get mail from Microsoft's farm with an ARC seal or two
that has never been near a mailing list. Any time a MS user sends a
message to one of my lists, it'll emerge with at least two ARC
signatures.

R's,
John

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote:

On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely  wrote:

On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:

On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely  wrote:

On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:

On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely  wrote:

On 25/11/2020 20:16, Michael Thomas wrote:

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:

Without resorting to ARC, it is still possible to validate
author domain's signatures directly if the MLM just adds a
subject tag and a footer >

I agree that ARC isn't really needed to do this (trust the
last hop from the MLM and determine the original
authenticity from the MLM's perspective) 

I didn't mean to trust the MLM.  I meant remove the subject
tag and the footer, then the original DKIM signature verifies.
See:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>>

When I was at Cisco, with l= and some subject line heuristics I
could get probably like 90+% verification rate across the entire
company, a company that uses external mailing lists a lot.
Definitely not 100% though. >>

DKIM itself is not 100%.  You always have lines beginning with
"From " or occasional autoconversions. >>
l= doesn't cover multipart/alternative nor
Content-Transfer-Encoding: base64. In addition, the DKIM spec
discourages its usage and suggests that "Assessors might wish to
ignore signatures that use the tag." >

Right, some of the other dkim-light or diff concepts we discussed
would be better than using l= >
We again got hung up on the 100% solution, though... something that
handled subject-prefix and footer in a transport agnostic way might
have worked. 

I'm not clear about the meaning of "100%".  If an author domain puts
no DKIM signatures, there is no way to verify them.  Hence, some
compliance of the author domain has to be required. 
The same holds for conditional signatures.

The same holds for MLM transformations.


Yes, by 100% I meant of messages that were already authenticated and
therefore should continue to be authenticated through the relay. >>

That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's
no way it can continue to be authenticated through a relay. >>
OTOH, mailing lists and relays are two different beasts.  For one thing,
it is very unusual for a mailing list to send to another mailing list.
Thus, we can safely specify a non-stackable authentication method. >
mailing list to mailing list mail is very common in GSuite, but maybe we're 
a special case.  Part of that was that aliases were moved to the mailing 
list infra (which is definitely more of an "our problem" than everyone), but 
we also see common usage where companies make groups matching their 
hierarchy (the all company group goes to all department groups which go to 
all local groups etc).  We also see some where announce groups mix contrib 
groups, etc.  Especially since we also use the same groups as ACL groups for 
GSuite and Google Cloud, so hierarchical groups are very common.


I'm not familiar with that feature.  How does a list get subscribed to another 
list?


In general, a list accepts messages from subscribed users, so if dmarc-ietf 
distributed this message to another list which I'm not a subscriber of, it 
would not pass.  (From: rewriting changes that behavior.  For example, one 
could subscribe to a list which routinely rewrites From: on behalf of this 
list, dmarc-ietf.  If the former list traffic is very high, that subscribing 
could be a sort of DoS attack to us.)



(there was a recent common where someone said who needs an org chart when 
we have email, showing the list of footers for all of the org level mailing 
lists the message went to to get to them)


The mlm-transform draft (referenced above) limits footers to 10 lines of text, 
each shorter than 80 characters.  If the hierarchy is not deeper than 10,  the 
chart can fit within a single footer.  Note that every added line breaks all 
previous signatures.  However, only the author domain's signature is worth 
being recovered, as far as MLM transformations are concerned.  ARC can still 
certify the whole chain.


The 10 lines limit is arbitrary.  It is meant to avoid that recipients mistake 
the footer for the main part of the message.



(one construction of hierarchical announce lists that was not well 
considered did result in every person on the combined list getting 9000 
copies of messages to the list, so flattening lists is sometimes much 
preferred) >
Which isn't to say we couldn't work around it or do the work to flatten the 
lists, though it increases the complexity of the product (can you 
unsubscribe from the top level list but not a sub list?)


I guess some coordination among sublists is required anyway.

To recognize that a message arrives from a sublis

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Tue 01/Dec/2020 14:27:04 +0100 devel2020 wrote:

Le 01/12/2020 à 11:37, Alessandro Vesely a écrit :


[...] a meagre set of old-fashioned individuals who still dislike mass social 
media [...]


Can decisions please be made based on sound technical reasons rather
than intolerance and zealotry?



That was not meant to prompt the making of any decision.  It is a fact that 
mailing lists are not among the most popular communication tools.




Setting aside the form of your argument: no, contracting with Facebook
et al should not be a prerequisite for using the Internet for any
purpose. By the very definition of "open network".



I agree with that "should".


Best
Ale
--




















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/1/20 6:21 PM, Brandon Long wrote:



On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas > wrote:



On 11/30/20 8:56 PM, Brandon Long wrote:

Right, some of the other dkim-light or diff concepts we discussed
would be better than using l=

We again got hung up on the 100% solution, though... something
that handled subject-prefix and
footer in a transport agnostic way might have worked.  The fact
that DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd have to come
up with a new canonicalization
and get it to widespread adoption before the simple diff could
work.  Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I
imagine that's harder work than
even ARC.


Frankly all it would take is a google or another large mail
provider to publicly state that unless a mailing list supports BCP
XYZ, your mail will be subject to very strict scrutiny and likely
not delivered to get the attention of mailing list providers. That
was my suggestion back in the day but it was scoffed at because
people could point to some edge case that generates .001% of list
traffic and thus invalidating the entire approach. The best is
definitely the enemy of the good here.

People really need to keep in mind that service provider email is
not the only game in town. That point keeps getting lost.

arguably we're all here because a large mail provider did make such a 
change (though to be fair, there were plenty of others who wanted to 
make that change).


While Google might be able to help move things along, there would need 
to be strong community support for that, no one wants to go this alone 
and look like the big bully.


I also think that you're overestimating what we could do. Ultimately, 
we serve our customers, and they want their legitimate email, even if 
it doesn't support BCP XYZ.




Well obviously the BCP would have to come first and there would have to 
be community buy-in to create such a BCP, but a Google participating in 
creating such a BCP ought pique the interests of people who make mailing 
list software who obviously have the biggest stake in this.


It occurs to me that it might not even be a BCP. Maybe mailing lists can 
just create a header with sed commands to undo its changes :)


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[devel2020]

Le 01/12/2020 à 11:37, Alessandro Vesely a écrit :
> 
> [...] a meagre set of old-fashioned individuals who still dislike mass social 
> media [...]

Can decisions please be made based on sound technical reasons rather
than intolerance and zealotry?

Setting aside the form of your argument: no, contracting with Facebook
et al should not be a prerequisite for using the Internet for any
purpose. By the very definition of "open network".

Cheers,
BC

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:

On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely  wrote:

On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:

On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely  wrote:

On 25/11/2020 20:16, Michael Thomas wrote:

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:

Without resorting to ARC, it is still possible to validate author
domain's signatures directly if the MLM just adds a subject tag
and a footer>

I agree that ARC isn't really needed to do this (trust the last hop
from the MLM and determine the original authenticity from the MLM's
perspective)

I didn't mean to trust the MLM.  I meant remove the subject tag and
the footer, then the original DKIM signature verifies.  See:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/


When I was at Cisco, with l= and some subject line heuristics I could get
probably like 90+% verification rate across the entire company, a company that
uses external mailing lists a lot. Definitely not 100% though.



DKIM itself is not 100%.  You always have lines beginning with "From " or
occasional autoconversions.

l= doesn't cover multipart/alternative nor Content-Transfer-Encoding:
base64. In addition, the DKIM spec discourages its usage and suggests
that "Assessors might wish to ignore signatures that use the tag.">>


Right, some of the other dkim-light or diff concepts we discussed would be
better than using l=

We again got hung up on the 100% solution, though... something that handled
subject-prefix and footer in a transport agnostic way might have worked.


I'm not clear about the meaning of "100%".  If an author domain puts no
DKIM signatures, there is no way to verify them.  Hence, some compliance of
the author domain has to be required.

The same holds for conditional signatures.

The same holds for MLM transformations.



Yes, by 100% I meant of messages that were already authenticated and 
therefore should continue to be authenticated through the relay.



That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's no way 
it can continue to be authenticated through a relay.


OTOH, mailing lists and relays are two different beasts.  For one thing, it is 
very unusual for a mailing list to send to another mailing list.  Thus, we can 
safely specify a non-stackable authentication method.



Some of the conditional signatures of the "include a diff you can remove to 
validate the original" attempt seemed to fail on the theory that there were

too many things that couldn't be handled.  Ie, if your relay removes
attachments, including them back in a diff kind of breaks the whole point of
that... but how common is that (even less now with Yahoo Groups gone, but
possibly still some av/malware relays still do this).


Not to mention anonymous lists, which remove the OP identity completely.  They 
are DMARC-proof by themselves, with no additional twists.  My draft restricts 
footers to text/plain MIME type, to overcome the objection to l=.  Hence, if a 
list appends HTML parts (e.g. to use ), it doesn't qualify as DMARC-proof.



I think that one issue we've had is that DMARC is very mechanical and 
straight-forward, so anything that's fuzzy in response seems more

complicated.


It may seem fuzzy, but it's not.  The ietf list (i...@ietf.org), for example, 
adds no subject tag and no footer.  DKIM signatures should remain valid, then. 
 Yet, if posters sign Sender:, they fail.  I wouldn't call that fuzziness.  It 
is the very nature of the spec.  If you sign Received:, no relay can hold your 
signature over.



Best
Ale
--



















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Brandon Long]

On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas  wrote:

>
> On 11/30/20 8:56 PM, Brandon Long wrote:
>
> Right, some of the other dkim-light or diff concepts we discussed would be
> better than using l=
>
> We again got hung up on the 100% solution, though... something that
> handled subject-prefix and
> footer in a transport agnostic way might have worked.  The fact that DKIM
> isn't transport agnostic
> is an achilles heel to even that, though, since we'd have to come up with
> a new canonicalization
> and get it to widespread adoption before the simple diff could work.  Or
> require mailing lists to
> be a lot more strict in how they do their email rewriting, but I imagine
> that's harder work than
> even ARC.
>
> Frankly all it would take is a google or another large mail provider to
> publicly state that unless a mailing list supports BCP XYZ, your mail will
> be subject to very strict scrutiny and likely not delivered to get the
> attention of mailing list providers. That was my suggestion back in the day
> but it was scoffed at because people could point to some edge case that
> generates .001% of list traffic and thus invalidating the entire approach.
> The best is definitely the enemy of the good here.
>
> People really need to keep in mind that service provider email is not the
> only game in town. That point keeps getting lost.
>
arguably we're all here because a large mail provider did make such a
change (though to be fair, there were plenty of others who wanted to make
that change).

While Google might be able to help move things along, there would need to
be strong community support for that, no one wants to go this alone and
look like the big bully.

I also think that you're overestimating what we could do.  Ultimately, we
serve our customers, and they want their legitimate email, even if it
doesn't support BCP XYZ.

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 11/30/20 8:56 PM, Brandon Long wrote:



On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely > wrote:


On 25/11/2020 20:16, Michael Thomas wrote:

> When I was at Cisco, with l= and some subject line heuristics I
could get
> probably like 90+% verification rate across the entire company,
a company that
> uses external mailing lists a lot. Definitely not 100% though.


DKIM itself is not 100%.  You always have lines beginning with
"From " or
occasional autoconversions.

l= doesn't cover multipart/alternative nor
Content-Transfer-Encoding: base64.
In addition, the DKIM spec discourages its usage and suggests that
"Assessors
might wish to ignore signatures that use the tag."

Nobody said it can fix everything. It's just that those things are in 
the long tail. And that admonition sounds like it crept in there after 
rfc4871 when i wasn't paying attention. i find that a ridiculous 
overreaction and begs the question why.


Being able recover 90%+ signatures going through mailing lists made our 
scheme of spear-phish alerting very close to viable. We never got to the 
point of having to make that call because there was just too many crufty 
email servers in the company that didn't use the centralized email path 
to insure their messages were signed. That had nothing to do with 
whether our scheme could work or not.





Right, some of the other dkim-light or diff concepts we discussed 
would be better than using l=


We again got hung up on the 100% solution, though... something that 
handled subject-prefix and
footer in a transport agnostic way might have worked. The fact that 
DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd have to come up 
with a new canonicalization
and get it to widespread adoption before the simple diff could work.  
Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I 
imagine that's harder work than

even ARC.




Frankly all it would take is a google or another large mail provider to 
publicly state that unless a mailing list supports BCP XYZ, your mail 
will be subject to very strict scrutiny and likely not delivered to get 
the attention of mailing list providers. That was my suggestion back in 
the day but it was scoffed at because people could point to some edge 
case that generates .001% of list traffic and thus invalidating the 
entire approach. The best is definitely the enemy of the good here.


People really need to keep in mind that service provider email is not 
the only game in town. That point keeps getting lost.


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:
> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely  wrote:
> 
>> On 25/11/2020 20:16, Michael Thomas wrote:
>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
 On 25/11/2020 19:24, Jesse Thompson wrote:
> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
>> Without resorting to ARC, it is still possible to validate author
>> domain's signatures directly if the MLM just adds a subject tag
>> and a footer>
> I agree that ARC isn't really needed to do this (trust the last hop
> from the MLM and determine the original authenticity from the MLM's
> perspective)
 I didn't mean to trust the MLM.  I meant remove the subject tag and
 the footer, then the original DKIM signature verifies.  See:
 https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
>>>
>>> When I was at Cisco, with l= and some subject line heuristics I could get
>>> probably like 90+% verification rate across the entire company, a company 
>>> that
>>> uses external mailing lists a lot. Definitely not 100% though.
>>
>>
>> DKIM itself is not 100%.  You always have lines beginning with "From " or
>> occasional autoconversions.
>>
>> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: 
>> base64. In addition, the DKIM spec discourages its usage and suggests
>> that "Assessors might wish to ignore signatures that use the tag.">>
> 
> Right, some of the other dkim-light or diff concepts we discussed would be
> better than using l=
> 
> We again got hung up on the 100% solution, though... something that handled 
> subject-prefix and footer in a transport agnostic way might have worked.

I'm not clear about the meaning of "100%".  If an author domain puts no DKIM 
signatures, there is no way to verify them.  Hence, some compliance of the 
author domain has to be required.

The same holds for conditional signatures.

The same holds for MLM transformations.


> The fact that DKIM isn't transport agnostic is an achilles heel to even
> that, though, since we'd have to come up with a new canonicalization and get
> it to widespread adoption before the simple diff could work.

As DKIM works in the vast majority of cases (yes, not 100%, but nearly), the 
idea to discombobulate it for the sake of a meagre set of old-fashioned 
individuals who still dislike mass social media is a showstopper.  Yet, since 
DMARC standardization itself avails of mailing lists, we may want to get some 
coherence.


> Or require mailing lists to be a lot more strict in how they do their email
> rewriting, but I imagine that's harder work than even ARC.

They are quite strict already.  For example, I received the message I'm 
replying to in both my top and dmarc folders.  Both copies of the message have 
the correct From:.  The MLM copy was authenticated like so:

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass reason="Original-From: transformed" (whitelisted) 
header.d=google.com;
  dkim=pass (whitelisted) header.d=ietf.org
header.b=zA0RRbSR;
  dkim=fail (signature verification failed, whitelisted) header.d=ietf.org
header.b=F65GxYqF

From: restoring is documented here:
https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans


Best
Ale
-- 

















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On 25/11/2020 20:16, Michael Thomas wrote:

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:
Without resorting to ARC, it is still possible to validate author domain's 
signatures directly if the MLM just adds a subject tag and a footer, like, 
for example, this list does.   While ARC solves "deep" forwarding problems, 
which may arise in the context of email address portability, MLM 
transformation reversion solves the simpler mailing list problem, including 
reverting munged From:'s.


I agree that ARC isn't really needed to do this (trust the last hop from the 
MLM and determine the original authenticity from the MLM's perspective)


I didn't mean to trust the MLM.  I meant remove the subject tag and the 
footer, then the original DKIM signature verifies.  See:

https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/


When I was at Cisco, with l= and some subject line heuristics I could get 
probably like 90+% verification rate across the entire company, a company that 
uses external mailing lists a lot. Definitely not 100% though.



DKIM itself is not 100%.  You always have lines beginning with "From " or 
occasional autoconversions.


l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: base64. 
In addition, the DKIM spec discourages its usage and suggests that "Assessors 
might wish to ignore signatures that use the tag."



Best
Ale
--



































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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article <695b8714-b174-e3d6-d6c0-1a1d535fb...@mtcc.com> you write:
>Not everything is service provider. We were investigating this from an 
>enterprise standpoint.
>
>And if you can't trust mailing traffic from providers what is the point 
>of ARC?

Um, please see the previous umpteen messages describing how ARC works
and how it addresses this particular problem.

R's,
John

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 11/25/20 12:31 PM, John Levine wrote:

In article ,
Michael Thomas   wrote:

When I was at Cisco, with l= and some subject line heuristics I could
get probably like 90+% verification rate across the entire company, a
company that uses external mailing lists a lot. Definitely not 100% though.

I think you will find that at very large mail systems like gmail and
Microsoft and Yahoo, 90% might as well be 0%. The volume of errors is
just too high and the number of complaints would be impossible.

While I almost never see the sort of spam leakage through mailing lists
that Brandon reports, I believe him when he says it's enough of a problem
that Gmail can't just whitelist traffic from mailing lists.



Not everything is service provider. We were investigating this from an 
enterprise standpoint.


And if you can't trust mailing traffic from providers what is the point 
of ARC?


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article ,
Michael Thomas   wrote:
>When I was at Cisco, with l= and some subject line heuristics I could 
>get probably like 90+% verification rate across the entire company, a 
>company that uses external mailing lists a lot. Definitely not 100% though.

I think you will find that at very large mail systems like gmail and
Microsoft and Yahoo, 90% might as well be 0%. The volume of errors is
just too high and the number of complaints would be impossible.

While I almost never see the sort of spam leakage through mailing lists 
that Brandon reports, I believe him when he says it's enough of a problem
that Gmail can't just whitelist traffic from mailing lists.

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] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

Hi,

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:
Without resorting to ARC, it is still possible to validate author 
domain's signatures directly if the MLM just adds a subject tag and 
a footer, like, for example, this list does.   While ARC solves 
"deep" forwarding problems, which may arise in the context of email 
address portability, MLM transformation reversion solves the simpler 
mailing list problem, including reverting munged From:'s.


I agree that ARC isn't really needed to do this (trust the last hop 
from the MLM and determine the original authenticity from the MLM's 
perspective)



I didn't mean to trust the MLM.  I meant remove the subject tag and 
the footer, then the original DKIM signature verifies.  See:

https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/



When I was at Cisco, with l= and some subject line heuristics I could 
get probably like 90+% verification rate across the entire company, a 
company that uses external mailing lists a lot. Definitely not 100% though.


Mike

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

Hi,

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:

Without resorting to ARC, it is still possible to validate author domain's signatures 
directly if the MLM just adds a subject tag and a footer, like, for example, this list 
does.   While ARC solves "deep" forwarding problems, which may arise in the 
context of email address portability, MLM transformation reversion solves the simpler 
mailing list problem, including reverting munged From:'s.


I agree that ARC isn't really needed to do this (trust the last hop from the 
MLM and determine the original authenticity from the MLM's perspective)



I didn't mean to trust the MLM.  I meant remove the subject tag and the footer, 
then the original DKIM signature verifies.  See:

https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/



Plus, if it eventually solves the "deep" forwarding issue, then ARC is 
certainly better than trying to follow received header chains, etc.



IMHO, that's where the real value or ARC lies.  Large mailbox providers forward 
lots of messages to one another, as set up by users, and they seem to prefer to 
forward messages anyway rather than filter before forwarding.  That's what John 
reported in:

https://mailarchive.ietf.org/arch/msg/dmarc/OmTzwzP9GuE1oF5m1TvUZVA799c



Anecdotally, after much debate, our team is leaning more towards *not* 
reverting munged From:'s from our own MLM

1. Until ARC has a reputation model that is commonly adopted, header munging 
isn't going to subside.  I still find MLM operators who are just now realizing 
that they have to munge messages.  We need to tell users that this is the new, 
growing, reality.



Yup.



2. If we only unmunge for our own domains' users' authoring messages to our own MLM, it 
has limited overall effect, and it distorts the user-reality story from point #1.  We 
would have to unmunge for all domains' authors sending to all "trusted" MLMs in 
order to give the users what they expect from their prior reality.

3. Since we can only unmunge for our own recipients, it just creates an 
inconsistent experience on top of the already inconsistent experience of the 
conditional munging most MLMs do based on the authors' DMARC policies.



If the original signature verifies, each MDA can restore the unmunged From: 
right before committing to local storage.  That way, the rewritten From: 
becomes a transfer artifact, not seen by users.



Best
Ale
--





















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Jesse Thompson]

On 11/25/20 11:30 AM, Alessandro Vesely wrote:
> Without resorting to ARC, it is still possible to validate author domain's 
> signatures directly if the MLM just adds a subject tag and a footer, like, 
> for example, this list does.   While ARC solves "deep" forwarding problems, 
> which may arise in the context of email address portability, MLM 
> transformation reversion solves the simpler mailing list problem, including 
> reverting munged From:'s.

I agree that ARC isn't really needed to do this (trust the last hop from the 
MLM and determine the original authenticity from the MLM's perspective), 
although I think that ARC somewhat standardizes what headers/value to look for 
(I may be wrong).  Plus, if it eventually solves the "deep" forwarding issue, 
then ARC is certainly better than trying to follow received header chains, etc.

Anecdotally, after much debate, our team is leaning more towards *not* 
reverting munged From:'s from our own MLM

1. Until ARC has a reputation model that is commonly adopted, header munging 
isn't going to subside.  I still find MLM operators who are just now realizing 
that they have to munge messages.  We need to tell users that this is the new, 
growing, reality.

2. If we only unmunge for our own domains' users' authoring messages to our own 
MLM, it has limited overall effect, and it distorts the user-reality story from 
point #1.  We would have to unmunge for all domains' authors sending to all 
"trusted" MLMs in order to give the users what they expect from their prior 
reality.

3. Since we can only unmunge for our own recipients, it just creates an 
inconsistent experience on top of the already inconsistent experience of the 
conditional munging most MLMs do based on the authors' DMARC policies.  

We would rather see:

3a) MLMs that munge for all messages regardless of the author's domain's DMARC 
policy 

3b) MLMs that allow operators to configure recipient destinations that they 
know are going to trust non-munged messages (via ARC or whatever)

Jesse

P.S. If anyone knows how to trick Google Groups into doing 3a and/or 3b, please 
ping me (off list is OK)

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

Hi,

On 25/11/2020 13:57, Douglas E. Foster wrote:
Indirect mail flows are difficult to detect.   SMTP address rewrite is already 
common practice for forwarding.



Return address rewriting is a Good Thing™, unlike From: rewriting.  I'd welcome 
forwarding my email, even if modified (I'm not a bank).  At the same time, I'd 
stop spam pretending to be coming directly from my server.  SPF -all yields 
such possibility, except that it sometimes stops internal forwarding at 
uncoordinated admds.  My proposed dp=reject would ameliorate spf-all while 
still being more permissive than p=reject.  A midway policy, which tackles the 
"mailing list problem" from the other side.



More to the point, John's interest is finding ways to increase the trust level 
for forwarded mail, while your idea says that direct mail is more trusted than 
indirect mail, which is the problem he is trying to overcome.



Yes, they are two different problems.


We need to be able to evaluate indirect mail based on both the submitter MTA. 
and the originator MTA.   ARC gets us started in that direction.   I think more 
filtering data is needed and am working on a proposal to that effect.



Without resorting to ARC, it is still possible to validate author domain's 
signatures directly if the MLM just adds a subject tag and a footer, like, for 
example, this list does.   While ARC solves "deep" forwarding problems, which 
may arise in the context of email address portability, MLM transformation 
reversion solves the simpler mailing list problem, including reverting munged 
From:'s.



Best
Ale
--




















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Douglas E. Foster]

Indirect mail flows are difficult to detect.   SMTP address rewrite is already 
common practice for forwarding.More to the point, John's interest is finding 
ways to increase the trust level for forwarded mail, while your idea says that 
direct mail is more trusted than indirect maill, which is the problem he is 
trying to overcome.We need to be able to evaluate indirect mail based on both 
the submitter MTA. and the originator MTA.   ARC gets us started in that 
direction.   I think more filtering data is needed and am working on a proposal 
to that effect.Doug

 Original message 
From: Alessandro Vesely  Date: 
11/25/20  6:28 AM  (GMT-05:00) To: dmarc-ietf  
Subject: [dmarc-ietf] A policy for direct mail flows only, was ARC 
questions 
On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote:
> ARC deals with the problem that most list software forwards everything
> with a subscriber's address on the From: line and does a lousy job of
> spam filtering. The question is if the entity sending the message to
> the list was who it purported to be.
>
> For example, if a message from a list fails DMARC alignment, but ARC
> says it was aligned on the way in, it's likely a real message from a
> subscriber. If it was unaligned on the way in, it's likely spam.


I publish p=none in order to avoid spurious rejections due to casual message
modifications that happen in transit.  However, I'm quite confident that SPF or
DKIM verify, since users submit messages through the right mail server.

Couldn't I address direct flows only?  Doing so would prevent a casual spammer
from abusing mailing lists I'm subscribed to by simply faking From:.

A direct flow is one were SPF credentials (helo name or return address) are
aligned with From:.  That includes some simple forwarding, but not mailing list
traffic.  Direct policy could be expressed as dp=.  Authenticate as usual,
either SPF or DKIM.  On failure, discard only if direct flow.  For example:
   v=DMARC1; p=none; dp=reject;

Makes sense?

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

[dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote:

ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering. The question is if the entity sending the message to
the list was who it purported to be. 


For example, if a message from a list fails DMARC alignment, but ARC
says it was aligned on the way in, it's likely a real message from a
subscriber. If it was unaligned on the way in, it's likely spam.



I publish p=none in order to avoid spurious rejections due to casual message 
modifications that happen in transit.  However, I'm quite confident that SPF or 
DKIM verify, since users submit messages through the right mail server.


Couldn't I address direct flows only?  Doing so would prevent a casual spammer 
from abusing mailing lists I'm subscribed to by simply faking From:.


A direct flow is one were SPF credentials (helo name or return address) are 
aligned with From:.  That includes some simple forwarding, but not mailing list 
traffic.  Direct policy could be expressed as dp=.  Authenticate as usual, 
either SPF or DKIM.  On failure, discard only if direct flow.  For example:


   v=DMARC1; p=none; dp=reject;

Makes sense?

Best
Ale
--






















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