-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Pete
Resnick <[email protected]> writes
> Let's call the downside "the Yahoo problem" (sorry Richard). Back
> when Yahoo implemented p=reject, it wasn't because they really
> wanted to disallow people posting to non-modifying mailing lists or
> going through alumni forwarders. It was because p=reject seemed
> like the "most secure".
Yahoo wanted to prevent customers believing their friends had been
hacked and were sending them bad email. p=reject achieved that.
>And everybody else followed suit
Not everybody else (and some large senders have spent forever saying
they will do it RSN and continue to make forward looking predictions) ..
I still see lots of forged email that doesn't come from where it claims
to do so --- including a great deal from myself at highwayman.com,
claiming that they have videos of me visiting adult websites...
> Two things on this: 1) It seems highly likely that (even if it's
> easy) receivers will not update their code to do fromUnmunging
> because doing that requires them to also evaluate the message and
> see whether it really is worthy of being unmunged, something that
> you've already claimed is unpredictable, chaotic, and leaves
> unexpected sharp edges. I don't think it is as bad as you say it
> is, but I think receivers are likely to come to the same conclusion
> that you did and refuse to unmunge. 2) Unmunging is a good bit of
> work.
in DKIM2 that is not the case ... the data needed is lying around as a
result of having determined that one has a Fully Verified DKIM2 Message
so not much work at all (even if Claude takes the day off)
> I think we can come up with a much simpler set of principles
> for an anti-spam mechanism to use along the lines of "bounce
> anything more than minimal additions to bodies and prefixes to
> Subjects" that are easier to implement and maintain the
> functionality that is desirable.
It is suggested that a way forward, to address the DKIM1 fragility
property that some seem to value is to make it a MUST that ANY body
modification MUST be accompanied by a change to the From header field
i.e. the same Message-Instance header field with a body recipe MUST have
a header recipe for From: (making it the same M-I is to avoid a lot of
extra complexity cross-checking DKIM2-Signature m= values)
Since From header fields MUST be authentic this means that anyone
changing the body (and wishing to preserve an existing DKIM2 chain) has
to produce a From header field and in order to sign that it MUST have
their domain present in it.
Essentially we make From-munging compulsory if you change the body.
The argument runs that this will play better with naive MUAs that
display what has arrived and that if they want a better user experience
they will put some effort into improving how they select the email
address when someone presses the <REPLY> button (rather like they are
meant to go and look at List-* headers already)
MUAs that want to put more engineering effort in will display what has
been changed in the message (and From header field) .. Bron has a nice
demo of a first cut at a UI for this which he will demo next Tuesday
Note that if you do NOT change the body then you do NOT have to munge
(so a mailing list that just modifies the Subject header field will be
fine).
At $DAYJOB$ all our automatic forwarding and manual forwarding (what
some people call bounces (from bounding onwards) to confuse (since these
are not DSNs)) does not change the body, so we are sanguine about this
proposal.
> *• There is a desire to maintain validation of a message's signing
> identifier across common transit and forwarding modifications.
> When a message goes through a re-posting, such as through a
> mailing list, the validation signature typically does not survive
> and cannot be recovered. Fixing this would permit a more robust
> evaluation of the message.
I think we still meet this ... essentially we have designed an easy to
implement "de-munge" and it is (to a large extent) consistent with
having something that is similar to the DKIM1 fragile-signature model.
> You could make the argument that signing the munged From addresses
> that bullet, but I would say that some folks would find that a
> "surprising" outcome and not really in the spirit of what that
> bullet intended to accomplish.
We are paying attention to what the WG asks for. Now if no-one else
wants to keep the fragile semantics of DKIM1 then we can go back to
where spec-09 has left us.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBavYnBGHfC/FfW545EQJN1QCg3GIy8cWGMxV/oz9hWA4W4xr24hIAmgNj
TllfXmOlvvqdnaIYRfl/ZRGw
=4tLW
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
