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

[Michael Thomas <[e-mail]>]

On 11/30/20 8:56 PM, Brandon Long wrote:
>
>
> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <[e-mail] 
> <mailto:[e-mail]>> 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