GVV Frage: Verneinte Datenschutzklausel

[Peter Heirich]

Ich teste gerade meine Installation von UseVote

Neben zwei Tippfehlern ( Patche an Marc Langer sind raus )

stellt sich mir die Frage der Behandlung der Datenschutzklausel.

Unterstellen wir Nicht-Bejahung der Datenschutzklausel:

Ist es ÃŒberhaupt korrekt, mit der UseVote-Software eine Benachrichtigung
zu erstellen, in der letztlich erlÀutert wird:

Wegen nicht erkannter Datenschutzklausel tun wir nichts, Stimme wird nicht
gezÀhlt.

Bereits darin liegt aber u.U. eine Verarbeitung. Zwar nett einen Hinweis
zu senden, aber u.U. unerwÃŒnscht und u.U. von einem Abmahn-Anwalt?

Zumal die Stimmabgabe weiterhin gespeichert wird.


Die Software kann die Mail bzw Stimme auch kommentarlos ignorieren.

Wie ist die empfohlene Verfahrensweise?

Peter

[Urs Janßen]

Content-Type: multipart/mixed; boundary="Xananews.1.2.3"

[...]

--Xananews.1.2.3
Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=usevoteger-4.14.patch

nicht wundern wenn dich keiner liest, cleanfeed entsorgt den binaermuell
ueblicherweise.

[Peter Heirich]

Post by Urs Janßen

Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=usevoteger-4.14.patch

nicht wundern wenn dich keiner liest, cleanfeed entsorgt den binaermuell
ueblicherweise.

Genaugenommen ist da nichts binär, sondern Text in iso8859-1

Mein "innerer", frischer 2.7.1 inn ( debian bookworm ) hat es akzeptiert,
der "äußere" inn 2.6.5 hat es dann verweigert.

Mindestens der uplink zu in-berlin.de scheint es genommen zu haben, sonst
wäre es bei dir nicht angekommen.

Ich habe jetzt ein Supersedes drüber gemacht und einen www-Link für
Bedürftige benutzt.

Aber trotzdem danke für den Hinweis!

Peter

[Urs Janßen]

Post by Peter Heirich

Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch

Genaugenommen ist da nichts binär, sondern Text in iso8859-1

der content-type sagt was anderes
_unified_ diff als text/plain waer sinnvoller gewesen

[Peter Heirich]

Post by Urs Janßen
der content-type sagt was anderes
unified diff als text/plain waer sinnvoller gewesen

War nur so ein Test was xananews da macht.

Und von mir aus auch beide Patches als diff -U 5

https://heirich.name/usevote/

[Henning Hucke]

Post by Urs Janßen

Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=usevoteger-4.14.patch

nicht wundern wenn dich keiner liest, cleanfeed entsorgt den binaermuell
ueblicherweise.

Genaugenommen ist da nichts bin�r, sondern Text in iso8859-1
[...]

Hallo Peter,

meine Empfehlung ist in einem solchen Fall immer, dann auch den
entsprechenden MIME-Type zu verwenden.

Was Urs m�glicherweise meinte, war der MIME-Type. Faktisch ist
"application/octet-stream" ein Synonym f�r "arbitrary data", mithin
zumindest potentiell bin�re Daten. Da schaut man dann nicht
notwendigerweise auch noch rein und analysiert das, wenn "jemand" schon
deklariert, dass es arbitrary data ist.

Least matching w�re beispielsweise "text/plain" gewesen. Mein "mime.type"
kennt beispielsweise "text/x-patch".

Was heutzutage so als "application/octet-stream" durch die Gegend
geschleudert wird, ist hahneb�chen. Auch so eine Sache, f�r die ich
Microsoft gerne mal die Leviten lesen w�rde.

MfG Henning

[Urs Janßen]

x-post und f'up nach de.comm.software.newsreader

Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: tin/2.4.1-20161224 ("Daill") (UNIX) (Linux/4.9.0-15-amd64 (x86_64))

[...]

meine Empfehlung ist in einem solchen Fall immer, dann auch den
entsprechenden MIME-Type zu verwenden.
Was Urs m�glicherweise meinte, war der MIME-Type. Faktisch ist

^ das war mal ein ISO-8859-1 ö, passt also nicht zum angegebenen
UTF-8.

wie man das mit tin >= 2.0 hinbekommt ist mir ein raetzel.

[Claus Reibenstein]

Post by Henning Hucke
Was Urs m�glicherweise meinte, war der MIME-Type. Faktisch ist

Content-Type: text/plain; charset=UTF-8

Content-Type und Textkodierung sollten schon zusammenpassen, wenn man
lesbare Postings erzeugen will.

Gruß
Claus

[Peter Heirich]

Post by Henning Hucke
meine Empfehlung ist in einem solchen Fall immer, dann auch den
entsprechenden MIME-Type zu verwenden.

Wenn das wirklich nötig gewesen wäre, hätte ich mit slrn o.ä. mein
grüch versucht.

Der Gedanke war: Weil ich die Patces erwähne, hänge doch die paar Bytes
mit ran. xananews hat da einen ATTACH-Button, noch nie zuvor benutzt.
Binaries sind es nicht, also ke.in Verstoß gegen die Netiquette.

Nach Content-Type wurde nicht gefragt. Einfach Anlage drangehängt und los.

Mein Server hat das angenommen und damit für mich ok.

Durch die Bemerung von Urs dann "aufgewokt" ;-) mein nächster Server mit
Speisung über nntp hat verweigert. Über UUCP in Richtung iplink aber raus.

Vermutlich ist cleanfeed irgendwie bei debian optional, bei Centos nicht ?


Egal, demnächst mal checken.

Peter

[Claus Reibenstein]

Post by Peter Heirich

Post by Urs Janßen

Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=usevoteger-4.14.patch

nicht wundern wenn dich keiner liest, cleanfeed entsorgt den binaermuell
ueblicherweise.

Genaugenommen ist da nichts binär, sondern Text in iso8859-1

Attachments sind im Usenet generell nicht gern gesehen, egal ob binär
oder Text. Manche Newsserver entfernen solche Attachments, andere gleich
die komplette Nachricht.

Dass mein individual.de die Nachricht komplett durchgelassen hat,
wundert mich etwas. Normalerweise filtern die die Attachments raus.

Gruß
Claus

[Heiko Schlichting]

Post by Claus Reibenstein
Dass mein individual.de die Nachricht komplett durchgelassen hat,
wundert mich etwas. Normalerweise filtern die die Attachments raus.

Bislang nur, wenn es sich wirklich um Binaries handelt.

Heiko

[Peter J. Holzer]

Post by Claus Reibenstein

Post by Peter Heirich

Post by Urs Janßen

Content-Type: Application/Octet-Stream; name=usevoteger-4.14.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=usevoteger-4.14.patch

nicht wundern wenn dich keiner liest, cleanfeed entsorgt den binaermuell
ueblicherweise.

Genaugenommen ist da nichts binär, sondern Text in iso8859-1

Attachments sind im Usenet generell nicht gern gesehen, egal ob binär
oder Text. Manche Newsserver entfernen solche Attachments, andere gleich
die komplette Nachricht.

Letzteres ist IMHO ok, aber eine geänderte Nachricht weiterzuleiten,
ist ein absolutes Nono.

Post by Claus Reibenstein
Dass mein individual.de die Nachricht komplett durchgelassen hat,
wundert mich etwas. Normalerweise filtern die die Attachments raus.

Oft gibt es noch weitere Kriterien, insbesondere die Länge der
Nachricht.

hp

[Claus Reibenstein]

Post by Peter J. Holzer

Post by Claus Reibenstein
Attachments sind im Usenet generell nicht gern gesehen, egal ob binär
oder Text. Manche Newsserver entfernen solche Attachments, andere gleich
die komplette Nachricht.

Letzteres ist IMHO ok, aber eine geänderte Nachricht weiterzuleiten,
ist ein absolutes Nono.

Habe ich oft genug erlebt.

Gruß
Claus

[Heiko Schlichting]

Post by Claus Reibenstein

[...] aber eine geänderte Nachricht weiterzuleiten, ist ein absolutes
Nono.

Habe ich oft genug erlebt.

Welche Newsserver verändern denn Artikel beim Weiterleiten? Ich kann mich
nicht erinnern, sowas in den letzten Jahren mal bemerkt zu haben.

Heiko