On Sat 12/Nov/2022 19:46:13 +0100 Wei Chuang wrote:
On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman <skl...@kitterman.com> wrote:
On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman <skl...@kitterman.com> wrote:
If a domain is signing spam and their reputation suffers as a result,
isn't that the system working as designed?
Yes, it is.
The slides
https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions
at Dispatch and the problem statement draft
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem
help describe the DKIM replay problem.
Thanks!
I think Section 2, *Mail Flow Scenarios* lacks the case of secondary MXes,
especially if they are provided by a different ADMD.
For a nit, *ESP Bulk Sender* has to be promoted to section title.
I think that between the draft and the discussion so far there are a few
classes of potential solutions:
1. Signers have taken responsibility for the message when they signed
it, so they get to live with the consequences of having done so (for this
purpose, I think the "message" is the signed content of the message). No
standards action or changes required to DKIM, except maybe modernizing
header field signing/over-signing recommendations to make replay at least
a little more difficult.
That's the easiest thing to do. Correctly listed as #1.
2. Introduce changes that break existing indirect mail flows. Standards
actions needed. Senders and receivers both need to make changes.
Standards actions needed. If we go down this path, would it be more
honest just to declare indirect mail flows obsolete/deprecated (based on
the prevalence of From re-writing on mailing lists, common practice may be
headed this way already due to DMARC). >>
3. Changes that modify expectations for legitimate indirect mail flows
that illegitimate indirect mail flows such as replay attacks will have
difficulty copying. These require changes by senders, indirect mail
processors (e.g. mailing list providers and forwarders), and receivers.
Unlikely to be effective until widely implemented.
2 and 3 look the same to me. We need to change something in the standards, and
that would require to adjust the wording in the proposed charter, where it says:
compatibility with existing deployments will be a critical factor,
and it is unlikely that proposals that lack compatibility will
proceed to publication.
A way of bridging this, particularly for approach 3, is to use legacy
authentication in addition to the replay resistant technique. Use the
replay resistant technique when available in preference to DKIM for DMARC
and reputation systems, but have it available to fall back to. A follow on
consideration then is why would anyone adopt the new replay resistant
technique. Presumably there would be deliverability incentives for senders
and forwarders to adopt the replay resistant technique (due to the negative
reputation effects DKIM replay has) and for receivers to avoid escalations.
In any case, I think the above categorization is pretty reasonable.
The two proposed replay resistant cryptographic domain based protocols that
leverage ARC seem to be difficult to implement or a mailing list with thousands
final recipients or a multi-hop forwarding.
What I've seen is that the Received header shows the delivery of the
message to the initial recipient, followed by a new set of Received
headers that shows that the message has been resent. Sometimes the
spammer leaves behind other clues like duplicate headers like multiple
Date, Message-id or Subject headers.
We cannot rely on spammers' habits.
I'd rather note that recipients not in To:/Cc:, when legal, require prior
arrangement. Bcc:, depending on use cases, requires either an explicit or an
implicit agreement. Admins set up secondary MXes and inbound filtering
services. Users subscribe to mailing lists ans newsletters, and request
forwarding (when used for email portability). In addition, in the latter
cases, messages to the final recipient have a single envelope recipient. That
feature can be used to setup per-user whitelists, to be updated concurrently
with the subscription/ forwarding setup.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
