Marcel Logen in de.test:

>>>>><https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>
>>>>
>>>>Beispiel:
>>>>
>>>>| Date: Thu, 11 Apr 2024 17:03:54 +0200
>>>>| Message-ID: <87msq0j605.fsf@n14.ybtra.de>
>>>>
>>>>Die Variable "message-uniq-id-char" hat (in dieser Gnus-Sitzung?) den
>>>>Wert 284.
>>>>
>>>> 284 % 25 = 9
>>>> 284 // 25 = 11
>>>>
>>>>Also 11 * 25 + 9 = 284.
>>>>
>>>>Datumsumrechnung (mit GNU date in der bash):
>>>>
>>>> date -d '11 Apr 2024 17:03:54 +0200' +%s
>>>>
>>>>ergibt
>>>>
>>>> 1712847834.
>>>>
>>>>In Emacs ("M-x eval-expression" oder mit "M-:"):
>>>>
>>>> M-: (message-number-base36 (+ (ash 1712847834 -16) (ash 9 16)) 4) RET
>>>>
>>>>ergibt
>>>>
>>>> msq0
>>>>
>>>>und
>>>>
>>>> M-: (message-number-base36 (+ (logand 1712847834 #xffff) (ash 11 16)) 4) RET
>>>>
>>>>ergibt:
>>>>
>>>> j605
>>>>
>>>>"ash" ist "bit shift to left" (oder "to right", wenn das zweite Argument
>>>>negativ ist). "logand" ist bitweises AND.
>>>>
>>>>Zusammen mit der User-ID 1000 (=> 87) hier auf dem Rechner kommt der
>>>>linke Teil "87msq0j605" heraus. => OK!
>>>>
>>>>Die Frage ist natürlich, ob man aus einer gegebenen Gnus-Message-ID wieder
>>>>den Wert von "message-uniq-id-char" berechnen kann ...
>>>
>>>Ich habe jetzt den Wert von "message-uniq-id-char" auf 0 gesetzt.
>>>Mal sehen, was mit der Message-ID passiert.
>>
>>Ach so: Der Wert der Variablen wird bei jedem neuen Posting um 1 erhöht.
>
>Genauer: bei jedem Aufruf von "message.el"? Grübel.
>
>>| Date: Thu, 11 Apr 2024 18:48:37 +0200
>>| Message-ID: <87y19jzvyy.fsf@n14.ybtra.de>
>>
>>timestamp: 1712854117
>>
>>1 = 0 * 25 + 1
>>
>>Also:
>>
>> M-: (message-number-base36 (+ (ash 1712854117 -16) (ash 1 16)) 4) RET
>> => y19j
>>
>> M-: (message-number-base36 (+ (logand 1712854117 #xffff) (ash 0 16)) 4)
>> => zvyy
>
>So langsam blicke ich da durch. :-)
>
>Mal rückwärts rechnen:
>
>| user14@n14:~$ echo 'zyxwvutsrqponmlkjihgfedcba9876543210' && echo '0----+----1----+----2----+----3----+'
>| zyxwvutsrqponmlkjihgfedcba9876543210
>| 0----+----1----+----2----+----3----+
>
> y 1 9 j
>y19j = 1 * 36^3 + 34 * 36^2 + 26 * 36 + 16 = 91672
>
> z v y y
>zvyy = 0 * 36^3 + 4 * 36^2 + 1 * 36 + 1 = 5221
>
>Der timestamp dazu war ja: 1712854117 (s. o.)
>
>1712854117 // 65536 = 26136
>1 * 65536 = 65536
> --------
> 91672 (sieh an!)
>
>M-: (logand 1712854117 #xffff) RET
>=> 5221 (#o12145, #x1465)
>
>Und: 1712854117 = 0x66181465
> ^^^^
>
>Wie bekomme ich jetzt aus diesem Wust den Wert von "message-uniq-id-char"?
>Hm ...
>
>Na ja, vielleicht heute am späteren Abend mal weitermachen.

Ein 'Reverse-Engineering'-Beispiel:

| Date: Fri, 08 Mar 2024 17:35:14 +0100
| Message-ID: <86y1asel6l...

Zunächst die 86. Das sollte die User ID 1001 sein.

zyxwvutsrqponmlkjihgfedcba9876543210
0----+----1----+----2----+----3----+

8 6
27 * 36 + 29 = 1001

timestamp:

date -d '8 Mar 2024 17:35:14 +0100' +%s
=> 1709915714

1709915714 // 65536 = 26091

y1as:

y 1 a s
1 *36^3 + 34 * 36^2 + 25 * 36 + 7 = 91627
- 26091
---------
65536 = 1 * 65536
el6l:

e l 6 l
21 *36^3 + 14 * 36^2 + 29 * 36 + 14 = 998978

998978 // 65536 = 15

Dann wäre "message-uniq-id-char" = 15 * 25 + 1 = 376

Jetzt die Probe - ich bin gespannt:

M-: (message-number-base36 (+ (ash 1709915714 -16) (ash 1 16)) 4) RET
=> y1as

und

M-: (message-number-base36 (+ (logand 1709915714 #xffff) (ash 15 16)) 4) RET
=> el6l

=> OK :-)

Man kann also bei Kenntnis des timestamps auf message-uniq-id-char
schließen.

(Ich hoffe, ich habe keinen Fehler drin.)

Marcel

fup2 de.comm.software.gnus
(vielleicht interessiert das ja dort jemanden :-)

Marcel Logen <333200007110-0201@ybtra.de> writes:

> Marcel Logen in de.test:
>
>>>>>><https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>
>>>>>
>>>>>Beispiel:
>>>>>
>>>>>| Date: Thu, 11 Apr 2024 17:03:54 +0200
>>>>>| Message-ID: <87msq0j605.fsf@n14.ybtra.de>
>>>>>
>>>>>Die Variable "message-uniq-id-char" hat (in dieser Gnus-Sitzung?) den
>>>>>Wert 284.
>>>>>
>>>>> 284 % 25 = 9
>>>>> 284 // 25 = 11
>>>>>
>>>>>Also 11 * 25 + 9 = 284.
>>>>>
>>>>>Datumsumrechnung (mit GNU date in der bash):
>>>>>
>>>>> date -d '11 Apr 2024 17:03:54 +0200' +%s
>>>>>
>>>>>ergibt
>>>>>
>>>>> 1712847834.
>>>>>
>>>>>In Emacs ("M-x eval-expression" oder mit "M-:"):
>>>>>
>>>>> M-: (message-number-base36 (+ (ash 1712847834 -16) (ash 9 16)) 4) RET
>>>>>
>>>>>ergibt
>>>>>
>>>>> msq0
>>>>>
>>>>>und
>>>>>
>>>>> M-: (message-number-base36 (+ (logand 1712847834 #xffff) (ash 11 16)) 4) RET
>>>>>
>>>>>ergibt:
>>>>>
>>>>> j605
>>>>>
>>>>>"ash" ist "bit shift to left" (oder "to right", wenn das zweite Argument
>>>>>negativ ist). "logand" ist bitweises AND.
>>>>>
>>>>>Zusammen mit der User-ID 1000 (=> 87) hier auf dem Rechner kommt der
>>>>>linke Teil "87msq0j605" heraus. => OK!
>>>>>
>>>>>Die Frage ist natürlich, ob man aus einer gegebenen Gnus-Message-ID wieder
>>>>>den Wert von "message-uniq-id-char" berechnen kann ...
>>>>
>>>>Ich habe jetzt den Wert von "message-uniq-id-char" auf 0 gesetzt.
>>>>Mal sehen, was mit der Message-ID passiert.
>>>
>>>Ach so: Der Wert der Variablen wird bei jedem neuen Posting um 1 erhöht.
>>
>>Genauer: bei jedem Aufruf von "message.el"? Grübel.
>>
>>>| Date: Thu, 11 Apr 2024 18:48:37 +0200
>>>| Message-ID: <87y19jzvyy.fsf@n14.ybtra.de>
>>>
>>>timestamp: 1712854117
>>>
>>>1 = 0 * 25 + 1
>>>
>>>Also:
>>>
>>> M-: (message-number-base36 (+ (ash 1712854117 -16) (ash 1 16)) 4) RET
>>> => y19j
>>>
>>> M-: (message-number-base36 (+ (logand 1712854117 #xffff) (ash 0 16)) 4)
>>> => zvyy
>>
>>So langsam blicke ich da durch. :-)
>>
>>Mal rückwärts rechnen:
>>
>>| user14@n14:~$ echo 'zyxwvutsrqponmlkjihgfedcba9876543210' && echo '0----+----1----+----2----+----3----+'
>>| zyxwvutsrqponmlkjihgfedcba9876543210
>>| 0----+----1----+----2----+----3----+
>>
>> y 1 9 j
>>y19j = 1 * 36^3 + 34 * 36^2 + 26 * 36 + 16 = 91672
>>
>> z v y y
>>zvyy = 0 * 36^3 + 4 * 36^2 + 1 * 36 + 1 = 5221
>>
>>Der timestamp dazu war ja: 1712854117 (s. o.)
>>
>>1712854117 // 65536 = 26136
>>1 * 65536 = 65536
>> --------
>> 91672 (sieh an!)
>>
>>M-: (logand 1712854117 #xffff) RET
>>=> 5221 (#o12145, #x1465)
>>
>>Und: 1712854117 = 0x66181465
>> ^^^^
>>
>>Wie bekomme ich jetzt aus diesem Wust den Wert von "message-uniq-id-char"?
>>Hm ...
>>
>>Na ja, vielleicht heute am späteren Abend mal weitermachen.
>
> Ein 'Reverse-Engineering'-Beispiel:
>
>| Date: Fri, 08 Mar 2024 17:35:14 +0100
>| Message-ID: <86y1asel6l...
>
> Zunächst die 86. Das sollte die User ID 1001 sein.
>
> zyxwvutsrqponmlkjihgfedcba9876543210
> 0----+----1----+----2----+----3----+
>
> 8 6
> 27 * 36 + 29 = 1001
>
> timestamp:
>
> date -d '8 Mar 2024 17:35:14 +0100' +%s
> => 1709915714
>
> 1709915714 // 65536 = 26091
>
> y1as:
>
> y 1 a s
> 1 *36^3 + 34 * 36^2 + 25 * 36 + 7 = 91627
> - 26091
> ---------
> 65536 = 1 * 65536
> el6l:
>
> e l 6 l
> 21 *36^3 + 14 * 36^2 + 29 * 36 + 14 = 998978
>
> 998978 // 65536 = 15
>
> Dann wäre "message-uniq-id-char" = 15 * 25 + 1 = 376
>
> Jetzt die Probe - ich bin gespannt:
>
> M-: (message-number-base36 (+ (ash 1709915714 -16) (ash 1 16)) 4) RET
> => y1as
>
> und
>
> M-: (message-number-base36 (+ (logand 1709915714 #xffff) (ash 15 16)) 4) RET
> => el6l
>
> => OK :-)
>
> Man kann also bei Kenntnis des timestamps auf message-uniq-id-char
> schließen.
>
> (Ich hoffe, ich habe keinen Fehler drin.)
>
> Marcel
>
> fup2 de.comm.software.gnus
> (vielleicht interessiert das ja dort jemanden :-)

Und? Ist das gefährlichh?

--
Stefan

Stefan Wiens in de.comm.software.gnus:

>Marcel Logen <333200007110-0201@ybtra.de> writes:
>> Marcel Logen in de.test:

>>>>>>><https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>

[...]

>> Man kann also bei Kenntnis des timestamps auf message-uniq-id-char
>> schließen.

Ob das auch ohne den timestamp geht, habe ich noch nicht heraus-
gefunden. (Dazu muß man womöglich ein Gleichungssystem mit drei
Gleichungen und drei Variablen lösen.)

>> (Ich hoffe, ich habe keinen Fehler drin.)

>> fup2 de.comm.software.gnus
>> (vielleicht interessiert das ja dort jemanden :-)
>
>Und? Ist das gefährlichh?

Nach meiner Einschätzung nicht, da es sich bei message-uniq-id-char
ja nur um einen internen Zähler handelt, der auch noch, wenn zunächst
nicht gesetzt, mit einer Zufallszahl (bis 625) initialisiert wird.

Marcel

Marcel Logen <333200007110-0201@ybtra.de> writes:

> Stefan Wiens in de.comm.software.gnus:
>
>>Marcel Logen <333200007110-0201@ybtra.de> writes:
>>> Marcel Logen in de.test:
>
>>>>>>>><https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>
>
> [...]
>
>>> Man kann also bei Kenntnis des timestamps auf message-uniq-id-char
>>> schließen.
>
> Ob das auch ohne den timestamp geht, habe ich noch nicht heraus-
> gefunden. (Dazu muß man womöglich ein Gleichungssystem mit drei
> Gleichungen und drei Variablen lösen.)
>
>>> (Ich hoffe, ich habe keinen Fehler drin.)
>
>>> fup2 de.comm.software.gnus
>>> (vielleicht interessiert das ja dort jemanden :-)
>>
>>Und? Ist das gefährlichh?
>
> Nach meiner Einschätzung nicht, da es sich bei message-uniq-id-char
> ja nur um einen internen Zähler handelt, der auch noch, wenn zunächst
> nicht gesetzt, mit einer Zufallszahl (bis 625) initialisiert wird.

Meinst Du, dass verschiedene Postings auf einen
Benutzer zusammen geführt werden können?

Aber das ist ja eine Schwierigkeit bei der
Message-ID. Will man nicht die Kollision
bei reinen Zufallsdaten riskieren, muss
man auf Zeitstempel und Ähnliches zurückgreifen.

Da message-uniq-id-char nur für die Erzeugung
von Message-IDs herangezogen wird, ist die Preisgabe
so einer internen Variablen vielleicht nicht so
schwerwiegend.

Der Wert ist hier gerade 62.

--
Stefan

Stefan Wiens in de.comm.software.gnus:

>Marcel Logen <333200007110-0201@ybtra.de> writes:
>> Stefan Wiens in de.comm.software.gnus:

[<https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>]

[Ermittlung von "message-unique-id-char"?]
>>>Und? Ist das gefährlichh?
>>
>> Nach meiner Einschätzung nicht, da es sich bei message-uniq-id-char
lies: "message-unique-id-char" (!)

>> ja nur um einen internen Zähler handelt, der auch noch, wenn zunächst
>> nicht gesetzt, mit einer Zufallszahl (bis 625) initialisiert wird.
>
>Meinst Du, dass verschiedene Postings auf einen
>Benutzer zusammen geführt werden können?

Das halte ich für unwahrscheinlich.

>Aber das ist ja eine Schwierigkeit bei der
>Message-ID. Will man nicht die Kollision
>bei reinen Zufallsdaten riskieren, muss
>man auf Zeitstempel und Ähnliches zurückgreifen.

Die Sache wird IMHO noch einfacher dadurch, daß es ja auch
noch eine Seite rechts vom @ in der MID gibt.

>Da message-uniq-id-char nur für die Erzeugung
>von Message-IDs herangezogen wird, ist die Preisgabe
>so einer internen Variablen vielleicht nicht so
>schwerwiegend.

Das sehe ich auch so.

>Der Wert ist hier gerade 62.

62 = 2 * 25 + 12

M-: (message-number-base36 (+ (ash 1712933115 -16) (ash (% 62 25) 16)) 4) RET
=> il0m

M-: (message-number-base36 (+ (logand 1712933115 #xffff) (ash (/ 62 25) 16)) 4) RET
=> wsg4

Deine Message-ID dazu war: <87il0mwsg4.fsf@eswe.dd-dns.de>.

Ich mußte da mit dem timestamp ein wenig herumprobieren, bis es paß-
te. Kann es vielleicht sein. daß Du bis zum Abschicken des Artikels
ca. 12 Minuten benötigt hast (und die MID schon zu Beginn des Editie-
rens erzeugt und nachher nicht mehr verändert wurde)?

| user14@n14:~$ date +%s -d '12 Apr 2024 16:57:21 +0200'
| 1712933841

| user14@n14:~$ date -d '@1712933115' -R
| Fri, 12 Apr 2024 16:45:15 +0200

Ich habe wie folgt gerechnet:

zyxwvutsrqponmlkjihgfedcba9876543210
0----+----1----+----2----+----3----+

| user14@n14:~$ bc -q
| 17*36^3+14*36^2+35*36+13
| 812569
|
| 3*36^3 + 7*36^2 + 19*36 + 31
| 149755
|
| 812569 / 65536
| 12
|
| 1712933841 / 65536
| 26137
|
| scale
| 0
|
| 812569 - 26137
| 786432
|
| 786432 / 65536
| 12
| 149755 / 65536
| 2

Marcel

Marcel Logen in de.comm.software.gnus:

>Stefan Wiens in de.comm.software.gnus:

[<https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el?h=emacs-29.3#n5901>]

[Ermittlung von "message-unique-id-char"?]
>>Der Wert ist hier gerade 62.
>
>62 = 2 * 25 + 12
>
>M-: (message-number-base36 (+ (ash 1712933115 -16) (ash (% 62 25) 16)) 4) RET
>=> il0m
>
>M-: (message-number-base36 (+ (logand 1712933115 #xffff) (ash (/ 62 25) 16)) 4) RET
>=> wsg4
>
>Deine Message-ID dazu war: <87il0mwsg4.fsf@eswe.dd-dns.de>.
>
>Ich mußte da mit dem timestamp ein wenig herumprobieren, bis es paß-
>te. Kann es vielleicht sein. daß Du bis zum Abschicken des Artikels
>ca. 12 Minuten benötigt hast (und die MID schon zu Beginn des Editie-
>rens erzeugt und nachher nicht mehr verändert wurde)?
>
>| user14@n14:~$ date +%s -d '12 Apr 2024 16:57:21 +0200'
>| 1712933841
>
>| user14@n14:~$ date -d '@1712933115' -R
>| Fri, 12 Apr 2024 16:45:15 +0200
>
>Ich habe wie folgt gerechnet:
>
> zyxwvutsrqponmlkjihgfedcba9876543210
> 0----+----1----+----2----+----3----+

Wobei ich jetzt nicht weiß, ob das alles richtig war. Ich sollte
das Ganze mal automatisieren. Jedenfalls habe ich stundenlang mit
verschiedenen Message-IDs herumgerechnet, und manchmal klappte es,
manchmal aber auch nicht. Grmpf.

Das Hauptproblem ist für mich derzeit das binäre AND mit 0xFFFF.
Ich weiß noch nicht, ob und wie ich das 'rückgängig' machen kann.

Ingrid

Marcel Logen in de.comm.software.gnus:

>Wobei ich jetzt nicht weiß, ob das alles richtig war. Ich sollte
>das Ganze mal automatisieren. Jedenfalls habe ich stundenlang mit
>verschiedenen Message-IDs herumgerechnet, und manchmal klappte es,
>manchmal aber auch nicht. Grmpf.
>
>Das Hauptproblem ist für mich derzeit das binäre AND mit 0xFFFF.
>Ich weiß noch nicht, ob und wie ich das 'rückgängig' machen kann.

Das muß ich gar nicht.

Ich habe jetzt ein Python3-Script geschrieben, das die meiste
Arbeit erledigt. Aber es klappt immer noch nicht in jedem Fall.

Problematisch ist die Division "/" in

(message-number-base36 (+ (logand 1712933841 #xffff) (ash (/ 12 25) 16)) 4)

Da muß ich dann durch Probieren die korrekte Zahl (statt der 12)
ermitteln. Also 12+25, 12+2*25, 12+3*25 etc. bis 12+24*25. Wenn
es denn überhaupt aufgeht.

Ingrid

Marcel Logen in de.comm.software.gnus:

>Marcel Logen in de.comm.software.gnus:

>>Wobei ich jetzt nicht weiß, ob das alles richtig war. Ich sollte
>>das Ganze mal automatisieren. Jedenfalls habe ich stundenlang mit
>>verschiedenen Message-IDs herumgerechnet, und manchmal klappte es,
>>manchmal aber auch nicht. Grmpf.

Ich habe jetzt eine Lösung (mit Python3).

Allerdings funktioniert die bei Stefan W. nicht.

>Ich habe jetzt ein Python3-Script geschrieben, das die meiste
>Arbeit erledigt. Aber es klappt immer noch nicht in jedem Fall.
>
>Problematisch ist die Division "/" in
>
> (message-number-base36 (+ (logand 1712933841 #xffff) (ash (/ 12 25) 16)) 4)
>
>Da muß ich dann durch Probieren die korrekte Zahl (statt der 12)
>ermitteln. Also 12+25, 12+2*25, 12+3*25 etc. bis 12+24*25. Wenn
>es denn überhaupt aufgeht.

Das Probieren habe ich auch automatisiert - und es führt tat-
sächlich zur Lösung. Beispiel: Das Posting, auf das ich antworte.

| Date: Sat, 13 Apr 2024 12:05:51 +0200
| Message-ID: <877ch1bmrk.fsf@n14.ybtra.de>

M-: (message-number-base36 (+ (ash 1713002751 -16) (ash (% 445 25) 16)) 4) RET
=> 7ch1

M-: (message-number-base36 (+ (logand 1713002751 #xffff) (ash (/ 445 25) 16)) 4) RET
=> bmrk

"message-unique-id-char" ist hier 425 (im Bereich von 0 bis 624).
Der timestamp laut "Date"-Headerfeld = 1713002751.

Scheint zu klappen. :-)

Ingrid

Marcel Logen in de.comm.software.gnus:

>Das Probieren habe ich auch automatisiert - und es führt tat-
>sächlich zur Lösung. Beispiel: Das Posting, auf das ich antworte.
>
>| Date: Sat, 13 Apr 2024 12:05:51 +0200
>| Message-ID: <877ch1bmrk.fsf@n14.ybtra.de>
>
> M-: (message-number-base36 (+ (ash 1713002751 -16) (ash (% 445 25) 16)) 4) RET
> => 7ch1
>
> M-: (message-number-base36 (+ (logand 1713002751 #xffff) (ash (/ 445 25) 16)) 4) RET
> => bmrk
>
>"message-unique-id-char" ist hier 425 (im Bereich von 0 bis 624).

Es muß natürlich "445" heißen!

>Der timestamp laut "Date"-Headerfeld = 1713002751.
>
>Scheint zu klappen. :-)

Eine weitere offene Frage (neben der, warum es bei Stefans
Postings nicht klappt) ist: Kann man (durch Probieren) auch
den benutzten timestamp ermitteln (ohne auf das "Date"-Header-
feld zurückgreifen zu müssen, also nur aus der Message-ID
(vielleicht aber mit dem "Date" als Startwert))?

Ingrid hur1 (588641)
--
╭────╮ ╭──────────╮ ╭───╮ ╭─╮ ╭─╮ ╭───╮ ╭─────
╯ ╭─╯ │ ╭───────╯ ╭───╮ ╭──╮ ╭─╯ ╰────╯ ╰─╯ ╰──╮ ╭────╯ ╰─╯
╭─╯ ╭─╯ ╰────╮ ╭──╯ ╰──╯ ╰─╯ ╭─────╯ │
╰────╯ ╰─╯ ╰───────╯ 5e45ff

Marcel Logen in de.comm.software.gnus:

>Marcel Logen in de.comm.software.gnus:

[...]

>>"message-unique-id-char" ist hier 425 (im Bereich von 0 bis 624).
>
>Es muß natürlich "445" heißen!

Diese Variable wird bei jedem Aufruf der Funktion "message-unique-id"
aus message.el (also wohl bei jedem Erstellen einer Message-ID) um
eins erhöht (mod 625). Wenn nicht gesetzt, wird ein Zufallswert ge-
nommen.

>>Scheint zu klappen. :-)
>
>Eine weitere offene Frage (neben der, warum es bei Stefans
>Postings nicht klappt) ist: Kann man (durch Probieren) auch
>den benutzten timestamp ermitteln (ohne auf das "Date"-Header-
>feld zurückgreifen zu müssen, also nur aus der Message-ID
>(vielleicht aber mit dem "Date" als Startwert))?

Hier der Output des Python3-Scripts mit einem Posting von
Stefan W.:

| user14@n14:~/ybtra-n14$ ./gnus-message-id13.py
| little
| b2 zyxwvutsrqponmlkjihgfedcba9876543210
| c3 ['', '', 'Date: Fri, 12 Apr 2024 19:05:45 +0200', 'Organization: none', 'Lines: 26', 'Message-ID: <877ch2wm4o.fsf@eswe.dd-dns.de>', '']
| e5 Date: Fri, 12 Apr 2024 19:05:45 +0200
| f6 Message-ID: <877ch2wm4o.fsf@eswe.dd-dns.de>
| g7 Fri, 12 Apr 2024 19:05:45 +0200
| h8 <877ch2wm4o.fsf@eswe.dd-dns.de>
| i9 2024-04-12 19:05:45+02:00
| (message-number-base36 (+ (ash 1712941303 -16) (ash (% 70 25) 16)) 4)
| (message-number-base36 (+ (logand 1712941303 #xffff) (ash (/ 70 25) 16)) 4)
| 2024-04-12 17:01:43 UTC
| user14@n14:~/ybtra-n14$

"message-unique-id-char" ist hier 70 - und der in die MID ein-
geflossene Zeitpunkt ist "19:01:43 MESZ".

Erst mal Ende mit "Ingrid" :-)

Marcel Logen <333200007110-0201@ybtra.de> writes:

> Stefan Wiens in de.comm.software.gnus:

[message-unique-id-char]

>>Der Wert ist hier gerade 62.
>
> 62 = 2 * 25 + 12
>
> M-: (message-number-base36 (+ (ash 1712933115 -16) (ash (% 62 25) 16)) 4) RET
> => il0m
>
> M-: (message-number-base36 (+ (logand 1712933115 #xffff) (ash (/ 62 25) 16)) 4) RET
> => wsg4
>
> Deine Message-ID dazu war: <87il0mwsg4.fsf@eswe.dd-dns.de>.
>
> Ich mußte da mit dem timestamp ein wenig herumprobieren, bis es paß-
> te. Kann es vielleicht sein. daß Du bis zum Abschicken des Artikels
> ca. 12 Minuten benötigt hast (und die MID schon zu Beginn des Editie-
> rens erzeugt und nachher nicht mehr verändert wurde)?

So ist es.

Hier ist der Wert der Variablen message-generate-headers-first t
und die Variable message-deletable-headers enthält nur Date und Lines,
nicht aber Message-ID, wie der Default wäre.

In diesem Augenblick hat message-unique-id-char hier den Wert 83.
Stände der Message-ID-Header nicht schon hier oben im Artikel,
würde der Zähler zuerst inkrementiert.

Aber was will man machen, das Verfahren soll ja auch mit mehreren
Postings pro Sekunde zurechtkommen.

--
Stefan

Stefan Wiens in de.comm.software.gnus:

>Marcel Logen <333200007110-0201@ybtra.de> writes:

[...]

>> Ich mußte da mit dem timestamp ein wenig herumprobieren, bis es paß-
>> te. Kann es vielleicht sein. daß Du bis zum Abschicken des Artikels
>> ca. 12 Minuten benötigt hast (und die MID schon zu Beginn des Editie-
>> rens erzeugt und nachher nicht mehr verändert wurde)?
>
>So ist es.

Ja, OK, danke für die Bestätigung.

>Hier ist der Wert der Variablen message-generate-headers-first t

Bei mir auch.

>und die Variable message-deletable-headers enthält nur Date und Lines,
>nicht aber Message-ID, wie der Default wäre.

Enthält hier alle drei Headerfeld-Namen.

>In diesem Augenblick hat message-unique-id-char hier den Wert 83.

Das konnte ich auch ermitteln:

| g7 Mon, 15 Apr 2024 22:23:35 +0200
| h8 <87o7aav2bf.fsf@eswe.dd-dns.de>
| i9 2024-04-15 22:23:35+02:00
| j36 1713212615
| (message-number-base36 (+ (ash 1713210244 -16) (ash (% 83 25) 16)) 4)
| (message-number-base36 (+ (logand 1713210244 #xffff) (ash (/ 83 25) 16)) 4)
| 2024-04-15 19:44:04 UTC

Die beiden Elisp-Zeilen ergeben hier "o7aa" und "v2bf".

Erstellungszeitpunkt der Message-ID war "2024-04-15T21:44:04+0200",
also etwa 40 Minuten vor dem Absenden.

Man muß also wohl doch (automatisiert) probieren - direktes Aus-
rechnen des timestamp und von message-unique-id-char funktioniert
nicht.

Aber man kann die "Aufgabe" lösen. :-)

Marcel

Marcel Logen <333200007110-0201@ybtra.de> writes:

> Stefan Wiens in de.comm.software.gnus:
>
>>Marcel Logen <333200007110-0201@ybtra.de> writes:
>
> [...]
>
>>> Ich mußte da mit dem timestamp ein wenig herumprobieren, bis es paß-
>>> te. Kann es vielleicht sein. daß Du bis zum Abschicken des Artikels
>>> ca. 12 Minuten benötigt hast (und die MID schon zu Beginn des Editie-
>>> rens erzeugt und nachher nicht mehr verändert wurde)?
>>
>>So ist es.
>
> Ja, OK, danke für die Bestätigung.
>
>>Hier ist der Wert der Variablen message-generate-headers-first t
>
> Bei mir auch.
>
>>und die Variable message-deletable-headers enthält nur Date und Lines,
>>nicht aber Message-ID, wie der Default wäre.
>
> Enthält hier alle drei Headerfeld-Namen.

Dann wird Die Message-ID beim Versenden neu ermittelt,
was den Suchraum (s. u.) verringert.

>>In diesem Augenblick hat message-unique-id-char hier den Wert 83.
>
> Das konnte ich auch ermitteln:
>
>| g7 Mon, 15 Apr 2024 22:23:35 +0200
>| h8 <87o7aav2bf.fsf@eswe.dd-dns.de>
>| i9 2024-04-15 22:23:35+02:00
>| j36 1713212615
>| (message-number-base36 (+ (ash 1713210244 -16) (ash (% 83 25) 16)) 4)
>| (message-number-base36 (+ (logand 1713210244 #xffff) (ash (/ 83 25) 16)) 4)
>| 2024-04-15 19:44:04 UTC
>
> Die beiden Elisp-Zeilen ergeben hier "o7aa" und "v2bf".
>
> Erstellungszeitpunkt der Message-ID war "2024-04-15T21:44:04+0200",
> also etwa 40 Minuten vor dem Absenden.

Könnte in etwa hinkommen. Ich habe zwischendurch noch im
Source-Code und der Doku geblättert und so weiter.

> Man muß also wohl doch (automatisiert) probieren - direktes Aus-
> rechnen des timestamp und von message-unique-id-char funktioniert
> nicht.
>
> Aber man kann die "Aufgabe" lösen. :-)

Der Suchraum ist überschaubar, (* 25 25 40 60) ergibt 1500000.

Interessanter könnte sein, zukünftige Message-IDs durch
prophylaktische Postings in weit verbreitete Testgruppen
zu unterbinden. Aber 150000 Postings für 40 min?

Dagegen könnte man sich einen Vorrat an Message-IDs
anlegen und diese dann wie eine TAN-Liste verbrauchen.
Natürlich nur aus Zeiträumen, in denen man Kontrolle
über den FQDN hat(te).

Das geht aber schon an die Grenze der Empfehlungen in
message.el (nahe der Funktion message-unique-id), wann
man den originalen Algorithmus verlässt und am Suffix
oder anders die Änderung kenntlich machen sollte.

--
Stefan

Stefan Wiens in de.comm.software.gnus:

>Marcel Logen <333200007110-0201@ybtra.de> writes:

[...]

>>| (message-number-base36 (+ (ash 1713210244 -16) (ash (% 83 25) 16)) 4)
>>| (message-number-base36 (+ (logand 1713210244 #xffff) (ash (/ 83 25) 16)) 4)
>>| 2024-04-15 19:44:04 UTC
>>
>> Die beiden Elisp-Zeilen ergeben hier "o7aa" und "v2bf".

Die Funktion "message-number-base36" habe ich inzwischen
in Python3 'nachgebaut'. So muß ich nicht immer Gnus be-
mühen, wenn ich eine Gnus-Message-ID analysieren will.

[...]

>> Man muß also wohl doch (automatisiert) probieren - direktes Aus-
>> rechnen des timestamp und von message-unique-id-char funktioniert
>> nicht.
>>
>> Aber man kann die "Aufgabe" lösen. :-)
>
>Der Suchraum ist überschaubar, (* 25 25 40 60) ergibt 1500000.

Die 25*25=625 kann man noch, wenn ich mich jetzt nicht
in meinem eigenen Code verzettelt habe und deshalb flacsh
liege, ein wenig reduzieren, indem man - ausgehend von ei-
nem 25er-Rest als Startwert - in 25er-Schritten vorgeht/
sucht. Den Startwert kann man AFAICS aus der Message-ID
und dem timestamp ermitteln (siehe dazu die erste Zeile
oben).

>Interessanter könnte sein, zukünftige Message-IDs durch
>prophylaktische Postings in weit verbreitete Testgruppen
>zu unterbinden. Aber 150000 Postings für 40 min?

Wieso sollte man das wollen? Sabotage?

>Dagegen könnte man sich einen Vorrat an Message-IDs
>anlegen und diese dann wie eine TAN-Liste verbrauchen.
>Natürlich nur aus Zeiträumen, in denen man Kontrolle
>über den FQDN hat(te).
>
>Das geht aber schon an die Grenze der Empfehlungen in
>message.el (nahe der Funktion message-unique-id), wann
>man den originalen Algorithmus verlässt und am Suffix
>oder anders die Änderung kenntlich machen sollte.

Mir selbst geht es nur um die Analyse der vorhandenen
Message-IDs, nicht um ein neues Verfahren.

Marcel
--
╭─╮ ╭───╮ ╭────╮ ╭─╮ ╭────╮ ..67..
╭──╯ ╰──╮ ╭───╯ │ ╭─╮ ╰──╮ │ ..42..╭─╯ ╰─╮ ╭─╯ ╰───╮ ╭──
╰─╮ ╭──╯ ╭─╯ ╭────╯ ╭─╯ ╰─────╯ ╰─╮ ╭──╮ ╭─╯ ╭──╯ │ ╭───────╯ ╰─╮
╭──╯ ╰────╯ ╰──────╯ ..32..╰─╯ ╰──╯ ╰────╯ ╰────────────╯

Marcel Logen <333200007110-0201@ybtra.de> writes:

> Stefan Wiens in de.comm.software.gnus:
>
>>Marcel Logen <333200007110-0201@ybtra.de> writes:
>
> [...]
>
>>>| (message-number-base36 (+ (ash 1713210244 -16) (ash (% 83 25) 16)) 4)
>>>| (message-number-base36 (+ (logand 1713210244 #xffff) (ash (/ 83 25) 16)) 4)
>>>| 2024-04-15 19:44:04 UTC
>>>
>>> Die beiden Elisp-Zeilen ergeben hier "o7aa" und "v2bf".
>
> Die Funktion "message-number-base36" habe ich inzwischen
> in Python3 'nachgebaut'. So muß ich nicht immer Gnus be-
> mühen, wenn ich eine Gnus-Message-ID analysieren will.
>
> [...]
>
>>> Man muß also wohl doch (automatisiert) probieren - direktes Aus-
>>> rechnen des timestamp und von message-unique-id-char funktioniert
>>> nicht.
>>>
>>> Aber man kann die "Aufgabe" lösen. :-)
>>
>>Der Suchraum ist überschaubar, (* 25 25 40 60) ergibt 1500000.
>
> Die 25*25=625 kann man noch, wenn ich mich jetzt nicht
> in meinem eigenen Code verzettelt habe und deshalb flacsh
> liege, ein wenig reduzieren, indem man - ausgehend von ei-
> nem 25er-Rest als Startwert - in 25er-Schritten vorgeht/
> sucht. Den Startwert kann man AFAICS aus der Message-ID
> und dem timestamp ermitteln (siehe dazu die erste Zeile
> oben).

Da könntest du richtig liegen.

>>Interessanter könnte sein, zukünftige Message-IDs durch
>>prophylaktische Postings in weit verbreitete Testgruppen
>>zu unterbinden. Aber 150000 Postings für 40 min?
>
> Wieso sollte man das wollen? Sabotage?

Was sonst kann man mit der Kenntnis dieses
internen Zählers message-uniq-id-char anstellen?

Evtl. lassen sich rückwirkend Message-IDs derselben
Emacs-Session zuordnen, und das will man vielleicht
nicht.

Die User-ID macht Gnus ja sehr offen bekannt.

Aber es bleibt doch dabei:
Die Zutaten zum linken Teil der Message-ID
sind: User-ID, der o. g. Zähler modulo 625
und der Timestamp (in Sekunden).
Die Verwürfelungen fügen nichts neues
hinzu.

--
Stefan

Stefan Wiens in de.comm.software.gnus:

>Marcel Logen <333200007110-0201@ybtra.de> writes:
>> Stefan Wiens in de.comm.software.gnus:

Jetzt hast Du mich aber zu sabotieren versucht. ;-)

Die Zeitspanne zwischen Erstellung der MID (1713400791)
und dem Versand deines Postings (1713420821) lag bei über
20000 Sekunden (ca. 5 1/2 Std.).

Ich habe dann einfach den Suchbereich in meinem Script
von 9000 auf 90000 Sekunden erhöht. Danach ging es auch
noch recht fix.

| Thu, 18 Apr 2024 08:13:41 +0200
| <87bk67v6zs.fsf@eswe.dd-dns.de>
| 2024-04-18 08:13:41+02:00
| 1713420821
| (message-number-base36 (+ (ash 1713400791 -16) (ash (% 92 25) 16)) 4)
| bk67
| (message-number-base36 (+ (logand 1713400791 #xffff) (ash (/ 92 25) 16)) 4)
| v6zs
| 2024-04-18 00:39:51 UTC
| 20030

Vermutlich nutzt Du immer noch dieselbe Gnus-Session
wie schon seit Tagen. message-unique-id-char ist 92.

[...]

>>>Interessanter könnte sein, zukünftige Message-IDs durch
>>>prophylaktische Postings in weit verbreitete Testgruppen
>>>zu unterbinden. Aber 150000 Postings für 40 min?
>>
>> Wieso sollte man das wollen? Sabotage?
>
>Was sonst kann man mit der Kenntnis dieses
>internen Zählers message-uniq-id-char anstellen?
>
>Evtl. lassen sich rückwirkend Message-IDs derselben
>Emacs-Session zuordnen, und das will man vielleicht
>nicht.

Jo.

>Die User-ID macht Gnus ja sehr offen bekannt.
>
>Aber es bleibt doch dabei:
>Die Zutaten zum linken Teil der Message-ID
>sind: User-ID, der o. g. Zähler modulo 625
>und der Timestamp (in Sekunden).
>Die Verwürfelungen fügen nichts neues
>hinzu.

Volle Zustimmung dazu meinerseits.

Ich glaube, ich kann das Thema für mich als abgeschlos-
sen betrachten. :-) Ein Tool für die Analyse der Gnus-
MIDs habe ich ja jetzt.

Marcel
--
╭─────╮ ╭──╮ ╭─────╮ ╭────────────╮ ╭─╮ ..67..
╰──╮ │ ╭─╯ ╰──╯ ╭──╯ ╰─────────╮ │ ╭──╯ ╰─╮ ╭────╮ ..67..
──╮ │ │ ╭─╯ ╭───────╯ ╭───╮ ╭─╮ ╭──╯ │ │ ╭───╯ ╰─╮ ╰─╮ ╭──╮
╰─╯ ╰─╯ ╰─────────╯ ╰─╯ ╰──╯ ╰─╯ ╰───────────╯ ╰─╯ ╰───