Hello.
Bron Gondwana wrote in
<8361f17f-aaf0-4f8e-a1c0-2ec99911b...@app.fastmail.com>:
|On Tue, Nov 19, 2024, at 12:14, Steffen Nurpmeso wrote:
|> I wondered for myself how the bsdiff algorithm would work out for
|> such things.
|
|This is basically the bsdiff algorithm, but with the syntax converted \
|to be something human readable and header safe.
Thank. Ok, in this case as you show looks very impressive. The
algorithm "does not need to patch" several, as you say. Also your
message in my inbox and what came over IETF would be addressable
like so.
But, this is my data point here, it will not work out without full
diffs in many other cases. For example i responded to Richard
Clayton's message
jszrijbynuonf...@highwayman.com
https://mailarchive.ietf.org/arch/msg/ietf-dkim/1ZCF-h9rHsL2YT3lTgo_qmIpVGE
which seems 7-bit plain (one had to ask him how he sent it) with
20241117030640.wk6r9c7R@steffen%sdaoden.eu
https://mailarchive.ietf.org/arch/msg/ietf-dkim/k4wUEwxJLI_AIU-Q9TXBBhI0gPU
that goes out without MIME as such (text/plain 7-bit content-type
is optional), but both of these two messages came in via ML as
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
And here the complete text need to be replaced. This is t2*.txt.
And *if* (just thinking) that is only a forwarder address like the
@FreeBSD.org one of Colin Percival, of CPAN, sourceforge or such
kind of, then *possibly* (but likely not) once again.
Things are better (for me as a German who effectively writes
mostly 7-bit ASCII) for the mentioned OpenGroup server, where you
sent eg text/plain; charset="utf-8"/quoted-printable (because of
a MIME-folded long line, and a German name with Umlauts etc) and
only get the 8-bit conversion.
One more question: how about a language which practically always
needs UTF-8 with more than one byte per character, ie, an Asian
language, and such? For anyone not going the 8-bit way (like
myself) this is thus either quoted-printable or base64 right away.
Then reencodings to 8-bit are more expensive.
Well i do not know, it would have to be tested on real life data;
of course one could hope for the future, if it is all 8-bit and
if ML software and such stops this reencoding "madness", then..
And, of course, all this pretty much only affects the text parts,
large images and such are base64 data and (pretty much) constant.
My examples from above, if i pass only the bodies (i will attach
them) to bsdiff i get
-rw-r----- 1 steffen wheel 2167 Nov 19 21:22 t1-i.txt
-rw-r----- 1 steffen wheel 2201 Nov 19 21:22 t1-o.txt
-rw------- 1 steffen wheel 236 Nov 19 21:22 t1-patch
-rw-r----- 1 steffen wheel 8412 Nov 19 21:22 t2-i.txt
-rw-r----- 1 steffen wheel 5932 Nov 19 21:22 t2-o.txt
-rw------- 1 steffen wheel 4350 Nov 19 21:23 t2-patch
Hm. Ok let me remove the bzip2 stuff from bsdiff.. Here is the
same without, and then running plzip and zstd on the uncompressed
binary data; this still has the normal header and such (note
i have not yet looked at all, it may very well be that patches at
position 0 or "EOT" could be optimized away etc etc.
plzip -9 and zstd -19
-rw------- 1 steffen wheel 142 Nov 19 21:48 t1-patch-2.lz
-rw------- 1 steffen wheel 116 Nov 19 21:48 t1-patch-2.zst
-rw------- 1 steffen wheel 4654 Nov 19 21:48 t2-patch-2.lz
-rw------- 1 steffen wheel 4577 Nov 19 21:48 t2-patch-2.zst
It would be interesting to know how your implementation of the
algorithm works out for those (and the "real" vcsdiff
implementation i have seen is huge). Would be cool if it is
superior, of course.
You know, .. the "DKIM now horny" draft i will write anyway
(because why not, it only extends DKIM/6376) will include diffing,
it will state that normalized headers shall come first, followed
by normalized body, all this to be diffed and optionally
compressed (but decompressing MUST be supported; just today
Antonio Diaz Diaz posted "Lunzip 1.15-rc1 released", very small
decompressor only).
Then, if additional headers are to be included these have to be
prepended, like trace headers for an email; maybe that special
case can be optimized away very easily (from bsdiff .. for now).
Regarding licenses these are BSD 2-clause, MIT, and i think lzip
is available as public domain (despite the IETF draft variant).
The nice thing about all that long time matured software is that
it is very small, statically linking them all in is no problem; on
FreeBSD:
-rw------- 1 steffen wheel 19992 Nov 19 21:58 bsdiff.o
-rw------- 1 steffen wheel 14904 Nov 19 21:58 divsufsort.o
-rw------- 1 steffen wheel 43928 Nov 19 21:58 sssort.o
-rw------- 1 steffen wheel 32848 Nov 19 21:58 trsort.o
-rw------- 1 steffen wheel 19000 Nov 19 21:58 utils.o
#|f-1400:/tmp/z$ ll bsdiff
-rwx------ 1 steffen wheel 49200 Nov 19 21:58 bsdiff*
#|f-1400:/tmp/z$ strip bsdiff
#|f-1400:/tmp/z$ ll bsdiff
-rwx------ 1 steffen wheel 46200 Nov 19 21:58 bsdiff*
and on Linux:
-rwxr-x--- 1 steffen steffen 105696 Nov 19 22:01 minilzip*
This is en- plus decoding, statically linked (lzlib).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
Hello!
Joshua M. Clulow wrote in
<CAEwA5n+LAJU5pKB==vodiApr4DLV+t3s2D=w=h8_16za3d_...@mail.gmail.com>:
|On Wed, 30 Oct 2024 at 16:20, Steffen Nurpmeso via austin-group-l at
|The Open Group <austin-grou...@opengroup.org> wrote:
|> elif command -v kstat >/dev/null 2>&1; then
|> i=$(PERL5OPT= kstat -p cpu | awk '
|> BEGIN{no=0; FS=":"}
|> {if($2 > no) max = $2; next}
|> END{print ++max}
|> ')
|> [ $? -eq 0 ] && NPROC=$i
|> fi
|> export NPROC
|
|FWIW, you can just use "psrinfo -t" (for "totals") if you want the
|online CPU count, at least on illumos systems:
|
| $ uname -a
| SunOS vulcan 5.11 helios-2.0.22694 i86pc i386 i86pc
|
| $ PERL5OPT= kstat -p cpu | awk 'BEGIN { no = 0; FS = ":"; }
| { if ($2 > no) max = $2; next; }
| END{ print ++max; }'
| 48
|
| $ psrinfo -t
| 48
Thank you. This does not seem to be portable to elder machines
of the OpenCSW cluster to which i thankfully have access to,
whereas the older thing -- Jörg Schilling gave me this hint in the
past, you know -- works also there:
#?0|kent:steffen$ ssh sdao...@login.opencsw.org
...
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
...
#?255|login:sdaoden$ ssh unstable9s
Last login: Mon Sep 23 21:50:30 2024 from login.bo.opencs
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
..
#?0|unstable9s:sdaoden$ psrinfo -t
/.SUNWnative/usr/sbin/psrinfo: illegal option -- t
usage:
psrinfo [-v] [-p] [processor_id ...]
psrinfo -s [-p] processor_id
#?2|unstable9s:sdaoden$ echo $NPROC
32
But thanks, i think i could test this inside () and check $?, it
likely is still better than running a complete perl session.
Will do.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
Hello!
Joshua M. Clulow wrote in
<CAEwA5n+LAJU5pKB=3D=3DvodiApr4DLV+t3s2D=3Dw=3dh8_16za3d_...@mail.gmail.co=
m>:
|On Wed, 30 Oct 2024 at 16:20, Steffen Nurpmeso via austin-group-l at
|The Open Group <austin-grou...@opengroup.org> wrote:
|> elif command -v kstat >/dev/null 2>&1; then
|> i=3D$(PERL5OPT=3D kstat -p cpu | awk '
|> BEGIN{no=3D0; FS=3D":"}
|> {if($2 > no) max =3D $2; next}
|> END{print ++max}
|> ')
|> [ $? -eq 0 ] && NPROC=3D$i
|> fi
|> export NPROC
|
|FWIW, you can just use "psrinfo -t" (for "totals") if you want the
|online CPU count, at least on illumos systems:
|
| $ uname -a
| SunOS vulcan 5.11 helios-2.0.22694 i86pc i386 i86pc
|
| $ PERL5OPT=3D kstat -p cpu | awk 'BEGIN { no =3D 0; FS =3D ":"; }
| { if ($2 > no) max =3D $2; next; }
| END{ print ++max; }'
| 48
|
| $ psrinfo -t
| 48
Thank you. This does not seem to be portable to elder machines
of the OpenCSW cluster to which i thankfully have access to,
whereas the older thing -- J=C3=B6rg Schilling gave me this hint in the
past, you know -- works also there:
#?0|kent:steffen$ ssh sdao...@login.opencsw.org
...
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
...
#?255|login:sdaoden$ ssh unstable9s
Last login: Mon Sep 23 21:50:30 2024 from login.bo.opencs
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
..
#?0|unstable9s:sdaoden$ psrinfo -t
/.SUNWnative/usr/sbin/psrinfo: illegal option -- t
usage:
psrinfo [-v] [-p] [processor_id ...]
psrinfo -s [-p] processor_id
#?2|unstable9s:sdaoden$ echo $NPROC
32
But thanks, i think i could test this inside () and check $?, it
likely is still better than running a complete perl session.
Will do.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
UmljaGFyZCBDbGF5dG9uIHdyb3RlIGluDQogPEpTWlJpSkJ5blVPbkZBR2hAaGlnaHdheW1hbi5j
b20+Og0KIHwtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQogfEhhc2g6IFNIQTEN
CiB8DQogfEluIG1lc3NhZ2UgPDIwMjQxMTE2MjA0OTM1LmRDYjBtUWNHQHN0ZWZmZW4lc2Rhb2Rl
bi5ldT4sIFN0ZWZmZW4NCiB8TnVycG1lc28gPHN0ZWZmZW5Ac2Rhb2Rlbi5ldT4gd3JpdGVzDQog
fA0KIHw+SGF2aW5nIHNhaWQgdGhhdCwgaWYgaXQgaXMgcmVhbGx5IGFjY2VwdGFibGUgdG8gaW5j
bHVkZSB0aGUgZW50aXJlDQogfD5oaXN0b3J5IG9mIGNoYW5nZXMgaW4gdGhhdCAic3RhY2siIHRo
YXQgZW1haWwgaGVhZGVycyBmb3JtIChoaWhpOg0KIHw+eWVzIHBsZWFzZSwgaSBmaW5kIGl0IGFi
c3VyZCB0aGF0IHRoZXNlIHRoaW5ncyBoYXZlIHRvIGJlIG51bWJlcmVkDQogfD5naXZlbiB0aGlz
IGlzIGEgc3RhY2s7DQogfA0KIHx0aGVyZSBpcyBhIGJlbGllZiAocGVyaGFwcyBub3Qgd2VsbC1m
b3VuZGVkKSB0aGF0IHRoZXJlIGFyZSBzeXN0ZW1zIG91dA0KIHx0aGVyZSB0aGF0IHJlb3JkZXIg
aGVhZGVycy5bLl0NCg0KVGhhdCBpcyBhIGdvb2QgcXVlc3Rpb24uICBIYXMgdGhpcyBldmVyIGJl
ZW4gdHJ1bHkgdmVyaWZpZWQNCmkgdGhpbmsgYWxtb3N0IHR3ZW50eSB5ZWFycyBhZ28gd2hlbiBE
S0lNIHdhcyAvIHByZWRlY2Vzc29ycyB3ZXJlDQppbnZlbnRlZCwgYW5kICpleHBsaWNpdGx5KiBk
b2N1bWVudGVkIGFzDQoNCiAgIFRoZSBES0lNLVNpZ25hdHVyZSBoZWFkZXIgZmllbGQgU0hPVUxE
IGJlIHRyZWF0ZWQgYXMgdGhvdWdoIGl0IHdlcmUgYQ0KICAgdHJhY2UgaGVhZGVyIGZpZWxkIGFz
IGRlZmluZWQgaW4gU2VjdGlvbiAzLjYgb2YgW1JGQzUzMjJdIGFuZCBoZW5jZQ0KICAgU0hPVUxE
IE5PVCBiZSByZW9yZGVyZWQgYW5kIFNIT1VMRCBiZSBwcmVwZW5kZWQgdG8gdGhlIG1lc3NhZ2Uu
DQoNCndoZW4gc3RhbmRhcmRhcmRpemVkLCBhbmQgd2hlcmUgdGhlIHJlZmVyZW5jZWQgUkZDIHNh
eXMgZWcNCg0KICAgV2hlbiB0aGUgU01UUCBzZXJ2ZXIgYWNjZXB0cyBhIG1lc3NhZ2UgZWl0aGVy
IGZvciByZWxheWluZyBvciBmb3INCiAgIGZpbmFsIGRlbGl2ZXJ5LCBpdCBpbnNlcnRzIGEgdHJh
Y2UgcmVjb3JkIChhbHNvIHJlZmVycmVkIHRvDQogICBpbnRlcmNoYW5nZWFibHkgYXMgYSAidGlt
ZSBzdGFtcCBsaW5lIiBvciAiUmVjZWl2ZWQiIGxpbmUpIGF0IHRoZSB0b3ANCiAgIG9mIHRoZSBt
YWlsIGRhdGEuDQoNCmFuZCBpbiAiNC40IFRyYWNlIEluZm9ybWF0aW9uIg0KDQogICBBbiBJbnRl
cm5ldCBtYWlsIHByb2dyYW0gTVVTVCBOT1QgY2hhbmdlIG9yIGRlbGV0ZSBhIFJlY2VpdmVkOiBs
aW5lDQogICB0aGF0IHdhcyBwcmV2aW91c2x5IGFkZGVkIHRvIHRoZSBtZXNzYWdlIGhlYWRlciBz
ZWN0aW9uLiAgU01UUA0KICAgc2VydmVycyBNVVNUIHByZXBlbmQgUmVjZWl2ZWQgbGluZXMgdG8g
bWVzc2FnZXM7IHRoZXkgTVVTVCBOT1QgY2hhbmdlDQogICB0aGUgb3JkZXIgb2YgZXhpc3Rpbmcg
bGluZXMgb3IgaW5zZXJ0IFJlY2VpdmVkIGxpbmVzIGluIGFueSBvdGhlcg0KICAgbG9jYXRpb24u
DQoNCmFuZCA1MzIxYmlzIGRpc2N1c3Npb24gdG91Y2hlZCB0aGlzIHRvcGljIGlmIGkgcmVjYWxs
IGNvcnJlY3RseS4NCg0KQW55aG93IGl0IGlzIHBsYWluIHRoYXQgUkZDIDUzMjEgc29mdHdhcmUg
a25vd3MgYWJvdXQgdGhlIG5vdGlvbg0KYW5kIHRoZSBwcmVzc2luZyBuZWVkIHRvIHRyZWF0IGEg
bWVzc2FnZSBhcyAiYSBzdGFjayIuDQpUaGlzIGlzIHRydWUgc2luY2UgUkZDIDgyMiBmcm9tIDE5
ODIsIHdoZXJlIG9uZSBjYW4gcmVhZA0KDQogICAgIDQuMy4gIFRSQUNFIEZJRUxEUw0KDQogICAg
ICAgICAgVHJhY2UgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBwcm92aWRlIGFuIGF1ZGl0IHRyYWls
IG9mICBtZXMtDQogICAgIHNhZ2UgIGhhbmRsaW5nLiAgIEluICBhZGRpdGlvbiwgIGl0IGluZGlj
YXRlcyBhIHJvdXRlIGJhY2sgdG8gdGhlDQogICAgIHNlbmRlciBvZiB0aGUgbWVzc2FnZS4NCg0K
IkFuIGF1ZGl0IHRyYWlsIiBtZWFucyB0cmFjZSBoZWFkZXJzIGZvcm0gYSBzZXF1ZW50aWFsIHdl
bGwNCnNlcXVlbmNlIC0tIHBsZWFzZSBsZXQgbWUgQ2M6IGVtYWlsY29yZUAgYXMgdGhlIG5ldyB3
b3JkaW5nIGlzIGluDQpteSBvcGluaW9uIGJ5IGZhciB3b3JzZSB0aGFuIHdoYXQgUkZDIDgyMiBz
YXlzLCBpbmRlZWQuDQpCdXQgbm93IHRoZSBmdW4gb2YgaXQ6IGl0IHNlZW1zIGFjY29yZGluZyBJ
RVRGIG1ldGhvZG9sb2d5IFJGQyA4MjINCmlzIGFjdHVhbGx5ICp0aGUqIHN0YW5kYXJkIHRoYXQg
Y291bnRzLCBhdCBsZWFzdCB1bnRpbCBSRkMgNTMyMWJpcw0KaXMgcmVsZWFzZWQsICppZiogaSBn
b3QgdGhhdC4gIElmIHRoYXQgaXNuJ3QgZnVubnksIHlvdSBrbm93Lg0KDQpJZiBpIGFkZCB0aGVz
ZSB0aGluZ3MgdG9nZXRoZXIgaSBzZWUgREtJTSBzaWduYXR1cmVzIGFzIHBhcnQgb2YNCmEgc3Rh
Y2suICBTdXJlLCB0aGlzIGlzIFNIT1VMRCBub3QgTVVTVCwgYW5kIHRoZSBuZXdlciBTTVRQIFJG
Q3MNCmRpbHV0ZSAoc29ycnksIGRlYXIgSm9obiEpIHRoZSBub3Rpb24gb25lIGNhbiBnZXQsIGkg
cmVhbGx5DQpwZXJjZWl2ZSBSRkMgODIyIHNvIHRoYXQgaSB0aGluayBEb3VnbGFzIE1jSWxyb3kg
Y291bGQgYmFzayBpbg0KdGhpcyBjb25jaXNlIHRleHQuDQooTm8gbW9yZSBTTVRQIGJlbG93IHRo
aXMgcG9pbnQuKQ0KDQpCdXQsIHJlYWxseSwgZXZlciBzaW5jZSBpIGxvb2sgaSBoYXZlIHlldCB0
byBzZWUgdGhhdCByZW9yZGVyaW5nDQpvZiBES0lNIHNpZ25hdHVyZXMgdG9vayBwbGFjZS4gIE9o
LCByZW9yZGVyaW5nIGhhcHBlbnMgc3VwZXINCmZyZXF1ZW50bHkgZm9yIGFsbCBhZGRyZXNzIGZp
ZWxkcyAoaW5jbHVkaW5nIHNlbmRlciwgcmVwbHktdG8NCmV0YyksIHN1YmplY3RzLCBkYXRlLCBh
bmQgaW4gZ2VuZXJhbCBhbGwgdGhvc2UgZmllbGRzIHRoYXQgY2FuIGJlDQpzZWVuIGluIE1VQXMg
YW5kIG1haWxpbmctbGlzdHMsIGFzIHdlbGwgYXMgc3BhbSBldGMgbWlsdGVycywNCnByZXBlbmRl
ZCwgYXBwZW5kZWQsIHNjcmFtYmxlZCBldmVuLCBhbmQgdGhlIGVtbG0gbWFpbGluZy1saXN0DQpt
YW5hZ2VyIGlzIGxpa2VseSBhbG9uZSBpbiBpdHMgcXVlc3QgdG8gcHJlcGVuZCB0aGUgTGlzdC0g
aGVhZGVycywNCndoZXJlYXMgYWxsIG90aGVycyAiYXBwZW5kIiAob3IgYmV0dGVyLCBpbnNlcnQg
c29tZXdoZXJlIGF0IHRoZQ0KdGFpbCwgbWxtbWogIm1vcmUgaGVhdmlseSIgc28gdGhhbiBtYWls
bWFuKS4gIFRoYXQgaXMsIGFsbCBvdmVyDQp0aGUgcGxhY2UuICBCdXQgaXQgc2VlbXMgREtJTS1T
aWduYXR1cmUgYW5kIEF1dGhlbnRpY2F0aW9uLVJlc3VsdHMNCmlzIG5vdCBhbG9uZyB0aG9zZS4N
Cg0KSSBzYXkgdGh1cywgbGV0IGl0IGhhcHBlbi4gIE1ha2UgaXQgYSBNVVNULiAgSXQgaXMgYSB0
cmFjZSBoZWFkZXIuDQpBbGwgcmVsZXZhbnQgcGVyc29ucyBsaXN0ZW4gaGVyZSAob24gZW1haWxj
b3JlKS4gIEFueSBNVEENCmRldmVsb3BlciBvciBnaWFudCBhcHBvaW50ZWQgc3BlY2lhbGlzdCB3
aG9zZSBzb2Z0d2FyZSBkb2VzIG5vdA0KY29tcGx5IGNvdWxkIHNwZWFrIG91dC4gIFRoZXkgbGlz
dGVuLCB0aGV5IHRoZW4gKGFzIGFwcG9pbnRlZA0Kc3BlY2lhbGlzdHMpIGV2ZW4ga25vdyBSRkMg
ODIyIGlzIHRoZSAicmVhbCB0aGluZyIsIGhlbmNlIGl0IGlzDQpjcnlzdGFsIGNsZWFyIHRoYXQg
dHJhY2UgaXMgYW4gYXVkaXQgdHJhaWwgYW5kIHRodXMgc2VxdWVudGlhbC4NCihJdCBpcyBub3Qg
YXMgaWYgYW55b25lIGNhcmVzIGZvciB0aGlzIC0tIGhvdyBtdWNoIGlzIGl0LA0KMSBwZXJjZW50
IG9yIGxlc3M/IC0tIHRpbnkgY29ybmVyIG9mIHRoZSBpbnRlcm5ldCB0aGF0IGlzIG5vdA0KY292
ZXJlZCBieSB0aGUgZ2lhbnRzIChhbmQvb3IgdGhlaXIgc29mdHdhcmUpLCBieSBwb3N0Zml4LCBl
eGltLA0KcW1haWwsIG9wZW5zbXRwZCAoYW5kIGFsbCB0aG9zZSBjb21wbHkpLCBhbnlob3cuDQoN
CldoYXQgYmVsaWVmIGlzIHRoaXMgeW91IGFyZSB0YWxraW5nIGFib3V0Pw0KKChJdCBpcyBvdmVy
ZW5naW5lZXJpbmcuKSkNCg0KIHxbLl1OdW1iZXJpbmcgbWVhbnMgdGhhdCB0aGVzZSBjYW4gYmUg
dG9sZXJhdGVkDQogfHRoZSBhY3R1YWwgY29zdCBvZiBudW1iZXJpbmcgaXMgdmVyeSBsb3csIGFu
ZCBpdCBwcm92aWRlcyBzaWduaWZpY2FudA0KIHxjbGFyaXR5IGFuZCByZWFzc3VyYW5jZSAtLSBz
byBJIGRvbid0IGtub3cgd2h5IHlvdSBhcmUgYXJndWluZyBpdCBzaG91bGQNCiB8bm90IGJlIHBy
ZXNlbnQgaW4gdGhlIGRlc2lnbiAtLSBhbmQgSSBhbSBldmVuIGxlc3MgY2xlYXIgd2hhdCBpdCBo
YXMgdG8NCiB8ZG8gd2l0aCB0aGUgcHJvcG9zZWQgY2hhcnRlciBmb3IgYSBXb3JraW5nIEdyb3Vw
DQoNCkFoLiAgTWV0aG9kb2xvZ3kuDQoNCiB8LSAtLSANCiB8cmljaGFyZCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJpY2hhcmQgQ2xheXRvbg0KIHwN
CiB8VGhvc2Ugd2hvIHdvdWxkIGdpdmUgdXAgZXNzZW50aWFsIExpYmVydHksIHRvIHB1cmNoYXNl
IGEgbGl0dGxlIHRlbXBvcmFyeSANCiB8U2FmZXR5LCBkZXNlcnZlIG5laXRoZXIgTGliZXJ0eSBu
b3IgU2FmZXR5LiBCZW5qYW1pbiBGcmFua2xpbiAxMSBOb3YgMTc1NQ0KDQpPZmYtdG9waWMsIGJ1
dCB3aGF0IGlzICJsaWJlcnR5Ij8gIFVuZGVyLWVkdWNhdGVkIHVuZGVyLWluZm9ybWVkDQp1bmRl
ci1hd2FyZSAoYW5kIGhvdyBkaWQgdGhleSBnZXQgKnRoZXJlKj8pIHBlb3BsZSBtYWtpbmcgZ3Jl
ZWR5DQpkZWNpc2lvbnMuICBPdmVyIDc2IHBlcmNlbnQgbG9zcyBvZiBsaWZlIChkaXZlcnNpdHkp
IHNpbmNlIDE5NzAsDQp0aGUgQ2x1YiBvZiBSb21lICJ0aGUgbGltaXRzIHRvIGdyb3d0aCIgcmVw
b3J0IG9mIDE5NzIgaXQgaXMgd2UNCmNvbXBseSB0byBjb21wbGV0ZWx5IC0tIHNvIG11Y2ggdG8g
ImNsYXJpdHkgYW5kIHJlYXNzdXJhbmNlIiwNCmhhaCEuICBJIGhhdmUgYSB0ZWNobm8gc29uZyBh
cyBwYXJ0IG9mIGEgc2V0IG9mIGEgd29yZHdpZGUga25vd24NCkRKIGZyb20gYXJvdW5kIFkySyB0
aGF0IGkgdHJ1bHkgY291bGQgZmluZCwgaXQgc2F5cyAiRnJlZWRvbSBpcw0KcmVsZXZhbnQuIFNl
bGYtZGV0ZXJtaW5hdGlvbiBpcyByZWxldmFudC4gWW91IG11c3QgY29tcGx5Ii4gIEFuZA0Kc29y
cnksIHRoZSB3aGl0ZSBtYW4gaGFzIHNpbXBseSBmYWlsZWQuICBIZSBuZXZlciBlbWJyYWNlZCB0
aGUNCnByb2JsZW0gYW5kIHBhdmVkIGEgd2F5IGZvciAidGhlIHdob2xlIHRoaW5nIi4gIEFuZCBu
ZXZlcg0Kd2lsbC4gT3RoZXIgY2l2aWxpemF0aW9ucyBhbmQgcGhpbG9zb3BoaWVzIGRpZCAoYXQg
bGVhc3QgKnRoaW5rKikNCnNvIGJlZm9yZSBvdXJzIGV4aXN0ZWQuDQoNCiB8LS0tLS1CRUdJTiBQ
R1AgU0lHTkFUVVJFLS0tLS0NCiB8VmVyc2lvbjogUEdQc2RrIHZlcnNpb24gMS43LjENCiB8DQog
fGlRQS9Bd1VCWnpsSjh0Mm5RUUhGeEVWaUVRTEpTUUNnOVdZUG92YXV2Y2FaWmRkS3EzOVMwSkRD
OXBJQW5qcG0NCiB8eDl3OG9BenZXd1NiNGJOWVV5OE5lRDd0DQogfD0rTXVrDQogfC0tLS0tRU5E
IFBHUCBTSUdOQVRVUkUtLS0tLQ0KIC0tRW5kIG9mIDxKU1pSaUpCeW5VT25GQUdoQGhpZ2h3YXlt
YW4uY29tPg0KDQotLXN0ZWZmZW4NCnwNCnxEZXIgS3JhZ2VuYmFlciwgICAgICAgICAgICAgICAg
VGhlIG1vb24gYmVhciwNCnxkZXIgaG9sdCBzaWNoIG11bnRlciAgICAgICAgICAgaGUgY2hlZXJm
dWxseSBhbmQgb25lIGJ5IG9uZQ0KfGVpbmVuIG5hY2ggZGVtIGFuZGVyZW4gcnVudGVyICB3YS5r
cyBoaW1zZWxmIG9mZg0KfChCeSBSb2JlcnQgR2VybmhhcmR0KQ0KfA0KfEFuZCBpbiBGYWxsLCBm
ZWVsICJUaGUgRHJvcGJlYXIgQmFyZCJzIGJhbGwocykuDQp8DQp8VGhlIGJhbmRlZCBiZWFyDQp8
d2l0aG91dCBhIGNhcmUsDQp8QmFuZ2VkIG9uIGhpbXNlbGYgZm9yZSdlciBhbmQgZSdlcg0KfA0K
fEZhcmV3ZWxsLCBkZWFyIGNvbGxhciBiZWFyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCklldGYtZGtpbSBtYWlsaW5nIGxpc3QgLS0gaWV0Zi1ka2lt
QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8gaWV0Zi1ka2ltLWxlYXZl
QGlldGYub3JnCg==
Richard Clayton wrote in
<jszrijbynuonf...@highwayman.com>:
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|In message <20241116204935.dCb0mQcG@steffen%sdaoden.eu>, Steffen
|Nurpmeso <stef...@sdaoden.eu> writes
|
|>Having said that, if it is really acceptable to include the entire
|>history of changes in that "stack" that email headers form (hihi:
|>yes please, i find it absurd that these things have to be numbered
|>given this is a stack;
|
|there is a belief (perhaps not well-founded) that there are systems out
|there that reorder headers.[.]
That is a good question. Has this ever been truly verified
i think almost twenty years ago when DKIM was / predecessors were
invented, and *explicitly* documented as
The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC5322] and hence
SHOULD NOT be reordered and SHOULD be prepended to the message.
when standardardized, and where the referenced RFC says eg
When the SMTP server accepts a message either for relaying or for
final delivery, it inserts a trace record (also referred to
interchangeably as a "time stamp line" or "Received" line) at the top
of the mail data.
and in "4.4 Trace Information"
An Internet mail program MUST NOT change or delete a Received: line
that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change
the order of existing lines or insert Received lines in any other
location.
and 5321bis discussion touched this topic if i recall correctly.
Anyhow it is plain that RFC 5321 software knows about the notion
and the pressing need to treat a message as "a stack".
This is true since RFC 822 from 1982, where one can read
4.3. TRACE FIELDS
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
"An audit trail" means trace headers form a sequential well
sequence -- please let me Cc: emailcore@ as the new wording is in
my opinion by far worse than what RFC 822 says, indeed.
But now the fun of it: it seems according IETF methodology RFC 822
is actually *the* standard that counts, at least until RFC 5321bis
is released, *if* i got that. If that isn't funny, you know.
If i add these things together i see DKIM signatures as part of
a stack. Sure, this is SHOULD not MUST, and the newer SMTP RFCs
dilute (sorry, dear John!) the notion one can get, i really
perceive RFC 822 so that i think Douglas McIlroy could bask in
this concise text.
(No more SMTP below this point.)
But, really, ever since i look i have yet to see that reordering
of DKIM signatures took place. Oh, reordering happens super
frequently for all address fields (including sender, reply-to
etc), subjects, date, and in general all those fields that can be
seen in MUAs and mailing-lists, as well as spam etc milters,
prepended, appended, scrambled even, and the emlm mailing-list
manager is likely alone in its quest to prepend the List- headers,
whereas all others "append" (or better, insert somewhere at the
tail, mlmmj "more heavily" so than mailman). That is, all over
the place. But it seems DKIM-Signature and Authentication-Results
is not along those.
I say thus, let it happen. Make it a MUST. It is a trace header.
All relevant persons listen here (on emailcore). Any MTA
developer or giant appointed specialist whose software does not
comply could speak out. They listen, they then (as appointed
specialists) even know RFC 822 is the "real thing", hence it is
crystal clear that trace is an audit trail and thus sequential.
(It is not as if anyone cares for this -- how much is it,
1 percent or less? -- tiny corner of the internet that is not
covered by the giants (and/or their software), by postfix, exim,
qmail, opensmtpd (and all those comply), anyhow.
What belief is this you are talking about?
((It is overengineering.))
|[.]Numbering means that these can be tolerated
|the actual cost of numbering is very low, and it provides significant
|clarity and reassurance -- so I don't know why you are arguing it should
|not be present in the design -- and I am even less clear what it has to
|do with the proposed charter for a Working Group
Ah. Methodology.
|- --
|richard Richard Clayton
|
|Those who would give up essential Liberty, to purchase a little temporary
|Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
Off-topic, but what is "liberty"? Under-educated under-informed
under-aware (and how did they get *there*?) people making greedy
decisions. Over 76 percent loss of life (diversity) since 1970,
the Club of Rome "the limits to growth" report of 1972 it is we
comply to completely -- so much to "clarity and reassurance",
hah!. I have a techno song as part of a set of a wordwide known
DJ from around Y2K that i truly could find, it says "Freedom is
relevant. Self-determination is relevant. You must comply". And
sorry, the white man has simply failed. He never embraced the
problem and paved a way for "the whole thing". And never
will. Other civilizations and philosophies did (at least *think*)
so before ours existed.
|-----BEGIN PGP SIGNATURE-----
|Version: PGPsdk version 1.7.1
|
|iQA/AwUBZzlJ8t2nQQHFxEViEQLJSQCg9WYPovauvcaZZddKq39S0JDC9pIAnjpm
|x9w8oAzvWwSb4bNYUy8NeD7t
|=+Muk
|-----END PGP SIGNATURE-----
--End of <jszrijbynuonf...@highwayman.com>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
