-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>on interoperability, you raise a valid point.
my point (just so everyone keeps up with the conversation) being that it
will not work !
>For hh= to be verifiable
>across hops, the exclusion list must converge to a fixed set - identical
>at every hop -.
whatever "converge" means .. yes every hop must use the same list (so
one might as well write that list down in the spec)
>The current implementation uses a configurable list
>precisely to gather operational data on which prefixes need exclusion in
>practice.
what implementation is this ? can we try interworking with it ?
>The goal is to derive a normative fixed list from deployment
>experience, not to leave it as a per-operator choice. The alternative
>(excluding all X-* by default) leaves the injection surface open for all
>of them.
you need to show that this matters ...
>On who relies on X-* headers from non-adjacent hops, spam campaigns
>routinely inject forged X-Spam-Status and X-Spam-Score headers to
>influence downstream filtering.
as it happens I have 30642 spam messages sent to my account in the past
3 years sitting in a directory (I have hand filtered out the phish and
the fraud leaving just run of the mill spam) ....
18 of these contain X-Spam-Status
17 of these contain X-Spam-Score
Given the small numbers I did not bother to assess whether these header
fields were genuine or had been added to fool me (not)!
Now everyone's spam differs ... but this does not look like "routinely"
to me
I also have access to a feed of email provided to the Cambridge
Cybercrime Centre by those nice people at Abusix. This is quite a
substantial mail flow and is believed (because of the way that it is
curated) to be 99.99... percent spam
So I am processing the data for last Wednesday (which might well be a
typical day) which is about 13m records ... this will takes a while (the
server is quite busy -- I often note that just getting the data written
to disk in realtime is challenge). I will follow up when I have the
numbers from there and we'll see what "routinely" might mean in 2026.
>Most well-configured systems strip or
>ignore them, but the attack surface exists precisely because these
>headers are unsigned and unattributed. The question is whether the
>protocol should leave that surface open by design.
it leads to considerable simplification and no-one (including now you)
has produced any evidence it will cause an issue
>Google Groups already signs X-Original-Sender and
>X-Original-Authentication-Results in its DKIM-Signature h= tag, as a
>selective inclusion of security-relevant X-* headers that is
>operationally identical to the approach proposed here.
Google groups mainly sends me spam ... but anyway, in DKIM2 you will be
able to determine the information that these fields provide (I assume,
since I predict there is no actual published documentation) by
inspecting the DKIM2 header fields preceding the one added (in the
fullness of time) by Google Groups.
- --
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/AwUBahyjFmHfC/FfW545EQIgagCeNZr4HcVt3111d+VBu91fzfbzLTkAn0Fg
LOPKatuYpN8f+iS5zqkOQW5F
=DBUU
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
