We have been having a fairly extended discussion, much of which seems
hypothetical - “I don’t like DEMARC because I am worried that ... with mailing
lists”. I wonder if we could take a moment to try it and see what happens?
As an example of the case that comes to mind, see attached. It is a message
sent to v6ops(_at_)ietf(_dot_)org yesterday. The sender signed it using DKIM,
the IETF changed the message (added some trailing text) before forwarding it,
the receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and
failed.
It seems to me that we should not approve a procedure that has that effect, at
least without some guidance for mail relay administrators. I could imagine two
forms of guidance: “obey the end-to-end principle; don’t change the message the
originator sent”, or “if you change a signed message, first validate the
message you received and discard if that fails, change it, and then sign it
yourself, so that a receiver can see who changed it and validate the outcome”.
Could we actually try such guidance in a sandbox, and document appropriate
procedures for mailing lists?
--- Begin Message ---
fec0::/10 was reserved way back in rfc 1884
3879 and 4193 are contemporaneous activities. meany people on this list
were present for them.
The fact that we did a bad job at something 20 years ago doesn't mean
the problem that we were attempting to address went away.
I agree… People wanting to do NAT rather than learn how to do things better
without it is an education problem which continues to persist to this day.
Owen
--- End Message ---
signature.asc
Description: Message signed with OpenPGP using GPGMail