INN: seltsame Effekte bei CHECK/TAKETHIS

[Stefan+ (Stefan Froehlich)]

Ich habe seit ein paar Tagen einen neu installierten inn laufen. Debian 8
out of the box, einen Feed eingetragen. Der Feed arbeitet brav, aber nun
erhalte ich in den Logfiles interessante Meldungen der Art:

| May 2 09:57:07 innd: ME time 481625 idle 481597(26) artwrite 1(3) artlink 0(0) hiswrite 0(3) hissync 0(1) sitesend 0(6) artctrl 0(0) artcncl 0(0) hishave 0(3) hisgrep 0(0) perl 0(3)
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command welchen?)
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command --
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command Antworrflüssig.essig.ssig.essig.erfl�erflü
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command .
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command .
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command .
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command . .. .
| May 2 09:57:07 innd: pasture.szaf.org:15 bad_command .

Da ich damit rein gar nichts anfangen konnte (und inn-Experte bin ich schon
überhaupt nicht), habe ich mir den Datenverkehr mit tcpdump angesehen. Die
Unterhaltung auf der Leitung läuft (mit Auslassungen) wie folgt:

[Server bietet Posting an]
| 0x0030: 0645 2700 4348 4543 4b20 3c6d 6932 3030 .E'.CHECK.<mi200
| 0x0040: 6824 336c 3724 3140 7370 6572 616e 7a61 h$3l7$***@speranza
| 0x0050: 2e61 696f 652e 6f72 673e 0d0a .aioe.org>..

[Client will das Posting haben]
| 0x0030: 074c e6a1 3233 3820 3c6d 6932 3030 6824 .L..238.<mi200h$
| 0x0040: 336c 3724 3140 7370 6572 616e 7a61 2e61 3l7$***@speranza.a
| 0x0050: 696f 652e 6f72 673e 0d0a ioe.org>..

[Server sendet Posting]
| 0x0030: 0646 8282 5441 4b45 5448 4953 203c 6d69 .F..TAKETHIS.<mi
| 0x0040: 3230 3068 2433 6c37 2431 4073 7065 7261 200h$3l7$***@spera
| 0x0050: 6e7a 612e 6169 6f65 2e6f 7267 3e0d 0a50 nza.aioe.org>..P
| 0x0060: 6174 683a 206e 6577 732e 737a 6166 2e6f ath:.news.szaf.o
| [...]
| 0x0370: 6572 2069 6d20 5573 656e 6574 220d 0a70 er.im.Usenet"..p
| 0x0380: 6572 73c3 b66e 6c69 6368 3f0d 0a0d 0a4b ers..nlich?....K
| 0x0390: 656e 6e73 7420 6475 2050 6f73 743f 0d0a ennst.du.Post?..
| 0x03a0: 4b65 6e6e 7374 2064 7520 466c 6163 686d Kennst.du.Flachm
| 0x03b0: 616e 6e3f 0d0a 285a 7520 6265 6964 656e ann?..(Zu.beiden
| 0x03c0: 2068 6174 7465 7374 2064 7520 4b6f 6e74 .hattest.du.Kont
| 0x03d0: 616b 7429 0d0a 2861 6265 7220 7765 6c63 akt)..(aber.welc
| 0x03e0: 6865 6e3f 290d 0a2d 2d20 0d0a 416e 7477 hen?)..--...Antw
| 0x03f0: 6f72 7420 c3bc 6265 7266 6cc3 bc73 7369 ort...berfl..ssi
| 0x0400: 672e 0d0a 2e0d 0a g......

[Client bestaetigt Erhalt des Postings]
| 0x0000: 4500 005a 3a5c 4000 4006 1a19 94fb 522e E..Z:\@***@.....R.
| 0x0010: 576a a795 0077 c412 0a95 1d34 32a5 206f Wj...w.....42..o
| 0x0020: 8018 00dc fee2 0000 0101 080a 0646 8285 .............F..
| 0x0030: 074c e6a3 3233 3920 3c6d 6932 3030 6824 .L..239.<mi200h$
| 0x0040: 336c 3724 3140 7370 6572 616e 7a61 2e61 3l7$***@speranza.a
| 0x0050: 696f 652e 6f72 673e 0d0a ioe.org>..

Das Protokoll ist in RFC4644 definiert und nicht gerade rocket
science. Da sehe ich nicht viel Platz für Fehler, insbesondere
scheint mir der mit "bad_command" beschuldigte Sender aus dem
Schneider zu sein.

Tatsächlich gespeichert wurde allerdings:

| sfroehli:~$ tail -n 5 /var/spool/news/de/soc/arbeitslos/88
|
| Kennst du _einen_ "Teilnehmer" "hier im Usenet"
| persönlich?
|
| Kennst du Post überflüssig.

Das ist NICHT das, was gesendet worden ist, sondern in den letzten 5
Zeilen wurde ein Textstück einfach herausgeschnitten, und zwar in
etwa (aber auch wieder nicht exakt) das, was in den dubiosen
Fehlermeldungen als Kommando fehlinterpretiert worden ist.

Dummerweise betrifft das nicht nur diesen einen Artikel, sondern
mehrere pro Minute (immer der gleiche Effekt: gegen Ende des
Postings wird ein Block aus dem Text herausgeschnitten, der eine bis
einige wenige Zeilen gross ist), ich würde das daher gerne aus der
Welt schaffen. Ich habe allerdings nicht einmal ansatzweise eine
Ahnung, wo ich mit der Suche anfangen soll. Hat jemand Ideen?

Servus,
Stefan

[Thomas Hochstein]

Post by Stefan+ (Stefan Froehlich)
Das ist NICHT das, was gesendet worden ist, sondern in den letzten 5
Zeilen wurde ein Textstück einfach herausgeschnitten, und zwar in
etwa (aber auch wieder nicht exakt) das, was in den dubiosen
Fehlermeldungen als Kommando fehlinterpretiert worden ist.

Schuss ins Blaue:

Als Ende des Postings fehlinterpretiertes "." alleine auf einer Zeile,
mit der Folge, dass danach wieder Befehle erwartet werden, aber der
Rest des Postings kommt?

[Stefan+ (Stefan Froehlich)]

Post by Thomas Hochstein

Post by Stefan+ (Stefan Froehlich)
Das ist NICHT das, was gesendet worden ist, sondern in den letzten 5
Zeilen wurde ein Textstück einfach herausgeschnitten, und zwar in
etwa (aber auch wieder nicht exakt) das, was in den dubiosen
Fehlermeldungen als Kommando fehlinterpretiert worden ist.

Als Ende des Postings fehlinterpretiertes "." alleine auf einer Zeile,
mit der Folge, dass danach wieder Befehle erwartet werden, aber der
Rest des Postings kommt?

War auch mein erster Gedanke, aber bei keinem der Beispiele der Fall,
die ich mir angesehen habe (auch nicht bei dem aus meinem Vorposting).

Auch wenn ich nicht viel vom Inn verstehe - das einzige am System,
was mir *vollkommen* fremd ist, ist der systemd, und der ist jetzt
für die Aussenkommunikation zuständig. Mein nächster Ansatz wäre
nachzusehen, was tatsächlich beim inn ankommt... aber wie schneidet
man die annlassbezogene Kommunikation zwischen systemd und inn mit?

(Xpost nach dcoulm der letzten Frage wegen)

Servus,
Stefan

[Sven Hartge]

Auch wenn ich nicht viel vom Inn verstehe - das einzige am System, was
mir *vollkommen* fremd ist, ist der systemd, und der ist jetzt für die
Aussenkommunikation zuständig. Mein nächster Ansatz wäre nachzusehen,
was tatsächlich beim inn ankommt... aber wie schneidet man die
annlassbezogene Kommunikation zwischen systemd und inn mit?

Seit wann ist systemd für die Aussenkommunikation zuständig? Ich glaube,
du verwechselst hier etwas.

S°

[Stefan+ (Stefan Froehlich)]

Post by Sven Hartge

[...] was mir *vollkommen* fremd ist, ist der systemd, und der
ist jetzt für die Aussenkommunikation zuständig. Mein nächster
Ansatz wäre nachzusehen, was tatsächlich beim inn ankommt...
aber wie schneidet man die annlassbezogene Kommunikation
zwischen systemd und inn mit?

Seit wann ist systemd für die Aussenkommunikation zuständig? Ich
glaube, du verwechselst hier etwas.

Hmja, Du hast wohl recht - der systemd lauscht zwar auf dem
entsprechenden Port, reicht aber dann das Socket weiter, anstatt
Proxy zu spielen. Ist halt alles irgendwie neu und ungewohnt.

Das eigentliche Problem wird dadurch leider nicht kleiner...

Servus,
Stefan

[Stefan+ (Stefan Froehlich)]

Mein nächster Ansatz wäre nachzusehen, was tatsächlich beim inn
ankommt...

Nichts gutes. Ein strace() auf inn erzeugt folgendes (der Materie
halber ungekürzt):

#v+
Process 8021 attached
select(16, [3 11 13 15], [], NULL, {299675, 374837}) = 1 (in [15], left {299639, 31229})
lseek(7, 0, SEEK_SET) = 0
write(7, "dbz 3 1000003 9 C 128 127 24 8 7 6 5 4 3 2 1 0 0\n3413 2750 1265 2 0 0 0 0 0 0 0\n301211 243241 112137 120 0 0 0 0 0 0 0\n", 119) = 119
read(15, "CHECK <mi2jt2$88o$***@news.albasani.net>\r\n", 8191) = 40
write(15, "238 <mi2jt2$88o$***@news.albasani.net>\r\n", 38) = 38
sendto(4, "<61>May 2 15:36:34 innd: ME time 361252 idle 361204(37) artwrite 0(4) artlink 0(0) hiswrite 0(4) hissync 0(1) sitesend 0(8) artctrl 0(0) artcncl 0(0) hishave 0(8) hisgrep 0(0) perl 0(4) ", 187, MSG_NOSIGNAL, NULL, 0) = 187
select(16, [3 11 13 15], [], NULL, {300, 0}) = 1 (in [15], left {299, 992225})
read(15, "TAKETHIS <mi2jt2$88o$***@news.albasani.net>\r\nPath: news.szaf.o
rg!news.albasani.net!.POSTED!not-for-mail\r\nFrom: \"MaWin\" <me
@private.net>\r\nNewsgroups: de.rec.heimwerken\r\nSubject: Re: W
asser - undichter Keller, Ursachenforschung\r\nDate: Sat, 2 May
2015 15:36:33 +0200\r\nOrganization: albasani.net\r\nLines: 14\r
\nMessage-ID: <mi2jt2$88o$***@news.albasani.net>\r\nReferences: <5
8f2fdc0-fe9b-49d9-848c-***@googlegroups.com> <slrnmk9bm
r.2379.t-***@ID-685.user.individual.de> <67cc43c0-66d7-4467-8
1e8-***@googlegroups.com>\r\nMime-Version: 1.0\r\nConte
nt-Type: text/plain;\r\n\tformat=flowed;\r\n\tcharset=\"iso-8859
-1\";\r\n\treply-type=original\r\nContent-Transfer-Encoding: 8bit
\r\nX-Trace: news.albasani.net wopJrPNuFTyfT99I/2XaH0juR+NpONArwU
VpUHeLrTDMkJ4WUB5QyWQFMfxX2vod7lT2wQStnCvG5tpJV6dPPA==\r\nNNTP-Po
sting-Date: Sat, 2 May 2015 13:36:34 +0000 (UTC)\r\nInjection-Inf
o: news.albasani.net; logging-data=\"U4qTVC3JDqXoind5eRv31vahmPlR
Pi7hy1tQpFTmRyyKO7IqJsaybfR4Go608Ii4tm+epkyBTI9CJv0yfOYZdBRbKa7/H
D69vZzpH0H1pQY5nFLA7EV2UcZ3pz6m2Z8M\"; mail-complaints-to=\"abuse
@albasani.net\"\r\nX-MimeOLE: Produced By Microsoft MimeOLE V6.1.
7601.17609\r\nIn-Reply-To: <67cc43c0-66d7-4467-81e8-7ad0ecad2b1a@
googlegroups.com>\r\nX-Newsreader: Microsoft Windows Mail 6.0.600
2.18197\r\nCancel-Lock: sha1:P/BCTt+FKjyFaw1+sY7Q3TGH7hY=\r\nX-Pr
iority: 3\r\nX-MSMail-Priority: Normal\r\nXref: news.szaf.org de.
rec.heimwerken:196798\r\n\r\n\"Andreas Bauer\" <***@ar
cor.de> schrieb im Newsbeitrag \r\nnews:67cc43c0-66d7-4467-81e8-7
***@googlegroups.com...\r\n\r\n> Nur innen abdichten, rec
ht das....?\r\n\r\nNein, nat\374rlich nicht, dann hast du Pfusch.
\r\n\r\nWird von Handwerkern gerne angeboten.\r\n\r\nhttp://www.s
elbst.de/bauen-renovieren-artikel/wand-boden/wand-mauern-wand-abd
ichten/feuchte-waende-abdichtmoeglichkeiten-der-uebersicht-104113
.html\r\n-- \r\nMaWin, Manfred Winterhoff, mawin at gmx dot net\r
\n\r\n\r\n.\r\n", 8191) = 1853
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
open("de/rec/heimwerken/36", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 18
writev(18, [{"Path: ", 6}, {"hetzner2.epaxios.com!", 21}, {"87.106.167.149
", 14}, {"!", 1}, {"news.szaf.org!news.albasani.net!.POSTED!not-fo
r-mail\nFrom: \"MaWin\" <***@private.net>\nNewsgroups: de.rec.heimw
erken\nSubject: Re: Wasser - undichter Keller, Ursachenforschung\n
Date: Sat, 2 May 2015 15:36:33 +0200\nOrganization: albasani.net\n
Lines: 14\nMessage-ID: <mi2jt2$88o$***@news.albasani.net>\nReference
s: <58f2fdc0-fe9b-49d9-848c-***@googlegroups.com> <slrnmk
9bmr.2379.t-***@ID-685.user.individual.de> <67cc43c0-66d7-4467-
81e8-***@googlegroups.com>\nMime-Version: 1.0\nContent-Ty
pe: text/plain;\n\tformat=flowed;\n\tcharset=\"iso-8859-1\";\n\tre
ply-type=original\nContent-Transfer-Encoding: 8bit\nX-Trace: news.
albasani.net wopJrPNuFTyfT99I/2XaH0juR+NpONArwUVpUHeLrTDMkJ4WUB5Qy
WQFMfxX2vod7lT2wQStnCvG5tpJV6dPPA==\nNNTP-Posting-Date: Sat, 2 May
2015 13:36:34 +0000 (UTC)\nInjection-Info: news.albasani.net; log
ging-data=\"U4qTVC3JDqXoind5eRv31vahmPlRPi7hy1tQpFTmRyyKO7IqJsaybf
R4Go608Ii4tm+epkyBTI9CJv0yfOYZdBRbKa7/HD69vZzpH0H1pQY5nFLA7EV2UcZ3
pz6m2Z8M\"; mail-complaints-to=\"***@albasani.net\"\nX-MimeOLE:
Produced By Microsoft MimeOLE V6.1.7601.17609\nIn-Reply-To: <67cc4
3c0-66d7-4467-81e8-***@googlegroups.com>\nX-Newsreader: M
icrosoft Windows Mail 6.0.6002.18197\nCancel-Lock: sha1:P/BCTt+FKj
yFaw1+sY7Q3TGH7hY=\nX-Priority: 3\nX-MSMail-Priority: Normal\n", 1
261}, {"Xref: hetzner2.epaxios.com de.rec.heimwerken:36\n", 48}, {
"\n", 1}, {"\"Andreas Bauer\" <***@arcor.de> schrieb im
Newsbeitrag \nnews:67cc43c0-66d7-4467-81e8-***@googlegro
ups.com...\n\n> Nur innen abdichten, recht das....?\n\nNein, nat\3
74rlich nicht, dann hast du Pfusch.\n\nWird von Handwerkern gerne
angeboten.\n\nhttp://www.selbst.de/bauen-renovieren-artikel/wand-b
oden/wand-mauern-wand-abdichten/feuchte-waende-abdi gmx dot net\n\
n\n", 370}], 8) = 1722
close(18) = 0
lseek(5, 0, SEEK_CUR) = 301288
write(5, "<mi2jt2$88o$***@news.albasani.net>\t1430573794~-~1430573793\tde.rec.heimwerken/36\n", 78) = 78
lseek(8, 408704, SEEK_SET) = 408704
read(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 120) = 120
write(8, "\351\230\4\251\0\0\0\0", 8) = 8
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(16, "de/rec/heimwerken/36\tRe: Wasser - undichter Keller, Ursachenforschung\t\"MaWin\" <***@private.net>\tSat, 2 May 2015 15:36:33 +0200\t<mi2jt2$88o$***@news.albasani.net>\t<58f2fdc0-fe9b-49d9-848c-***@googlegroups.com> <slrnmk9bmr.2379.t-***@ID-685.user.individual.de> <67cc43c0-66d7-4467-81e8-***@googlegroups.com>\t1722\t14\tXref: hetzner2.epaxios.com de.rec.heimwerken:36 \n", 381) = 381
write(15, "239 <mi2jt2$88o$***@news.albasani.net>\r\n", 38) = 38
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command d Winterhoff, mawin at gmx dot net", 92, MSG_NOSIGNAL, NULL, 0) = 92
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command .", 59, MSG_NOSIGNAL, NULL, 0) = 59
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command d Winterhofn at gmdodt t ne net et", 92, MSG_NOSIGNAL, NULL, 0) = 92
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command .", 61, MSG_NOSIGNAL, NULL, 0) = 61
select(18, [3 11 13 15], [17], NULL, {300000, 0}) = 1 (out [17], left {299999, 999992})
write(17, "/var/spool/news/de/rec/heimwerken/36\n", 37) = 37
select(16, [3 11 13 15], [], NULL, {300000, 0}) = 1 (in [15], left {299999, 992407})
read(15, "CHECK <aZ31x.229882$***@fx25.iad>\r\nCHECK <cqk09dFi1adU2
@mid.individual.net>\r\nCHECK <***@mid.individual.net>\r
@speranza.aioe.org>\r\nCHECK <mi217h$6od$***@news.albasani.net>\r\nC
<***@privat.lahls.de>\r\nCHECK <de-usenet-server-list-20
***@news.unit0.net>\r\nCHECK <***@haydn.lew
onze.de>\r\nCHECK <d9d71c7f-edc1-4ec6-9578-***@googlegrou
ps.com>\r\nCHECK <mi23bu$aod$***@news.albasani.net>\r\n", 8191) = 1189
write(15, "238 <aZ31x.229882$***@fx25.iad>\r\n", 40) = 40
write(15, "238 <***@mid.individual.net>\r\n", 40) = 40
write(15, "238 <***@mid.individual.net>\r\n", 40) = 40
write(15, "238 <mi23qm$bnp$***@news.albasani.net>\r\n", 38) = 38
write(15, "238 <5fb02578-594c-466f-987d-***@googlegroups.com>\r\n", 61) = 61
write(15, "238 <6ec20e96-9522-4e58-98e3-***@googlegroups.com>\r\n", 61) = 61
write(15, "238 <***@dclc-faq.de>\r\n", 39) = 39
write(15, "238 <de-newusers-infos/de-newsgruppen/20150501-***@msgid.krell.zikzak.de>\r\n", 73) = 73
write(15, "238 <mi1r49$afe$***@dont-email.me>\r\n", 34) = 34
write(15, "238 <ba059b2a-382f-44a4-a66d-***@googlegroups.com>\r\n", 61) = 61
write(15, "238 <BAY182-***@phx.gbl>\r\n", 51) = 51
write(15, "238 <mi2bsh$scp$***@dont-email.me>\r\n", 34) = 34
write(15, "238 <***@henning.sponbiel.de>\r\n", 39) = 39
write(15, "238 <jj5e1c-***@news.muster.net>\r\n", 38) = 38
write(15, "238 <mi295c$r1h$***@speranza.aioe.org>\r\n", 38) = 38
write(15, "238 <mi217h$6od$***@news.albasani.net>\r\n", 38) = 38
write(15, "238 <de-newusers-infos/faq/20150501-***@msgid.krell.zikzak.de>\r\n", 62) = 62
write(15, "238 <kqme1c-***@wschwanke.de>\r\n", 35) = 35
write(15, "238 <***@tipota.de>\r\n", 29) = 29
write(15, "238 <***@bavariasound.chiemgau-net.de>\r\n", 52) = 52
write(15, "438 <***@privat.lahls.de>\r\n", 36) = 36
write(15, "238 <de-usenet-server-list-***@news.unit0.net>\r\n", 53) = 53
write(15, "438 <slrnmk8$***@news.albd$***@news.aani.net>\r\n", 43) = 43
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_messageid <slrnmk8$***@news.albd$***@news.aani.net>", 97, MSG_NOSIGNAL, NULL, 0) = 97
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command $***@asani.net>", 71, MSG_NOSIGNAL, NULL, 0) = 71
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command .net>", 63, MSG_NOSIGNAL, NULL, 0) = 63
write(15, "500 Syntax error or bad command\r\n", 33) = 33
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 bad_command 23bu$aod$223bu$aod$***@nasani.netsa albasa albasa .albasan.albasa.albasa.albas...", 137, MSG_NOSIGNAL, NULL, 0) = 137
select(16, [3 11 13 15], [], NULL, {300000, 0}) = 1 (in [15], left {299999, 999994})
read(15, "", 8191) = 0
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 readclose", 55, MSG_NOSIGNAL, NULL, 0) = 55
sendto(4, "<61>May 2 15:36:34 innd: pasture.szaf.org:15 closed seconds 80 accepted 1 refused 1 rejected 0", 95, MSG_NOSIGNAL, NULL, 0) = 95
close(15) = 0
select(14, [3 11 13], [], NULL, {300000, 0}Process 8021 detached
#v-

Spannend daran ist vor allem das Pärchen read(15) und writev(18).
Man sieht sehr schön, wie der Text verstümmelt gespeichert wird.

Ebenso seltsam ist die Reaktion auf die Liste von CHECKs weiter
unten: Da werden Fragmente als ungültige Msg-Ids reklamiert, die
überhaupt nie so empfangen worden sind.

Mir fehlt jede Idee, was da vor sich gehen könnte...

Servus,
Stefan

[Julien ÉLIE]

Hi Stefan,
Looks like the version of INN 1.x you are using does not cope well with
message-IDs syntactically incorrect. They should not have two "@".
Yet, it might also be a memory corruption because "<slrnmk8$***@news.alb"
could be the beginning of a message-ID and "d$***@news.aani.net>" the end
of another message-ID...

Are you sure you want to use INN 1.7.2 instead of latest INN 2.x
versions? (2.5.4 is the latest release; 2.6.0 will soon come)

[Stefan+ (Stefan Froehlich)]

Post by Julien ÉLIE
Looks like the version of INN 1.x you are using does not cope well with

Yes, but. The wrong behaviour is quite similar with CHECK and TAKETHIS,
*and* syntactically correct msg-ids are mangled as well, so I don't think
this is the actual trigger.

Post by Julien ÉLIE
Yet, it might also be a memory corruption [...]

Unlikely. The hardware has been running for 12 months without any problems
before the re-installation last week. And there are other services on the
same hardware without any trouble - only the newsfeed is broken.

In the meantime I filed
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784115> and asked my
feed to stop streaming. Problems were gone immediately, so I really suspect
the CHECK/TAKETHIS mechanism to be broken.

Post by Julien ÉLIE
Are you sure you want to use INN 1.7.2 instead of latest INN 2.x
versions? (2.5.4 is the latest release; 2.6.0 will soon come)

The server is more or less a dummy frontend for a database; it does
hardly more than collecting a couple of feeds. I was familiar with the
old inn some years ago, so this is by far easier for me than to get
into anything completely new (yes, I did take a look at inn2 first).

Stefan

[Julien ÉLIE]

Hi Stefan,

Post by Stefan+ (Stefan Froehlich)
In the meantime I filed
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784115> and asked
my feed to stop streaming. Problems were gone immediately, so I
really suspect the CHECK/TAKETHIS mechanism to be broken.

Thanks for your answer; you're right that it does not seem to be related
to invalid message-IDs or memory corruption.

It is strange that this bug in streaming mode is only uncovered now.
Probably linked to the new Debian release... I hope Marco will find
where the bug comes from.