On 1/5/25 4:58 PM, Richard Clayton wrote:
In message <[email protected]>, Michael
Thomas <[email protected]> writes
> 1) Why would knowing the changes in a message be useful?
because you can undo them and check the original signature is valid (or
not) and then use the reputation (and DMARC config) of the (purported)
sender to decide what to do with the email
you also know which entity did the changes so you may be able to develop
a reputation for the entity, when you determine -- in some manner --
whether their changes are benign or not
The charter, imo, should give the motivation or at least some inkling to
it. I mean, I was the one who thought salvaging modifications was a good
idea, but nobody else did. What's changed?
> 2) About Rcpt-to: why would knowing this be useful?
because it significantly restricts the opportunity for DKIM replay
That's not very clear. The charter should make clear why, imo.
> 3) The word "replayed" is sort of a red flag, imho. Are we really
trying to take
> a bite out of that apple again? If so, what justifies another
go-round? Do we
> know something new from last year?
we know much the same, but are proposing rather more changes to address
the issue (the current DKIM2 proposal is basically a souped up version
of one of the schemes proposed to deal with replay). Also replay is
only one of the issues that are being tackled (and for my $DAYJOB$ far
from the most important one).
Considering that the previous flamed out, why should the IESG allow a
new attempt? I mean, has something changed? It should at least state
what has changed and why the work is likely to achieve its goal when it
couldn't a mere year ago.
> 4) Again: DKIM doesn't have anything to say about the envelope. DKIM
works on
> headers and the message body. If getting some alignment between the
envelope
> layer and the message layer is useful, is that really a DKIM
problem? Wouldn't
> it better to just have a new header(s) and DKIM can just sign it
like normal?
we didn't think so
Why? I'm an outsider. I don't understand.
> I have to say when I saw this it looked pretty ominous to me. What
bounds on
> "email infrastructure" are we talking about? Any at all? Isn't that
pretty
> important that the full email community has a say on its bounds?
What is off
> limits?
we're not going to change anything in RFC5321/2 (and their new values)
albeit you won't be able to use more than one RCPT TO between MAIL FROM
and DATA (so bits of these documents will not be of much use any more)
The point is that such a broad seeming scope is pretty frightening. It
needs to be much more constained about what is in scope and what isn't.
I'd be very surprised if the IESG allowed such broad language.
> If we're going to get sucked into "trust us" by
> vendors/MAAWG who can't/won't say anything about their operational
issues, then
> we seem to be pretty much the same boat as last year.
the existing draft is pretty clear about some operational issues for
some people's $DAYJOB$s ... what tends to be off-limits is any labelling
of the Y-axis (though you can assume that for many people interested in
this work it comes in many many billions)
Which existing draft? Again, I'm coming at this just from having read
the charter and nothing else. That's the way most people are going to be
coming at this.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
