On 3/17/25 12:08 PM, Richard Clayton wrote:
In message<[email protected]>, Michael
Thomas<[email protected]> writes
On 3/16/25 5:34 PM, Richard Clayton wrote:
PPS: I'm don't understand why this requires the rt= to be limited
to just one address.
simplicity ... at the point at which an email is being signed it is not
possible to know how many recipients the receiving MTA will accept after
each MAIL FROM
Why is that "simple"?
because if you don't know which recipients will be grouped together you
cannot construct the rt= part of the DKIM2 header field. It also avoids
the MTA having to assess which recipients are only bcc'd
I dunno, if the To: header is all to the same domain, say, and they
match the rcpt-to like with an email conversation, you know that it's
safe to group them. Allowing multiple rcpt-to's doesn't seem to hurt
anything and it's completely up to the sender whether it wants to use
grouping rcpt-to's SMTP feature or not.If a sender wants to simplify its
life with this layer violation, it's perfectly at liberty to
code/configure it however they want and if that means that it's more
convenient to do a single rcpt-to at time, that's up to them and doesn't
require the protocol to mandate it.
Another point is that these proposed mf= and rt= could potentially be
useful for other uses. We never considered such a thing back then, but
if we're going to go there we should also make explicit whether the
sender wants the receiver to enforce anti-replay behavior rather than
implicitly through the presence of some other tags. Like
rpe=[true|false] (RePlayEnforce) or something like that where the
default is "false". Tags are cheap, after all. It would also make it
less confusing reading the draft, and a good place to have the
discussion of expected behavior by the receiver.
If an MTA wants to sign, why should it care how
many rcpt-to's it sends?
because the receiving MTA is on the lookout for unexpected copies of the
email and will reject them as being part of a replay attack
Except they aren't "unexpected" in the general case.
It intend each of the recipients, after all. I
don't get what the supposed security property is of limiting it to a
single rcpt-to. Is there one?
yes
Sorry this is not helpful at all. Being dismissive is not a good way to
get consensus at IETF.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
