[I assume this was intended for the list too?]
On 3/17/25 8:10 AM, Allen Robinson wrote:
On Sun, Mar 16, 2025 at 7:47 PM Michael Thomas <m...@mtcc.com> wrote:
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.
Not at all. The sender only controls the destination for the message
that has its signature as the most recent one. The receiver of that
message is free to resign and send it along to a new destination.
I think we're saying pretty much the same thing: when a receiver
receives a signature with a rt= that differs from the 821.rcpt-to of
that hop, it indicates that the sender considers that bogus since it
could be a replay. Exactly what the receiver is supposed to do with it
is probably open for discussion, or maybe just undefined since that is
beyond the protocol's bounds, similar to what happens when a signature
doesn't verify, etc. One choice might be to resign it and forwards it
though.
We will need to figure out what to do for the case of a DKIM2
originator -> DKIM1 forwarder -> DKIM2 mailbox, since the forwarder
wouldn't know to resign and it would end up looking like replay once
it's sent to the mailbox.
Generally speaking, all of these use cases being diagrammed out would be
really helpful. It's not been the easiest keeping track of what the
implications are, but maybe that's just me.
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?
Even if this were required (it's not, see above) requiring that a MTA
be able to make the decision about what does/does not get included in
the signature header seems ok to me.
On a meta level, it's not clear whether the intention is for inclusion
of the mf= and rt= tags are required or whether they are optional such
that the signer isn't asking for some differential handling. As I've
said elsewhere, having some sort of explicit signaling mechanism of the
sender's intent would probably be better. I know this isn't a protocol
draft, but it would be helpful to know whether the intent is to always
require this, or only as necessary.
That said, it would probably be good to start a discussion about what
the overview ought to contain or not. That is, is it akin to a problem
statement or does it want to mix potential solution space elements with
it. I tend to like problem statements better because they don't get as
wrapped around the axle arguing about potential solutions when we aren't
paying attention to what the problem(s) are.
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?
Simplicity is the primary driver to having this be a requirement.
There are cases (BCC, mailing lists) where it's very much required
that copies delivered to each recipient do not include the addresses
of other recipients. For the simple case of mail sent only to
addresses listed in the message's headers (To/Cc) it might be ok to
have multiple.
As I've said elsewhere, simplicity can easily be a sender/signer's
decision and doesn't need to be a protocol mandate. The way this reads
right now it seems there is some argument beyond "simplicity" , which is
confusing. I will say that I'm probably not the only one who finds that
this requirement is something of a red flag and will probably trigger a
lot of push back in the larger community. Unless it's absolutely needed,
my take is that it would be that it's better to let sleeping dogs lay.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
