On 3/18/25 12:30 PM, Richard Clayton wrote:
In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com>, Michael
Thomas <m...@mtcc.com> writes
>>>> 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.
when you get to SMTP time you may find that you are sending multiple
emails (because of limitations on RCPT TO counts) and those emails may
not go to the same server ... so how is the recipient going to do any
sensible assessment of whether a replay has occurred ?
The point here is that if an implementation can figure out how to do
that, the implementation should have that option. If the easiest way is
to just do single address rcpt-to's, that's fine but it doesn't require
a protocol level MUST to forbid multiple addresses on the rcpt-to. It
would be fine to add some informative text as to why a single address is
easier, but it doesn't need to enforced at the protocol level.
> 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.
the bad guys do not want to enforce anti-replay and they are the people
who construct the emails that get replayed.
This has nothing to do with with good guys and bad guys, it has to do
with a protocol level signal of what the sender intends for the receiver
to consider. Basically, explicit good, implicit not so much. And like I
said, an explicit tag gives an easy place to discuss the enforcement
algorithm which currently lacking or really hard to understand in this
draft.
Not wishing to have replay is something that a receiver wants not a
sender.
Well, neither of them want that. It can affect the sender's reputation
which I thought was the entire point of this exercise.
> Except they aren't "unexpected" in the general case.
as I pointed out a while back the "general case" today is one recipient
per email.
I'm sure that's true, but it doesn't alter the fact that it's still a
valid use case in the email architecture. I don't think we should be
building limitations to the email architecture unless it's absolutely
necessary, and thus far I haven't seen why it's necessary.
>>> 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 ... I should have said "yes, see above"
Sorry, I'm not seeing the security property. You've said above it makes
it more "simple". Simple might be desirable, but that's not a security
property.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
