Was tun mit falsch codierten Artikeln (was: Ähm...)

[Michael Baeuerle]

Mir kommt es auf den Unterschied "sieht kaputt aus" zu "ist kaputt
codiert" an (jeweils auf den Servern).

Das hätte schon vor Jahren passieren müssen! Beispielsweise sollten
unkodierte 8-Bit Zeichen in Headern vom Server (mit entsprechender
Nachricht an den Sender) einfach abgewiesen werden.
Dieses allein schon hätte und würde für viel mehr Ruhe sorgen.

Ich würde das zumindest für de.ALL unterstützen. Dadurch würde sofort
auffallen wenn ein Client Mist baut und der User könnte was dagegen
unternehmen (und sei es nur, dass er "ä" in "ae" ändert, ein anderes
Programm installieren ist ja gar nicht nötig).

Das wäre auch völlig standardkonform. Zitat aus RFC5537, Kapitel 3.1:
|
| No Netnews agent is ever required to accept any article. It is
| common for injecting, relaying, and serving agents to reject well-
| formed articles for reasons of local policy [...]

Leider hinkt man im Ausland mit MIME noch sehr hinterher, in russischen
Gruppen sieht man z.B. oft KOI8-R im Klartext (Beispiel: relcom.talk,
meistens auch von den üblichen verdächtigen Programmen verbrochen).
Da einfach die Tür zu machen und diese User quasi alle auschließen wäre
schon ein inakzeptabler Kollateralschaden. Dort kann man vieles ja
nicht einfach wie in der deutschen Sprache auf ASCII umschreiben.

Diese Problematik wird also wohl noch Jahrzehnte erhalten bleiben.
Oder sogar für alle Zeiten. Wenn man sich die brandneuen (aber in dieser
Beziehung grottenschlechten) Clients für Mobilgeräte sowie den Abwärts-
trend bei Google anschaut geht es da momentan eher rückwärts ...

[Xpost & Fup2 nach de.comm.software.newsserver]


Micha

[Wolfgang Bauer]

Post by Michael Baeuerle

Das hätte schon vor Jahren passieren müssen! Beispielsweise sollten
unkodierte 8-Bit Zeichen in Headern vom Server (mit entsprechender
Nachricht an den Sender) einfach abgewiesen werden.
Dieses allein schon hätte und würde für viel mehr Ruhe sorgen.

Ich würde das zumindest für de.ALL unterstützen. Dadurch würde sofort
auffallen wenn ein Client Mist baut und der User könnte was dagegen
unternehmen (und sei es nur, dass er "ä" in "ae" ändert, ein anderes
Programm installieren ist ja gar nicht nötig).

Das ließe sich in Dialog verwirklichen indem man da den
Standardzeichensatz auf us-ascii stellt. Das hat Jürgen Schmadlak schon
vor Jahren dazu empfohlen.

Wolfgang

[Peter Faust]

Klasse Idee. W?rde ich das machen, s?hen meine Texte uns?glich Schei?e aus.
Vom zitierten Text, zumal dort ja ebenfalls Umlaute vorkommen k?nnten, mal
ganz abgesehen. N?, das ist eine selten bl?de Idee mit dem ASCII, da ich in
der Schule m?hselig dem Ges?lze des Lehrers ?ber Umlaute folgen musste.

Wieso ASCII?

Die Forderung in Headern nichts außer ASCII zuzulassen habe ich schon sehr
oft gelesen - zumeist von Nutzern in dieser Richtung defekter NUAs ...

Jeder soll verwenden was er meint, dass nötig sei. Ab-
gewiesen werden sollen lediglich *kaputte* Postings, also solche wo
man den Zeichensatz raten muss weil er nicht deklariert *und* nicht
ASCII ist.

Schon klar. Aber wo soll man da ansetzen dies umzusetzen?
Ich denke da nur an peering, wo jeder beteiligte Server sein eigenes Süpp-
chen kocht.

Ein Fragezeichen würde nicht entstehen, denn der Artikel müsste als
Ganzes abgewiesen werden. RFC5537 verbietet einem Server ihn zu
reparieren.

Tja. Da isses schon das Problem: Nicht jeder Server hält sich an RFCs.

Nee, solange Uneinigkeit unter peerenden Newsservern herrscht, wird sich an
dem IST-Zustand nur auf lokaler und/oder persönlichen Ebene etwas ändern.
Sprich: Hinweise auf kaputte Artikel/NUAs - händische Reparaturen - Plonk.

Gruß, Peter

P.S.: Ich habe mal in dein Subjekt gewechselt und leite ebenfalls um.

X-Post nach <news:de.test> und <news:de.comm.software.newsserver>, Followup-To: <news:de.comm.software.newsserver>

[Thomas Barghahn]

[...]

Post by Peter Faust

Jeder soll verwenden was er meint, dass nötig sei. Ab-
gewiesen werden sollen lediglich *kaputte* Postings, also solche wo
man den Zeichensatz raten muss weil er nicht deklariert *und* nicht
ASCII ist.

Schon klar. Aber wo soll man da ansetzen dies umzusetzen?

Deshalb schrieb ich ja auch schon viel weiter oben:
| Das hätte schon vor Jahren passieren müssen!

[...]

Post by Peter Faust

Ein Fragezeichen würde nicht entstehen, denn der Artikel müsste als
Ganzes abgewiesen werden. RFC5537 verbietet einem Server ihn zu
reparieren.

Tja. Da isses schon das Problem: Nicht jeder Server hält sich an RFCs.

Tja. Es ist schon amüsant - kommt in DE eine neue Mehrwertsteuer, dann
zahlen plötzlich *alle* ... und *keiner* der Betroffenen geht auf die
Straße.

Schlimm(!) - ganz schlimm.

Freundliche Grüße
Thomas Barghahn

[Michael Baeuerle]

Post by Peter Faust

Klasse Idee. W?rde ich das machen, s?hen meine Texte uns?glich Schei?e aus.
Vom zitierten Text, zumal dort ja ebenfalls Umlaute vorkommen k?nnten, mal
ganz abgesehen. N?, das ist eine selten bl?de Idee mit dem ASCII, da ich in
der Schule m?hselig dem Ges?lze des Lehrers ?ber Umlaute folgen musste.

Wieso ASCII?

Die Forderung in Headern nichts außer ASCII zuzulassen habe ich schon sehr
oft gelesen - zumeist von Nutzern in dieser Richtung defekter NUAs ...

Im Endeffekt funktioniert ja auch tatsächlich nur ASCII. Mit den MIME
encoded words kann man aber trotzdem auch beliebige Sonderzeichen
darstellen obwohl man nur ASCII Zeichen sendet.

Post by Peter Faust

Jeder soll verwenden was er meint, dass nötig sei. Ab-
gewiesen werden sollen lediglich *kaputte* Postings, also solche wo
man den Zeichensatz raten muss weil er nicht deklariert *und* nicht
ASCII ist.

Schon klar. Aber wo soll man da ansetzen dies umzusetzen?

Gleich bei der Injection, also am 1. Server.

Post by Peter Faust
Ich denke da nur an peering, wo jeder beteiligte Server sein eigenes Süpp-
chen kocht.

Später noch zensieren finde ich keine gute Idee. In RFC5537 ist das ja
auch so spezifiziert mit der Begründung, dass nur bei der Injection eine
Fehlermeldung an denjenigen erzeugt werden kann der das Problem
verursacht hat.

Post by Peter Faust

Ein Fragezeichen würde nicht entstehen, denn der Artikel müsste als
Ganzes abgewiesen werden. RFC5537 verbietet einem Server ihn zu
reparieren.

Tja. Da isses schon das Problem: Nicht jeder Server hält sich an RFCs.
Nee, solange Uneinigkeit unter peerenden Newsservern herrscht, wird sich an
dem IST-Zustand nur auf lokaler und/oder persönlichen Ebene etwas ändern.
Sprich: Hinweise auf kaputte Artikel/NUAs - händische Reparaturen - Plonk.

Das ist state-of-the-art, der ist aber verbesserungsfähig.


Micha

[Oliver Cromm]

Post by Michael Baeuerle

Post by Peter Faust
Schon klar. Aber wo soll man da ansetzen dies umzusetzen?

Gleich bei der Injection, also am 1. Server.

Wenn das aber nur für de.* geschehen soll, wird man das auch
bestenfalls bei Servern im deutschsprachigen Raum verwirklichen
können (also z.B. nicht bei meinem). Gut, mit den größten 5 wäre
auch schon viel gewonnen, aber der eine oder andere würde als
Reaktion auf ein abgewiesenes Posting wohl doch auf einen
ausländischen Server umsteigen (zum Beispiel einen gewissen
italienischen, bei dem Hopfen und Malz verloren ist).

[Michael Baeuerle]

Post by Oliver Cromm

Post by Michael Baeuerle

Post by Peter Faust
Schon klar. Aber wo soll man da ansetzen dies umzusetzen?

Gleich bei der Injection, also am 1. Server.

Wenn das aber nur für de.* geschehen soll, wird man das auch
bestenfalls bei Servern im deutschsprachigen Raum verwirklichen
können (also z.B. nicht bei meinem). Gut, mit den größten 5 wäre
auch schon viel gewonnen,

Sehe ich auch so.

Post by Oliver Cromm
aber der eine oder andere würde als
Reaktion auf ein abgewiesenes Posting wohl doch auf einen
ausländischen Server umsteigen (zum Beispiel einen gewissen
italienischen, bei dem Hopfen und Malz verloren ist).

Man müsste da ja nicht überpingelig sein. Schritt 1 wäre einfach zu
überprüfen ob bei allen Bytes im Subject das achte Bit 0 ist. Falls nein
=> Abweisen.

Das würde die ganze Zeichensatzraterei erschlagen und es bliebe nur noch
die MIME-Problematik übrig. Aber MIME zu prüfen kommt eigentlich sowieso
nicht in Frage, weil das sehr kompliziert und quasi nirgends wirklich
korrekt implementiert ist.


Micha

[Paul Muster]

Post by Michael Baeuerle

Das hätte schon vor Jahren passieren müssen! Beispielsweise sollten
unkodierte 8-Bit Zeichen in Headern vom Server (mit entsprechender
Nachricht an den Sender) einfach abgewiesen werden.
Dieses allein schon hätte und würde für viel mehr Ruhe sorgen.

Ich würde das zumindest für de.ALL unterstützen. Dadurch würde sofort
auffallen wenn ein Client Mist baut und der User könnte was dagegen
unternehmen (und sei es nur, dass er "ä" in "ae" ändert, ein anderes
Programm installieren ist ja gar nicht nötig).
Leider hinkt man im Ausland mit MIME noch sehr hinterher, in russischen
Gruppen sieht man z.B. oft KOI8-R im Klartext (Beispiel: relcom.talk,
meistens auch von den üblichen verdächtigen Programmen verbrochen).
Da einfach die Tür zu machen und diese User quasi alle auschließen wäre
schon ein inakzeptabler Kollateralschaden. Dort kann man vieles ja
nicht einfach wie in der deutschen Sprache auf ASCII umschreiben.

Wenn sich erstmal jeder Serverbetreiber darum kümmert, dass _seine
eigenen User_ keinen Schrott einspeisen, wäre schon einiges gewonnen.
Inbound _auf den Peerings_ zu filtern ist eine wesentlich gravierendere
Maßnahme, das muss man nicht (gleich) tun.


mfG Paul