On 11/21/2022 5:03 PM, Jim Fenton wrote:
On 21 Nov 2022, at 16:07, Jon Callas wrote:
I really like the guidance that an MDA SHOULD remove a DKIM signature. I have
memories that we discussed just that even at the time, for a number of reasons.
I disagree with Jon (and Dave) on this. Spammers are notably agile — if some
mechanism they have been using stops working, they quickly adapt and develop a
workaround. In this case, they only need to arrange to have the signed message
relayed to an MTA they control, and their problem is solved. In many cases they
probably collect the signed messages from their own MTAs already.
Some spammers are. Many are not. Old techniques, that are widely
blocked, are still in use. Blocking them remains useful.
"Security" is often characterized as a game of making things more
expensive for bad actors. Raising the cost is a well-established
approach to quite a lot -- arguably all -- protection mechanisms.
There is only a very indirect benefit for the very large number of DKIM-aware
MTAs to change their behavior and remove DKIM signatures at delivery. This will
take a VERY long time to happen, and the problem persists in the meanwhile (and
the above adaptation on the part of spammers takes place as well).
You are making an argument that this won't get adopted, based on limited
incentives for the adopter. That challenge plagues all sorts protection
mechanisms.
To the extent that these receiving sites have a general interest in
reducing spam, there is a reasonable chance that they will see benefit
in community-wide adoption efforts.
Mostly this highlights to requirements for getting this -- and pretty
much any other change -- adopted:
1. easily available code, with a focus on getting it into the
popular code bases; and
2. active industry promotion.
It also addresses my long-standing complaint that DKIM is not supposed to be a
tracking and authenticity mechanism. Moreover, this is a much better solution
to my complaint than anything anyone has come up with, including my eccentric
foot-stamping about keys.
This came up in the context of the use of DKIM signatures on leaked email
messages to authenticate the leaked content. That is not the problem we’re
trying to solve here.
Collateral benefit is still a benefit. There's no requirement that it
be ignored just because it isn't/wasn't a goal.
On 11/22/2022 5:48 AM, Alessandro Vesely wrote:
On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote:
We actually seemed to like the idea, at least back then, that the
signature
survives delivery so that it can be validated at any point later.
Indeed, there are products, like Lieser's DKIM verifier plugin for
Thunderbird[*], which verify DKIM on the MUA.
Apparently the point I made, about local arrangements for optional
preservation, was missed.
On the average, it is ill-advised to discard a useful technique in order
to accommodate the mere potential of supporting a vanishingly small
community, where even that support would not provide meaningful efficacy.
DKIM efficacy is in the receiving filtering engine, not end-user
evaluation. In statistical terms -- out to a large number of decimal
points -- end-user evaluation now and forever occupies zero percent of
obtained efficacy.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
