On 3/6/25 4:06 PM, Allen Robinson wrote:
On Thu, Mar 6, 2025, 5:56 p.m. Michael Thomas <m...@mtcc.com> wrote:
1. I craft some spam and I test it across a range of anti-spam filters
(or just gmail's) and voila, I find one that will pass their filters
2. I then take that message and send it to my list of recipients. I
can use rcpt-to bunching or not. If I do a single rcpt-to per, I will
have to resign my spam for each recipient, but that doesn't seem like
an onerous requirement. I might grumble about it, but in the end of
the day I -- the spammer -- will do what is necessary.
The essence is that the message content got past the filters. Whether
it has to be done one-by-one or in batches seems like an operational
issue.
In any case, I think a larger problem is that to my knowledge the
draft doesn't even define the scenarios in which "replay" is a
problem, so if that's not the right scenario, that's on the draft
because it doesn't lay the problematic scenarios out.
You are close. The attack methodology was for a malicious user uses
the ESP's system to generate a message that's authenticated against
the ESP's domain, and then resend that unmodified at scale to other
recipients.
A spammer sending authenticated mail from a domain they control is not
DKIM replay, even if the content of the message was originally
generated by an ESP.
Ok, I think I might be getting it. So the inclusion of the mf= and rt=
is basically signaling to the receiver that the signer wants to limit
the scope of what sort of forwarding it finds acceptable.
This seems relatively straightforward for an ESP to always add those
tags and hope for the best, but what if it wasn't an ESP? What if it's
normal corpro mail where some of it is transactional and some of it just
normal user-user email. Will the MTA be tasked with deciding which need
to add those tags and those where it shouldn't?
That's what is sort of scary to me about this entire subject because the
authors seem to have a very, very narrow view of the email universe and
it's not at all clear to me how it interacts with the rest of the email
universe. I think that any solution should be prefaced with "first, do
no harm" for collateral damage, and it might be good for the motivation
to make that clear.
Mike
PS: I still have yet to see anything that requires a forklift upgrade of
DKIM.
PPS: I'm don't understand why this requires the rt= to be limited to
just one address. There might be practical reasons to break the
transactions up, but I get the impression that people think there is
some security property involved. If I, the signer, think a second
rcpt-to is ok, what is the problem?
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
