+1 to Scott's comment (killing l= in the simplest possible way).
I don't think that change necessarily will drive senders to change their
implementations (as we're already seeing some stop using l= already), but I
think it makes sense to have the RFC take a stronger stance and outright
remove supp
Murray beat me to this... I think that the purpose of being able to
reconstruct and verify messages before modification is to give us the
option to be more nuanced than attributing badness to both the original and
modifying entity.
This is probably a feature some systems choose to not use, since k
+1 to not constraining the workgroup too much at this point. I think there
are many details that need to be discussed before we know what is the best
option.
I'm not opposed to making some o the tweaks Dave suggested to more
accurately describe the problem and the goal as long as we focus on what w
I agree with Bron. The carbon footprint discussion distracts away from what
I think is the main purpose with a set of defined headers that have to be
signed: Making sure senders don't forget to sign them.
Personally I don't have a strong opinion if those headers are explicit or
implicit. The key po
r 14, 2025 at 9:32 AM Dave Crocker wrote:
> On 4/14/2025 5:10 PM, Emil Gustafsson wrote:
>
> rom what I think is the main purpose with a set of defined headers that
> have to be signed: Making sure senders don't forget to sign them.
>
>
> Forget? As if a normative
