HTTP POST: Input begrenzen?

[Marcel Logen]

Gegeben sei ein Formular, das mit der POST-Methode arbeitet,
und ein input-Element:

<input type="text" [...] name="trallala" size="4" maxlength="2">

Damit kann man hier (im Browser) nur zwei Zeichen eingeben.

Allerdings wäre es IMHO unter Umgehung des Browsers möglich,
mit der POST-Methode beliebig viel Text an den Server zu sen-
den.

Kann man das (mit PHP?) unterbinden?

Man kann/muß natürlich $_POST['trallala'] per Regexp checken,
z. B. auf "^[0-9]{1,2}$", und dann weiterverarbeiten. Aber
dafür würde zunächst doch trotzdem die gesamte (evtl. über-
große) Datenmenge zum Server übertragen.

Gibt es dafür eine Lösung? Oder begrenzen die Server die
eingehende Datenmenge sowieso?

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

[Ulli Horlacher]

Marcel Logen <33320000...@ybtra.de> wrote:

> Man kann/muß natürlich $_POST['trallala'] per Regexp checken,
> z. B. auf "^[0-9]{1,2}$", und dann weiterverarbeiten. Aber
> dafür würde zunächst doch trotzdem die gesamte (evtl. über-
> große) Datenmenge zum Server übertragen.
>
> Gibt es dafür eine Lösung? Oder begrenzen die Server die
> eingehende Datenmenge sowieso?

Ich hatte vor 12 Jahren ein aehnliches Problem:
Ich wollte mehr als 2 GB POSTen.
Damals konnte kein mir bekannter Webserver das verarbeiten.
Die hatten alle einen signed int32 bug, den schon der Urvater aller
Webserver, der NCSA httpd, hatte. Alle anderen haben wohl davon
abgeschrieben ohne nachzudenken.

Ich hab dann etwas nachgeforscht: ein typischer Webserver nimmt erstmal
den gesammten http post request an und gibt ihn dann an das CGI Programm
weiter. Erst das limitiert die Groesse. Uebertragen sind die Daten dann
aber laengst.

Eventuell kann das ein moderner Webserver besser machen.

Ich hatte vor 12 Jahren dann aus Notwehr einen eigenen Webserver
geschrieben, der mit beliebig grossen POSTs zurecht kommt.
Auch 2 PB sind damit kein Problem mehr :-)


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Stefan Froehlich]

On Sat, 21 Mar 2020 21:43:43 Marcel Logen wrote:
> Man kann/muß natürlich $_POST['trallala'] per Regexp checken, z.
> B. auf "^[0-9]{1,2}$", und dann weiterverarbeiten. Aber dafür
> würde zunächst doch trotzdem die gesamte (evtl. über- große)
> Datenmenge zum Server übertragen.

Ja; im Regelfall ist das aber kein größeres Problem; wenn jemand aus
Jux und Tollerei (oder auch in böser Absicht) Deinen Server mit
nicht weiterverarbeiteten Daten bewerfen möchte, dann könnte er das
ebenso auch über viele kleine Requests machen.

> Gibt es dafür eine Lösung? Oder begrenzen die Server die
> eingehende Datenmenge sowieso?

PHP bietet Dir in der Konfiguration ein paar Möglichkeiten zur
Begrenzung, Du kannst aber auch ganz basisnah den Webserver
entsprechend konfigurieren, beim Apache z.B. mit LimitRequestBody.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Versuchung in Hülle und Fülle: Stefan!
(Sloganizer)

[Marcel Mueller]

Am 21.03.20 um 21:43 schrieb Marcel Logen:

> Gegeben sei ein Formular, das mit der POST-Methode arbeitet,
> und ein input-Element:
>
> <input type="text" [...] name="trallala" size="4" maxlength="2">
>
> Damit kann man hier (im Browser) nur zwei Zeichen eingeben.
>
> Allerdings wäre es IMHO unter Umgehung des Browsers möglich,
> mit der POST-Methode beliebig viel Text an den Server zu sen-
> den.

Das geht immer.

> Kann man das (mit PHP?) unterbinden?

Da ist es schon zu spät. Das muss der Webserver machen.
In PHP kannst Du nur prüfen, ob die die Länge der Daten gefällt.

> Man kann/muß natürlich $_POST['trallala'] per Regexp checken,
> z. B. auf "^[0-9]{1,2}$", und dann weiterverarbeiten. Aber
> dafür würde zunächst doch trotzdem die gesamte (evtl. über-
> große) Datenmenge zum Server übertragen.

Exakt. Sowohl die Datenmenge als auch der ggf. belegte Speicher können
den Server beeinträchtigen. Wobei für DOS-Attacken die Sache mit dem
Speicher besser geeignet ist, denn das Netzwerk bekommt man mit einem
einzelnen Stream üblicherweise nicht platt, und für DDOS braucht man
keine großen Datenmengen pro Request.

> Gibt es dafür eine Lösung? Oder begrenzen die Server die
> eingehende Datenmenge sowieso?

Die meisten Server haben derlei Begrenzungen. Ausnahme sind
üblicherweise File-Uploads.


Marcel

[Arno Welzel]

Marcel Logen:

> Gegeben sei ein Formular, das mit der POST-Methode arbeitet,
> und ein input-Element:
>
> <input type="text" [...] name="trallala" size="4" maxlength="2">
>
> Damit kann man hier (im Browser) nur zwei Zeichen eingeben.
>
> Allerdings wäre es IMHO unter Umgehung des Browsers möglich,
> mit der POST-Methode beliebig viel Text an den Server zu sen-
> den.
>
> Kann man das (mit PHP?) unterbinden?

Nicht nur *kann* sondern man *muss* es auch tun, gerade weil man per
HTTP beliebigen Müll schicken kann.

> Man kann/muß natürlich $_POST['trallala'] per Regexp checken,
> z. B. auf "^[0-9]{1,2}$", und dann weiterverarbeiten. Aber
> dafür würde zunächst doch trotzdem die gesamte (evtl. über-
> große) Datenmenge zum Server übertragen.

Bei Apache kann das begrenzen:

<http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody>

> Gibt es dafür eine Lösung? Oder begrenzen die Server die
> eingehende Datenmenge sowieso?

Auch PHP kann die Datenmenge begrenzen, die es verarbeitet.

Siehe post_max_size in
<https://www.php.net/manual/de/ini.core.php#ini.post-max-size>.

Und dann gäbe es auch noch Grenzen für Speicherbelegung, Ausführungszeit
usw..


--
Arno Welzel
https://arnowelzel.de

[Marcel Logen]

Marcel Logen in de.comm.infosystems.www.authoring.misc:

>Gibt es dafür eine Lösung?

Dank an Euch alle für die erhellenden Antworten.

Ich werde mal mit phpinfo() nachsehen, was mein Provider da
standardmäßig so voreingestellt hat. Und was sich daran 'dre-
hen' läßt.

Gibt es eine ähnliche Funktion (wie phpinfo()) auch für den
Apache? Also in dem Sinne, daß man sich in einem directory
befindet und sich dann die dort (z. B. durch httpd.conf bis
hinunter zu den .htaccess-Dateien) aktuell eingestellten und
gültigen Werte anzeigen lassen kann?

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

[Arno Welzel]

Marcel Logen:

[...]

> Gibt es eine ähnliche Funktion (wie phpinfo()) auch für den
> Apache? Also in dem Sinne, daß man sich in einem directory
> befindet und sich dann die dort (z. B. durch httpd.conf bis
> hinunter zu den .htaccess-Dateien) aktuell eingestellten und
> gültigen Werte anzeigen lassen kann?

Theoretisch ja, praktisch wird das aber kein Serverbetreiber direkt
aufrufbar konfigurieren, weil man das sicher nicht öffentlich aufrufbar
haben will:

<https://httpd.apache.org/docs/2.4/mod/mod_info.html>

[Marcel Logen]

Arno Welzel in de.comm.infosystems.www.authoring.misc:

>Marcel Logen:

>> Gibt es eine ähnliche Funktion (wie phpinfo()) auch für den
>> Apache? Also in dem Sinne, daß man sich in einem directory
>> befindet und sich dann die dort (z. B. durch httpd.conf bis
>> hinunter zu den .htaccess-Dateien) aktuell eingestellten und
>> gültigen Werte anzeigen lassen kann?
>
>Theoretisch ja, praktisch wird das aber kein Serverbetreiber direkt
>aufrufbar konfigurieren, weil man das sicher nicht öffentlich aufrufbar
>haben will:
>
><https://httpd.apache.org/docs/2.4/mod/mod_info.html>

Danke für den Hinweis!

Ich überlege, ob es sicher genug wäre, wenn man als URL
so etwas wie

<http://your.host.example.com/8dd44909aaf8bb8e56bb16270da1e82ac30733ec4284ab4b34047170f6bed22a2d86543f5a2dfbb9d227>

nähme (z. B. erzeugt mit "openssl rand 42 -hex") ...

Also:

| <Location "/8dd44909aaf8bb8e56bb16270da1e82ac30733ec4284ab4b34047170f6bed22a2d86543f5a2dfbb9d227">
| SetHandler server-info
| </Location>

Oder wäre dann das HTTP (ohne "S") noch ein Sicherheits-
problem? Wäre es mit HTTPS einigermaßen OK?

Ähnlich für eine Seite mit phpinfo().

Marcel

Fup2 Webserver-Gruppe?
--
╭─────╮ ╭─────╮ ╭──────────────╮ ╭───╮ ╭─╮ ╭─────╮
╭─╮ │ ╭──╯ ╭─╯ ╭──╯ ╰─╮ ╭──╯ ╰─╮ ╰─╯ ╰──╯ │
│ ╰─╯ ╰──╮ │ ╰─╮ ╰────╮ ╰────╮ ╰──╮ ╭──╯ ╭───╮
╯ ╰─╯ ╰──────────╯ ╰────────╯ ╰──────╯ ╰─╮

[Arno Welzel]

Marcel Logen:

> Arno Welzel in de.comm.infosystems.www.authoring.misc:
[...]

>> <https://httpd.apache.org/docs/2.4/mod/mod_info.html>
>
> Danke für den Hinweis!
>
> Ich überlege, ob es sicher genug wäre, wenn man als URL
> so etwas wie
>
> <http://your.host.example.com/8dd44909aaf8bb8e56bb16270da1e82ac30733ec4284ab4b34047170f6bed22a2d86543f5a2dfbb9d227>
>
> nähme (z. B. erzeugt mit "openssl rand 42 -hex") ...
>
> Also:
>
> | <Location "/8dd44909aaf8bb8e56bb16270da1e82ac30733ec4284ab4b34047170f6bed22a2d86543f5a2dfbb9d227">
> | SetHandler server-info
> | </Location>
>
> Oder wäre dann das HTTP (ohne "S") noch ein Sicherheits-
> problem? Wäre es mit HTTPS einigermaßen OK?

https wäre sicher sinnvoll und eine so generierte URL ist dann auch
nicht wesentlich unsicherer als der Schutz mit Benutzername/Passwort.
Mir ist zumindest kein sinnvoll machbarer Weg bekannt, wie man ohne
Kenntnis der URL herausfinden kann, ob es die URL überhaupt gibt.

[sandeep kashyap]

a great feature of the program is, as the name suggests, a built-in picture finder. Just enter the keyword and the program will find and download thousands of pictures for you. It has different search modes allowing you to vary the level of your interaction with the download process

https://downloader.is

[Claus Reibenstein]

Du bist in einer deutschsprachigen Gruppe gelandet. Dort wird deutsch
gesprochen.

sandeep kashyap schrieb am 17.03.2022 um 20:48 in
de.comm.infosystems.www.authoring.misc:

[Claus Reibenstein]

Du bist in einer deutschsprachigen Gruppe gelandet. Hier wird deutsch

gesprochen.

sandeep kashyap schrieb am 17.03.2022 um 20:48 in
de.comm.infosystems.www.authoring.misc:

[Michael Landenberger]

"Claus Reibenstein" schrieb am 18.03.2022 um 20:34:03:

> Du bist in einer deutschsprachigen Gruppe gelandet. Dort wird deutsch
> gesprochen.

Und wie es sich in einer deutschsprachigen Gruppe gehört, werden Spammer auch
auf deutsch gefüttert.

SCNR

Michael

[Claus Reibenstein]

Michael Landenberger schrieb am 19.03.2022 um 09:41:

> "Claus Reibenstein" schrieb am 18.03.2022 um 20:34:03:
>
>> Du bist in einer deutschsprachigen Gruppe gelandet.

Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,
nachdem ich gemerkt hatte, dass es versehentlich in der Gruppe statt in
der Mail gelandet war.

> Und wie es sich in einer deutschsprachigen Gruppe gehört, werden Spammer auch
> auf deutsch gefüttert.

War nicht meine Absicht.

Gruß
Claus

[Michael Landenberger]

"Claus Reibenstein" schrieb am 19.03.2022 um 14:46:08:

> Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,
> nachdem ich gemerkt hatte, dass es versehentlich in der Gruppe statt in
> der Mail gelandet war.

Das Netz vergisst nie ;-)

Manche Newsserver unterstützen Cancel-Befehle nicht. Offenbar gehört der von
mir verwendete dazu, denn der hat deinen Cancel-Befehl ignoriert und
infolgedessen war dein Posting noch da.

Immerhin weiß ich jetzt, dass es keine Absicht war. Spammer-Fütterungen kenne
ich von dir sonst auch gar nicht.

Dass eine E-Mail in einer Newsgroup landet, ist übrigens ein typisches
Thunderbird-Problem. Wann immer das passiert, ist Thunderbird der verwendete
Mail-/Newsclient, und das eigentlich schon seit über einem Jahrzehnt.

Es erstaunt mich, dass es die Mozilla-Entwickler immer noch nicht hinbekommen
haben, das User-Interface von Thunderbird so zu gestalten, dass dieser Fehler
nicht passieren *kann*. Sogar mein selbst zusammengefrickelter
Mail-/Newsclient macht es besser: wer eine E-Mail verschicken will, muss dazu
einen speziellen E-Mail-Editor benutzen. Der aber kann Beiträge nur per SMTP
verschicken, also als E-Mail. Dagegen ist der E-Mail-Editor gar nicht in der
Lage, mit NNTP-Servern zu kommunizieren. Es ist also ausgeschlossen, mit
diesem Editor einen Newsbeitrag zu posten.

Umgekehrt braucht man zum Verfassen von Newsbeiträgen einen News-Editor, der
wiederum keine SMTP-Verbindungen aufbauen kann. Gleichzeitig akzeptiert er
auch keine E-Mail-Adressen im Empfänger-Feld. Aber selbst wenn er sie
akzeptieren würde, würde er den Eintrag im Empfänger-Feld nicht in den
"To:"-Header schreiben, sondern in den "Newsgroups"-Header. Ein SMTP-Server
kann damit nichts anfangen und würde die "Mail" (die ja eigentlich ein
Newsbeitrag ist) nicht verschicken.

Die beiden Editoren sind auch ziemlich verwechslungssicher gestaltet. Zum
einen unterscheiden sich die Symbole zum Öffnen dieser Editoren deutlich (das
Symbol für den Mail-Editor ist ein '@', das für den News-Editor ein 'N'). Und
zum anderen gibt es unübersehbare Unterschiede bei den Eingabefeldern für
Konten und Empfänger. Der Mail-Editor bietet nur Mail-(SMTP-)Accounts zum
Versand an, die dazu vorgesehene Liste ist mit "Von:" beschriftet. Das
Empfänger-Feld des Mail-Editors ist mit "An:" beschriftet und akzeptiert nur
Mailadressen.

Im News-Editor wiederum kann man nur News-(NNTP-)Accounts zum Versand
auswählen, die Konten-Liste ist mit "Newskonto:" beschriftet. Das Eingabefeld
des News-Editors ist mit "Newsgroups:" beschriftet und man kann dort nur
Newsgroup-Namen eintragen. E-Mail-Adressen werden im News-Editor wegen des
enthaltenen '@' nicht akzeptiert. Es ist also schon deswegen nicht möglich,
eine E-Mail versehentlich als News-Beitrag zu posten.

Also alles ganz easy, nur bei Mozilla tut man sich damit schwer.

Gruß

Michael

[Thomas Hochstein]

Michael Landenberger schrieb:

> Manche Newsserver unterstützen Cancel-Befehle nicht. Offenbar gehört der von
> mir verwendete dazu, denn der hat deinen Cancel-Befehl ignoriert und
> infolgedessen war dein Posting noch da.

Ich habe Zweifel, ob ein Cancel propagiert wurde. Mein Newsserver hat
nämlich, AFAIS, keinen bekommen. (Und news.individual.de setzt sowohl
Cancel-Lock als auch, bei einem Cancel von denselbem Account, Cancel-Key
passend; solche Cancel würde sowohl bei mir als auch bei Deinem Newsserver
ausgeführt.)

[Stefan Froehlich]

On Sat, 19 Mar 2022 17:18:20 Michael Landenberger wrote:
> "Claus Reibenstein" schrieb am 19.03.2022 um 14:46:08:
>> Wieso ist das Posting noch vorhanden? Das hatte ich doch
>> gelöscht, nachdem ich gemerkt hatte, dass es versehentlich in der
>> Gruppe statt in der Mail gelandet war.

> Das Netz vergisst nie ;-)

> Manche Newsserver unterstützen Cancel-Befehle nicht. Offenbar
> gehört der von mir verwendete dazu, denn der hat deinen
> Cancel-Befehl ignoriert und infolgedessen war dein Posting noch
> da.

Ich lese dort, wo Claus gepostet hat, bei der FU-Berlin, und auch
dort ist der Artikel noch sichtbar. Dort klappt das Löschen idR
reibungslos, eventuell ist also auf Claus' Seite schon etwas falsch
gelaufen.

> Es erstaunt mich, dass es die Mozilla-Entwickler immer noch nicht
> hinbekommen haben, das User-Interface von Thunderbird so zu
> gestalten, dass dieser Fehler nicht passieren *kann*. Sogar mein
> selbst zusammengefrickelter Mail-/Newsclient macht es besser: wer
> eine E-Mail verschicken will, muss dazu einen speziellen
> E-Mail-Editor benutzen. Der aber kann Beiträge nur per SMTP

> verschicken, [...] Umgekehrt braucht man zum Verfassen von

> Newsbeiträgen einen News-Editor, der wiederum keine
> SMTP-Verbindungen aufbauen kann.

Und das hilft? Ich möchte in meinem Newsreader in der Lage zu sein,
per Posting oder per Email zu reagieren, je nachdem, was gerade
passend erscheint. Verwende ich dafür unterschiedliche Editoren,
dann hat das den großen Nachteil, auf eine einheitliche Umgebung
verzichten zu müssen - verhindert aber immer noch nicht, dass ich
versehentlich meine Antwort mit dem falschen Editor schreibe und
diesen Fehler zu spät bemerke.

(Tatsächlich hat mein Newsreader gar keinen eigenen Editor, sondern
greift sowohl für News als auch für Mail auf den Systemeditor
zurück, was sowieso die bestmögliche Variante ist).

> Die beiden Editoren sind auch ziemlich verwechslungssicher
> gestaltet. Zum einen unterscheiden sich die Symbole zum Öffnen
> dieser Editoren deutlich (das Symbol für den Mail-Editor ist ein
> '@', das für den News-Editor ein 'N').

Nun denn, die Aufrufe erfolgen hier durch "r" (reply per mail) oder
"f" (follow-up), und nach dem Schreiben muss man einmal "w" zum
Posten oder "s" zum Mailen drücken. Das ist schon sehr verschieden;
hilft aber ggf. alles nichts, weil man diese Vorgänge sehr schnell
im Muskelgedächtnis hat.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan! Da steckt mehr drin, als man sich wünscht.
(Sloganizer)

[Michael Landenberger]

"Stefan Froehlich" schrieb am 19.03.2022 um 22:16:53:

> On Sat, 19 Mar 2022 17:18:20 Michael Landenberger wrote:

>> Es erstaunt mich, dass es die Mozilla-Entwickler immer noch nicht
>> hinbekommen haben, das User-Interface von Thunderbird so zu
>> gestalten, dass dieser Fehler nicht passieren *kann*. Sogar mein
>> selbst zusammengefrickelter Mail-/Newsclient macht es besser: wer
>> eine E-Mail verschicken will, muss dazu einen speziellen
>> E-Mail-Editor benutzen. Der aber kann Beiträge nur per SMTP
>> verschicken, [...] Umgekehrt braucht man zum Verfassen von
>> Newsbeiträgen einen News-Editor, der wiederum keine
>> SMTP-Verbindungen aufbauen kann.

> Und das hilft?

Natürlich.

> Ich möchte in meinem Newsreader in der Lage zu sein,
> per Posting oder per Email zu reagieren, je nachdem, was gerade
> passend erscheint.

Ist doch kein Problem: möchtest du per Posting reagieren, öffnest du den
News-Editor. Möchtest du per E-Mail reagieren, öffnest du den E-Mail-Editor.
Das geht selbstverständlich immer, allerdings sind die Wege dahin zumindest
bei meinem Client so deutlich unterschiedlich gekennzeichnet, dass es
eigentlich nicht passieren kann, dass man versehentlich den falschen Editor
nimmt.

> Verwende ich dafür unterschiedliche Editoren,
> dann hat das den großen Nachteil, auf eine einheitliche Umgebung
> verzichten zu müssen - verhindert aber immer noch nicht, dass ich
> versehentlich meine Antwort mit dem falschen Editor schreibe und
> diesen Fehler zu spät bemerke.

So unterschiedlich sind die Editoren dann auch wieder nicht. Man findet sich
in beiden sofort zurecht. Und falls man doch mal einen Fehler machen sollte
(kann ja passieren), bemerkt man den rechtzeitig und nicht erst, wenn es zu
spät ist. Schlimmstenfalls wird man mit der Nase darauf gestoßen, wenn man im
E-Mail-Editor eine Newsgroup oder im News-Editor eine Mailadresse ins
Empfängerfeld eingetragen hat.

Gruß

Michael

[Arno Welzel]

Claus Reibenstein:

> Michael Landenberger schrieb am 19.03.2022 um 09:41:
>
>> "Claus Reibenstein" schrieb am 18.03.2022 um 20:34:03:
>>
>>> Du bist in einer deutschsprachigen Gruppe gelandet.
>
> Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,

Weil Canceln von Postings wegen massivem Misbrauchs dieser Funktion in
der Vergangenehit in der Regel nicht funktioniert.

[Thomas Hochstein]

Arno Welzel schrieb:

> Claus Reibenstein:

> > Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,
>
> Weil Canceln von Postings wegen massivem Misbrauchs dieser Funktion in
> der Vergangenehit in der Regel nicht funktioniert.

Das ist sowohl allgemein als auch insbesondere im speziellen Fall
unzutreffend.

[Claus Reibenstein]

Michael Landenberger schrieb am 19.03.2022 um 17:18:

> "Claus Reibenstein" schrieb am 19.03.2022 um 14:46:08:
>
>> Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,
>> nachdem ich gemerkt hatte, dass es versehentlich in der Gruppe statt in
>> der Mail gelandet war.
>
> Das Netz vergisst nie ;-)

Das Netz ist diesmal unschuldig :-)

> Manche Newsserver unterstützen Cancel-Befehle nicht. Offenbar gehört der von
> mir verwendete dazu, denn der hat deinen Cancel-Befehl ignoriert und
> infolgedessen war dein Posting noch da.

Es gab gar keinen Cancel-Befehl. Ich hatte "Nachricht löschen" statt
"Nachricht annullieren" ausgewählt, was die Nachricht nur lokal
entfernt. Inzwischen habe ich das korrigiert, so dass nun auch auf
Deinem Server mein Posting verschwunden sein sollte.

> Dass eine E-Mail in einer Newsgroup landet, ist übrigens ein typisches
> Thunderbird-Problem. Wann immer das passiert, ist Thunderbird der verwendete
> Mail-/Newsclient, und das eigentlich schon seit über einem Jahrzehnt.

Ich verwende aber gar kein Thunderbird, sondern SeaMonkey.

> Es erstaunt mich, dass es die Mozilla-Entwickler immer noch nicht hinbekommen
> haben, das User-Interface von Thunderbird so zu gestalten, dass dieser Fehler
> nicht passieren *kann*. Sogar mein selbst zusammengefrickelter
> Mail-/Newsclient macht es besser: wer eine E-Mail verschicken will, muss dazu

> einen speziellen E-Mail-Editor benutzen. [...]

>
> Umgekehrt braucht man zum Verfassen von Newsbeiträgen einen News-Editor, der

> wiederum keine SMTP-Verbindungen aufbauen kann. [...]

Und das soll besser sein? Ich finde das eher sehr umständlich und noch
dazu überflüssig.

Wenn ich auf ein Usenet-Posting antworte, landet die Antwort i.d.R. in
der Gruppe. Will ich dem Absender antworten, wähle ich "Antwort nur an
Absender". Das ist der einzige Punkt, wo ich mich vertun kann, und genau
dieses Problem löst Du mit Deinen zwei getrennten Editoren in keinster
Weise.

> Also alles ganz easy, nur bei Mozilla tut man sich damit schwer.

Das Problem ist nicht Mozilla, sondern die Anwender, die ihre
Anwendung(en) nicht im Griff haben.

Gruß
Claus

[Stefan Froehlich]

On Sun, 20 Mar 2022 13:04:37 Claus Reibenstein wrote:
> [...], so dass nun auch auf Deinem Server mein Posting
> verschwunden sein sollte.

Sorry, but no.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Freude mit dem Segen der Schwiegermutter!
(Sloganizer)

[Michael Landenberger]

"Claus Reibenstein" schrieb am 20.03.2022 um 13:04:37:

> Wenn ich auf ein Usenet-Posting antworte, landet die Antwort i.d.R. in
> der Gruppe.

Bei mir natürlich auch. Allerdings wird, wenn ich in die Gruppe antworten
möchte, automatisch der News-Editor geöffnet. Mit dem kann ich nur
Newsbeiträge posten, keine E-Mails verschicken. Es geht einfach nicht.

> Will ich dem Absender antworten, wähle ich "Antwort nur an
> Absender". Das ist der einzige Punkt, wo ich mich vertun kann,

Ich kann mich halt aus mehreren Gründen nicht vertun. Zum einen ist das Icon
für "Antwort nur an Absender" ganz klar durch das '@' erkennbar, d. h. wenn
man da draufklickt, öffnet man in jedem Fall einen E-Mail-Editor. Und egal ob
man da absichtlich oder versehentlich draufgeklickt hat: der E-Mail-Editor
kann keine Newsbeiträge posten. No way. Man hat keine Chance, einen Text, der
als E-Mail-Antwort an den Absender gedacht war, irrtümlich in die Newsgroup zu
posten. Möchte man stattdessen die Antwort tatsächlich in die Newsgroup posten
und öffnet versehentlich den E-Mail-Editor, rennt man auch da gegen eine
Mauer: der E-Mail-Editor versteht kein NNTP und kann deswegen keine
Newsbeiträge posten. Er verweigert sich sogar jedem Versuch, das zu tun, indem
er Newsgroup-Namen nicht als Empfänger akzeptiert.

> Das Problem ist nicht Mozilla, sondern die Anwender, die ihre
> Anwendung(en) nicht im Griff haben.

Niemand ist perfekt, Fehler passieren immer wieder. Es gibt aber Software, die
Fehler vermeiden hilft oder abfängt, und es gibt Software, die das nicht tut.
Thunderbird scheint zu letzteren zu gehören. Das ist primär eine Aufgabe für
UI-Entwickler, aber genau die scheinen speziell bei Open-Source-Software
manchmal eher stiefmütterlich behandelt zu werden. Konsequenz: selbst zu
Zeiten, als Outlook Express noch ein sehr populärer Newsclient war, kamen
irrtümlich ins Usenet gepostete E-Mails mehrheitlich von Thunderbird, nicht
von Outlook Express. Die Erklärung dafür ist einfach: auch in Outlook Express
waren News- und E-Mail-Editor getrennt voneinander.

Gruß

Michael

[Arno Welzel]

Thomas Hochstein:

Allgemein gilt, dass es den "Cancel-Lock"-Header gibt und man den
korrekten Cancel-Key braucht, um einen Cancel erfolgreich ausführen zu
können. Genau das wurde eingeführt, um Fremd-Cancels zu verhindern.

In der Praxis werden aber eher Cancels von etlichen Servern einfach
generell ignoriert.

[Thomas Hochstein]

Arno Welzel schrieb:

> Thomas Hochstein:
> > Arno Welzel schrieb:
> >> Claus Reibenstein:
> >>> Wieso ist das Posting noch vorhanden? Das hatte ich doch gelöscht,
> >> Weil Canceln von Postings wegen massivem Misbrauchs dieser Funktion in
> >> der Vergangenehit in der Regel nicht funktioniert.
> > Das ist sowohl allgemein als auch insbesondere im speziellen Fall
> > unzutreffend.
>
> Allgemein gilt, dass es den "Cancel-Lock"-Header gibt und man den
> korrekten Cancel-Key braucht, um einen Cancel erfolgreich ausführen zu
> können. Genau das wurde eingeführt, um Fremd-Cancels zu verhindern.

So ist es. Und die relevanten Server beachten diese Konvention. Der
Server, den der OP nutzt, setzt beide Header sogar von selbst.

> In der Praxis werden aber eher Cancels von etlichen Servern einfach
> generell ignoriert.

Fraglos. Es wird immer etliche Server geben, die beliebige Dinge
ignorieren; alles kann, nichts muss.

Für die Praxis allerdings gilt, dass die ganz weit überwiegende Anzahl der
Netzteilnehmer in de.* Server nuttzt, die der Cancel-Lock-Konvention
folgen.

Das ist der _allgemeine_ Hintergrund.

Im _speziellen_ Fall würde es mich sehr überraschen, eine Cancel-Nachricht
zu sehen. Wenn eine solche tatsächlich versandt worden wäre, hätte
news.inidividual.de für den üassenden Cancel-Key gesorgt, und dann wäre
das Posting auf keinem Server, den ein Teilnehmer in diesem Thread nutzt,
noch sichtbar.

Deshalb war Deine Antwort im allgemeinen wie im speziellen neben der
Sache.

[Arno Welzel]

Thomas Hochstein:

[...]

> Für die Praxis allerdings gilt, dass die ganz weit überwiegende Anzahl der
> Netzteilnehmer in de.* Server nuttzt, die der Cancel-Lock-Konvention
> folgen.

Was nicht viel bringt, wenn die Peers das ignorieren.

> Deshalb war Deine Antwort im allgemeinen wie im speziellen neben der
> Sache.

Eher nicht.

[Thomas Hochstein]

Arno Welzel schrieb:

> Thomas Hochstein:
>

> > Für die Praxis allerdings gilt, dass die ganz weit überwiegende Anzahl der

> > Netzteilnehmer in de.* Server nutzt, die der Cancel-Lock-Konvention

> > folgen.
>
> Was nicht viel bringt, wenn die Peers das ignorieren.

Wenn (fast) alle Server die Konvention befolgen, reicht das völlig aus.