info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bedenkliche Entwicklungen in der IT-Landschaft am Beispiel von Mail, Newsletters und co
38 views
Skip to first unread message
Henning Hucke
Oct 14, 2022, 5:37:41 AM10/14/22
to
Hallo *,
als Admin bin ich seit 1994 unterwegs. Von Anfang an bezüglich
Linux/Unix und Netzwerk, weiteres ist mit den Jahren und der Technik
dazu gekommen.
Mit Computern bin ich grundsätzlich seit Ende der 1970er unterwegs,
mit einem eigenen seit etwa 1982.
Im Laufe der Jahre entwickeln man vermutlich ein paar Steckenpferde und
sei es nur, weil sie als Indikator für merkwürdige oder gar
Fehlentwicklungen dienen zu können scheinen.
Eines meiner solchen Steckenpferde ist "Mail"; vom Aufbau, Funktion und
Möglichkeiten von Mails über Mail-Systeme allgemein bis hin zu mail
processing etc pp. Mein Wissen in diesem - aber Gott sei Dank nicht nur
diesem - Bereich dürfte mit "Expertenniveau" nicht vollkommen
unzutreffend charakterisiert sein, wiewohl es natürlich und sicherlich
ITler gibt, die (auch) in diesem Bereich mehr/tieferes Wissen als ich
haben.
In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
triggern.
"Arbeit" differenziere ich von "Unannehmlichkeiten" dadurch, dass nicht
hier und da mal eine maildrop/procmail-Regel nachgeschäft, eine regex
mehr als vom Standard vorgesehen aufgebohrt werden muss, sondern man
echte Schwierigkeiten hat, seine Informationen/Anliegen los und
gegebenenfalls gefixt zu bekommen, weil auf jedem der Wege Fallstricke
lauern, die man zum einen vorher nicht kennt, weil sie nirgendwo
kommuniziert werden, zum anderen auch nicht (so einfach) um sie herum
kommt und es aus diesem Grund sinnvoll ist, zunächst einen anderen Weg zu
versuchen (der dann gerne wider Erwartung ebenfalls nicht funktioniert),
bevor man das Unternehmen unternimmt, um einen Fallstrick herum zu kommen.
Das hat damit begonnen, dass gegen Mitte der 2010er Jahre verwendete
funktionierende legitime E-Mail-Adressen angeblich keine E-Mail-Adressen
mehr waren - gefühlt zuerst bei Versicherungen bei denen man (sinnvoller
Weise, wie auch anderswo) solche als Login-Namen verwendet hat /
verwenden sollte, diese aber als angebliche Nicht-E-Mail-Adressen
*strikt* (read: nicht nach einem "Sind Sie sicher, dass sie diese
E-Mail-Adresse verwenden wollen und Mails an diese ankommen?" akzeptiert
worden wären) abgelehnt wurden -, ging damit weiter, dass beim
Arbeitgeber im Mail-System Adressen wie "vert...@firmen.domain"
eingetragen waren aber auf der Web-Seite "Vert...@firmen.domain"
verwendet wurde oder man bei einem Dienstleister "user...@meine.domain"
hinterlegt hat aber die - auch die wichtigen! - Mails an
"USER...@MEINE.DOMAIN" verschickt werden und endet nicht mit dem, was
ich gleich beschreibe.
Wir verstehen uns bitte richtig! Das vorbeschriebene sind /Beispiele/!
Es ist nicht nur das und es sind nicht unbedingt die "schlimmsten
Sachen". Aber der ein oder andere, der sich ebenfalls mit Mail-Sachen
etwas spezifischer auskennt, versteht vermutlich die Tragweite.
Das folgende ist ein Beispiel für das, was ich meine, wenn ich schreibe,
dass es inzwischen Arbeit triggert.
Natürlich bin auch ich krankenversichert. Und ich lasse mir durchaus
nicht ungerne Newsletter auch von meiner Krankenkasse mailen, weil man
über manche Sachen dann doch auf dem laufenden bleibt, wofür man
ansonsten regelmäßig explizit recherchieren müsste.
Es ist nicht schlimm, dass diese Newsletter einen HTML-Teil haben; in
bestimmten Situationen öffne ich den HTML-Teil durchaus in einem
entsprechenden Reader oder öffne ihn in einem HTML-Browser, um mir die
Informationen anzusehen. Aber mein Standard-Mailreader, den ich auch
gerne mal von unterwegs von meinem Tablet aus verwende, verwendet Curses
und stellt vorzugsweise den Plain-Text-Teil dar, rendert aber sogar den
HTML-Teil vernünftig, wenn dieser nicht allzu blödsinnig und mit allzu
vielen Grafiken gestaltet ist, wenn kein Text-Plain-Teil vorhanden ist.
So weit, so durchaus gut.
Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu schreiben
- Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass jeder
versteht, warum das so ist.
Der entscheidende Teil ist aber der folgende:
Natürlich hat die Krankenkasse eine Support-Mail-Adresse und ein
"E-Mail-Formular" auf der Web-Seite und weiteres.
Nun wollte ich die obige Information der Krankenkasse zukommen lassen
und als Beispiel auch die (nur der Vollständigkeit halber erwähnt: um
den HTML-Teil erleichterte Infomail-Mail, damit die Bearbeiter
tatsächlich den Plain-Text-Teil angezeigt bekommen) Infomail.
Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
annehmen würde. Der anschliessende Versuch mit dem Gedöns als
".txt"-Attachment hatte dasselbe Resultat.
Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
ich einige nicht liefern kann - ".doc" und ähnliches -, einiges besagte
Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
und einiges schlicht untauglich für den Transport der relevanten
Information ist.
Als nächstes habe ich das "E-Mail-Kontakt-Formular" versucht. Dieses
akzeptiert nur eine (zu) geringe Anzahl von Zeichen für die eigentliche
Nachricht und sieht keine Attachments vor.
Als nächstes habe ich das "Postfach" bei der Krankenkassen versucht. Das
funktionierte bis zum Absenden wunderbar, triggerte beim Absenden aber
einen unspezifische Fehler, sodass ich auf diesem Weg meine
Informationen ebenfalls nicht einkippen kann.
Schlussendlich habe ich die Mail mit meinem Anliegen und der
(angepassten) Infomail als Attachment an
"postm...@krankenkassen.domain" gemailt, die erstaunlicherweise sogar
angenommen wurde aber bisher keine Reaktion, geschweigedenn eine Antwort
erhalten und denke auch, dass sich das nicht ändern wird, vermutlich die
Mails im Nirwana oder einem nie gelesenen maildrop landen.
ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
Politik und gegebenenfalls Fachverbände und vielleicht sogar
Wirtschaftskunden auf dem Schirm?
Kann jemand hier diese Erfahrungen sekundieren und/oder hat einen guten
Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
mit an die Mail an den Support zu bappen, zu machen)!?
Mit freundlichem aber etwas ratlosen Gruß,
Henning
--
You have an ambitious nature and may make a name for yourself.
als Admin bin ich seit 1994 unterwegs. Von Anfang an bezüglich
Linux/Unix und Netzwerk, weiteres ist mit den Jahren und der Technik
dazu gekommen.
Mit Computern bin ich grundsätzlich seit Ende der 1970er unterwegs,
mit einem eigenen seit etwa 1982.
Im Laufe der Jahre entwickeln man vermutlich ein paar Steckenpferde und
sei es nur, weil sie als Indikator für merkwürdige oder gar
Fehlentwicklungen dienen zu können scheinen.
Eines meiner solchen Steckenpferde ist "Mail"; vom Aufbau, Funktion und
Möglichkeiten von Mails über Mail-Systeme allgemein bis hin zu mail
processing etc pp. Mein Wissen in diesem - aber Gott sei Dank nicht nur
diesem - Bereich dürfte mit "Expertenniveau" nicht vollkommen
unzutreffend charakterisiert sein, wiewohl es natürlich und sicherlich
ITler gibt, die (auch) in diesem Bereich mehr/tieferes Wissen als ich
haben.
In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
triggern.
"Arbeit" differenziere ich von "Unannehmlichkeiten" dadurch, dass nicht
hier und da mal eine maildrop/procmail-Regel nachgeschäft, eine regex
mehr als vom Standard vorgesehen aufgebohrt werden muss, sondern man
echte Schwierigkeiten hat, seine Informationen/Anliegen los und
gegebenenfalls gefixt zu bekommen, weil auf jedem der Wege Fallstricke
lauern, die man zum einen vorher nicht kennt, weil sie nirgendwo
kommuniziert werden, zum anderen auch nicht (so einfach) um sie herum
kommt und es aus diesem Grund sinnvoll ist, zunächst einen anderen Weg zu
versuchen (der dann gerne wider Erwartung ebenfalls nicht funktioniert),
bevor man das Unternehmen unternimmt, um einen Fallstrick herum zu kommen.
Das hat damit begonnen, dass gegen Mitte der 2010er Jahre verwendete
funktionierende legitime E-Mail-Adressen angeblich keine E-Mail-Adressen
mehr waren - gefühlt zuerst bei Versicherungen bei denen man (sinnvoller
Weise, wie auch anderswo) solche als Login-Namen verwendet hat /
verwenden sollte, diese aber als angebliche Nicht-E-Mail-Adressen
*strikt* (read: nicht nach einem "Sind Sie sicher, dass sie diese
E-Mail-Adresse verwenden wollen und Mails an diese ankommen?" akzeptiert
worden wären) abgelehnt wurden -, ging damit weiter, dass beim
Arbeitgeber im Mail-System Adressen wie "vert...@firmen.domain"
eingetragen waren aber auf der Web-Seite "Vert...@firmen.domain"
verwendet wurde oder man bei einem Dienstleister "user...@meine.domain"
hinterlegt hat aber die - auch die wichtigen! - Mails an
"USER...@MEINE.DOMAIN" verschickt werden und endet nicht mit dem, was
ich gleich beschreibe.
Wir verstehen uns bitte richtig! Das vorbeschriebene sind /Beispiele/!
Es ist nicht nur das und es sind nicht unbedingt die "schlimmsten
Sachen". Aber der ein oder andere, der sich ebenfalls mit Mail-Sachen
etwas spezifischer auskennt, versteht vermutlich die Tragweite.
Das folgende ist ein Beispiel für das, was ich meine, wenn ich schreibe,
dass es inzwischen Arbeit triggert.
Natürlich bin auch ich krankenversichert. Und ich lasse mir durchaus
nicht ungerne Newsletter auch von meiner Krankenkasse mailen, weil man
über manche Sachen dann doch auf dem laufenden bleibt, wofür man
ansonsten regelmäßig explizit recherchieren müsste.
Es ist nicht schlimm, dass diese Newsletter einen HTML-Teil haben; in
bestimmten Situationen öffne ich den HTML-Teil durchaus in einem
entsprechenden Reader oder öffne ihn in einem HTML-Browser, um mir die
Informationen anzusehen. Aber mein Standard-Mailreader, den ich auch
gerne mal von unterwegs von meinem Tablet aus verwende, verwendet Curses
und stellt vorzugsweise den Plain-Text-Teil dar, rendert aber sogar den
HTML-Teil vernünftig, wenn dieser nicht allzu blödsinnig und mit allzu
vielen Grafiken gestaltet ist, wenn kein Text-Plain-Teil vorhanden ist.
So weit, so durchaus gut.
Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu schreiben
- Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass jeder
versteht, warum das so ist.
Der entscheidende Teil ist aber der folgende:
Natürlich hat die Krankenkasse eine Support-Mail-Adresse und ein
"E-Mail-Formular" auf der Web-Seite und weiteres.
Nun wollte ich die obige Information der Krankenkasse zukommen lassen
und als Beispiel auch die (nur der Vollständigkeit halber erwähnt: um
den HTML-Teil erleichterte Infomail-Mail, damit die Bearbeiter
tatsächlich den Plain-Text-Teil angezeigt bekommen) Infomail.
Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
annehmen würde. Der anschliessende Versuch mit dem Gedöns als
".txt"-Attachment hatte dasselbe Resultat.
Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
ich einige nicht liefern kann - ".doc" und ähnliches -, einiges besagte
Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
und einiges schlicht untauglich für den Transport der relevanten
Information ist.
Als nächstes habe ich das "E-Mail-Kontakt-Formular" versucht. Dieses
akzeptiert nur eine (zu) geringe Anzahl von Zeichen für die eigentliche
Nachricht und sieht keine Attachments vor.
Als nächstes habe ich das "Postfach" bei der Krankenkassen versucht. Das
funktionierte bis zum Absenden wunderbar, triggerte beim Absenden aber
einen unspezifische Fehler, sodass ich auf diesem Weg meine
Informationen ebenfalls nicht einkippen kann.
Schlussendlich habe ich die Mail mit meinem Anliegen und der
(angepassten) Infomail als Attachment an
"postm...@krankenkassen.domain" gemailt, die erstaunlicherweise sogar
angenommen wurde aber bisher keine Reaktion, geschweigedenn eine Antwort
erhalten und denke auch, dass sich das nicht ändern wird, vermutlich die
Mails im Nirwana oder einem nie gelesenen maildrop landen.
ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
Politik und gegebenenfalls Fachverbände und vielleicht sogar
Wirtschaftskunden auf dem Schirm?
Kann jemand hier diese Erfahrungen sekundieren und/oder hat einen guten
Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
mit an die Mail an den Support zu bappen, zu machen)!?
Mit freundlichem aber etwas ratlosen Gruß,
Henning
--
You have an ambitious nature and may make a name for yourself.
Thomas Klix
Oct 14, 2022, 9:42:12 AM10/14/22
to
Henning Hucke wrote at Fri, 14 Oct 2022 09:10:49 -0000 (UTC):
> [...]
Nimm den "plain text"-Teil und forwarde ihn an eine passende Email-Adresse -
dann steht als erstes deine Kritik, gefolgt von "forwarded mail:" und dann
das kritisierte Teil. Alles plain text.
Thomas
> [...]
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
Warum willst du diese Infomail unbedingt als Anhang verschicken?
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
Nimm den "plain text"-Teil und forwarde ihn an eine passende Email-Adresse -
dann steht als erstes deine Kritik, gefolgt von "forwarded mail:" und dann
das kritisierte Teil. Alles plain text.
Thomas
Marco Moock
Oct 14, 2022, 2:00:42 PM10/14/22
to
Am 14.10.2022 um 09:10:49 Uhr schrieb Henning Hucke:
> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
> triggern.
Die meisten Leute wollen das leider so.
> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
> triggern.
> Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
> einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
> wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu
> schreiben
> - Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass
> jeder versteht, warum das so ist.
deabonniere diese Newsletter.
Henning Hucke
Oct 15, 2022, 4:37:42 AM10/15/22
to
Marco Moock <mo...@posteo.de> wrote:
> Am 14.10.2022 um 09:10:49 Uhr schrieb Henning Hucke:
>
>> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
>> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
>> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
>> triggern.
>
> Die meisten Leute wollen das leider so.
Mit Verlaub: Das bezweifele ich.
> Am 14.10.2022 um 09:10:49 Uhr schrieb Henning Hucke:
>
>> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
>> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
>> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
>> triggern.
>
> Die meisten Leute wollen das leider so.
Außerdem war ja meine Frage eher, ob der CCC solche Sachen auf dem Schirm
hat und in entsprechenden Beratungen gegebenenfalls geeignet
transportiert. Das ist das, was mich in Bezug auf den CCC an diesem
Aspekt in dieser Newsgroup am meisten interessiert.
Inwieweit das "gesellschaftlich so 'gewollt'" ist, warum es so ist und
wie man gegensteuern kann, sind andere Fragen, die man gerne in einem
anderen Thread und/oder in einer anderen (zu dieser Fragestellung
passenderen) Newsgroup besprechen kann; no offence!
>> Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
>> einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
>> wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu
>> schreiben
>> - Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass
>> jeder versteht, warum das so ist.
>
> Ist leider so und nervt, aber ich lese sowas dann nicht mehr und
> deabonniere diese Newsletter.
Aber die inkriminierte Mail hat mich gebeten, meinen Account "zu bestätigen",
weil mir sonst der Zugriff abhanden kommen (und die Wiedererlangung
desselben entsprechende Arbeit / entsprechenden Aufwand triggern) wird.
Und diese Mail wurde mit Newsletter-Methoden (List-Id-Header etc pp)
verschickt, weshalb sie zudem in meinem entsprechenden Newsletter-Folder
statt im Anbieter bezogenen "Wichtige(re) Mails"-Folder gelandet ist.
Wenn schon mit Newsletter-Methoden, dann bitte eine List-Id für den
normalen Newsletter und eine /andere/ List-Id für die /wichtigen/ per
Massenmail verschickten Infomails!
Mit freundlichem Gruß,
Henning
--
Honesty is for the most part less profitable than dishonesty.
-- Plato
Henning Hucke
Oct 15, 2022, 4:37:42 AM10/15/22
to
Dank für den Gedanken.
Das E-Mail-Formular erlaubt nicht genügend Zeichen, um überhaupt die
inkriminierte Mail zu transportieren.
Aus Erfahrung ist meine starke Vermutung, dass die als selbstständige
weitergeleitete oder gebouncte Mail beim Support nur Unverständnis
hinterlassen wird. Zudem beziehe ich mich auch auf Header-Informationen,
die in dieser Form verloren gehen.
Wie geschrieben: Bei Verwendung des "Postfach"s, als einer
"Web-Mail"-Anwendung, die ausschliesslich eine anbieterinterne
Kommunikation erlaubt/unterstützt, führt das Schreiben einer Nachricht
mit dem pasten des Plain-Text-Anteils der inkriminierten Mail zu einem
unspezifischen Fehler, der faktisch das Versenden der Informationen
unmöglich macht.
Darüber hinaus ist das ja nur ein Teilaspekt meiner Kritik / meines
"Problems". Warum werden keine ".txt"-Attachments erlaubt!? Warum wird
es nirgendwo zum Durchlesen im vorhinein an prominenter Stelle
dokumentiert? Muss ich bei jeder Ziel-Adresse vorher nachschauen,
welche Attachments akzeptiert werden?
Mehr noch: Warum werde ich an eine E-Mail-Adresse "postmaster" etwas los,
was (Stand heute) augenscheinlich im Nirwana landet?
Aber viel weiter tragend: Wie ich schrub, ist das nur und lediglich ein
Beispiel.
Ich könnte auch noch davon berichten, dass E-Mails an den Bundestag mit
Absenderadressen nach dem oben zu sehenden Muster auf Anfoderung
Server-Empfangsbestätigungen triggern, dann aber nicht mal
beispielsweise SPAM-getagt im adressierten maildrop landen, sondern
*verifizierter Weise* im "Nirwana" verschwinden, dass Mails mit
normalerer Absender-E-Mail-Adresse aufgrund eines Subject-Tags der Art
"[TAG@<tag>] Subject text" das selbe passiert, etc pp.
Hätte ich bei dieser Sache nicht nachgehakt und hätte ich keine
Server-Empfangsbestätigung angefordert, würde ich bis zum Sankt
Nimmerleinstag auf Reaktion, geschweigedenn Antwort gewartet haben...
Mit freundlichem Gruß,
Henning
--
The echo of a platitude from the mouth of a fool.
-- Ambrose Bierce
Marco Moock
Oct 15, 2022, 4:57:31 AM10/15/22
to
Am 15.10.2022 um 08:16:18 Uhr schrieb Henning Hucke:
> Mit Verlaub: Das bezweifele ich.
Der Ottonormaluser kennt nur HTML-Mails und da das dann auch so toll
> Mit Verlaub: Das bezweifele ich.
für den aussieht, will der nichts anderes. Dass es andere Leute gibt,
die das anders sehen, wird gerne ignoriert.
Stefan Froehlich
Oct 15, 2022, 6:53:11 AM10/15/22
to
#v+
From: *grosses, internationales unternehmen*
Subject: REMINDER 1: IMPORTANT NOTIFICATION ABOUT DIGITAL CERTIFICATE CHANGES AT $FIRMA - ACTION REQUIRED
[...]
Content-Type: multipart/alternative
[...]
Content-Type: text/plain
Dear all,
As many of you faced issues with the previous emails, I am sharing
the certificates as direct email. Kindly install the new
certificates as per the below instructions. [...]
#v-
In der Mail davor wurde lediglich ein 500 kB großes HTML-Attachment
verschickt, das man abspeichern und lokal mit dem Browser öffnen
sollte, um darin dann einen Link zu finden, mit dem man eine
verschlüsselte Übertragung der neuen Zertifikate anstoßen hätte
können.
Der Reifen war offenbar so klein geraten, dass niemand mehr
durchspringen wollte, und siehe da: Es ging am Ende doch auch
anders.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - weil bleue Liebe nie und nimmer treibt.
(Sloganizer)
Nomen Nescio
Oct 15, 2022, 7:27:11 AM10/15/22
to
On 2022-10-15, Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Außerdem war ja meine Frage eher, ob der CCC solche Sachen auf dem Schirm
> hat und in entsprechenden Beratungen gegebenenfalls geeignet
> transportiert.
Nein, tut "der CCC" nicht.
> Außerdem war ja meine Frage eher, ob der CCC solche Sachen auf dem Schirm
> hat und in entsprechenden Beratungen gegebenenfalls geeignet
> transportiert.
Du überschätzt die Beratertätigkeiten sowie das Interesse für E-Mail.
Nomen Nescio
Oct 15, 2022, 7:42:23 AM10/15/22
to
On 2022-10-15, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> In der Mail davor wurde lediglich ein 500 kB großes HTML-Attachment
> verschickt, das man abspeichern und lokal mit dem Browser öffnen
> sollte, um darin dann einen Link zu finden, mit dem man eine
> verschlüsselte Übertragung der neuen Zertifikate anstoßen hätte
> können.
Ziemlich unsicherer Saftladen, wenn die Mitarbeiter am cert store
> In der Mail davor wurde lediglich ein 500 kB großes HTML-Attachment
> verschickt, das man abspeichern und lokal mit dem Browser öffnen
> sollte, um darin dann einen Link zu finden, mit dem man eine
> verschlüsselte Übertragung der neuen Zertifikate anstoßen hätte
> können.
herumpfuschen müssen. Die haben keine IT?
Stefan Reuther
Oct 15, 2022, 9:59:41 AM10/15/22
to
Am 14.10.2022 um 11:10 schrieb Henning Hucke:
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde.
Ach, und ich dachte, jetzt kommt eine Tirade über das Oligopol der
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde.
großen Mailanbieter, die kleinere über immer weitere Stöckchen springen
lassen, und ansonsten Mails auch mal ohne Meldung an Sender oder
Empfänger wegwerfen, alles im Namen der Heiligen Spambekämpfung. DAS
würde ich eine bedenkliche Entwicklung nennen.
HTML-Mail? Ist halt Standard geworden. Mag nicht jeder, aber Texte
formatieren ist halt von den Nutzern gewünscht und ein anderes Format
dafür hat sich nicht durchgesetzt (erinnert sich wer an text/enriched?).
Attachment-Filter? Ist halt Stand der Technik, wenn auf der anderen
Seite potenziell Sachbearbeiter sitzen, die auf alles klicken, was nicht
bei Drei auf den Bäumen ist. Immerhin war dein Filter so freundlich, dir
mitzuteilen, was er nicht mag, anstatt es einfach zu löschen.
Stefan
Stefan Froehlich
Oct 15, 2022, 11:22:57 AM10/15/22
to
eigenwillige. Ich hatte noch weitere lustige Erfahrungen mit denen,
z.B. Zeitangaben der Form:
#v+
<DATE>2019-07-29+01:00T09:52:05+01:00</DATE>
#v-
...gepaart mit völligem Unverständnis, wo denn mein Problem damit
wäre.
Ich bin Einzelunternehmer, die haben 10k Mitarbeiter und machen
rund 1 Mrd. Umsatz. Leider ein ungleiches Duell.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Henning Hucke
Oct 17, 2022, 3:37:37 AM10/17/22
to
das kann man ja so auch grundsätzlich stehen lassen, wenn ich es auch
weiterhin bezweifele.
Es geht ja aber gerade nicht um Newsletter-Mails, sondern um Mails, die
mit Massenmail-Methoden versendet werden und nicht unwichtige, um nicht
"wichtige" zu schreiben, Informationen enthalten bzw. Aktionen
veranlassen möchten.
Wenn diese Informationen abseits unzureichender Verdeutlichung, dass die
Mail wichtig ist - noch nicht mal ein "Priority: high" oder ähnliches
war gesetzt - zudem in syntaktischem Müll versteckt werden, triggert das
(auf die angedeutete Weise) (vermeidbar gewesene) Arbeit.
Auf nicht mehr aber auch auf nicht weniger wollte ich hinaus; und auf
die Weiterungen und weiteren Folgen... :-).
Mit freundlichem Gruß,
Henning
--
Sebastian Suchanek
Nov 17, 2022, 1:21:55 AM11/17/22
to
Am 14.10.2022 um 11:10 schrieb Henning Hucke:
> [...]
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> ich einige nicht liefern kann - ".doc" und ähnliches
> [...]
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> ich einige nicht liefern kann - ".doc" und ähnliches
Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
.doc-Dateien erzeugen.
Davon abgesehen finde ich es aber schon einigermaßen seltsam, dass man
einerseits .eml-Anhänge zurückweist, .doc aber akzeptiert. (.doc kann
(schad-)makro-versucht sein, das neuere .docx hingegen nicht.)
Tschüs,
Sebastian
Marco Moock
Nov 17, 2022, 2:05:12 AM11/17/22
to
Am 17.11.2022 um 07:16:55 Uhr schrieb Sebastian Suchanek:
> Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
> .doc-Dateien erzeugen.
Wobei die vollständige Kompatibilität mit MS-Office nicht immer gegeben
> Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
> .doc-Dateien erzeugen.
ist.
> Davon abgesehen finde ich es aber schon einigermaßen seltsam, dass
> man einerseits .eml-Anhänge zurückweist, .doc aber akzeptiert. (.doc
> kann (schad-)makro-versucht sein, das neuere .docx hingegen nicht.)
dann eine Bewerbung als .doc nicht bekommt, wird die sauer und will das
entsperrt haben.
Marc Haber
Nov 17, 2022, 4:41:25 AM11/17/22
to
Sebastian Suchanek <sebastian...@gmx.de> wrote:
>Am 14.10.2022 um 11:10 schrieb Henning Hucke:
>
>> [...]
>> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
>> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
>> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
>> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
>> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
>> ".txt"-Attachment hatte dasselbe Resultat.
>> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
>> ich einige nicht liefern kann - ".doc" und ähnliches
> > [...]
>
>Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
>.doc-Dateien erzeugen.
Die aber oft genug in Word dann nicht so aussehen wie beabsichtigt.
>Am 14.10.2022 um 11:10 schrieb Henning Hucke:
>
>> [...]
>> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
>> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
>> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
>> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
>> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
>> ".txt"-Attachment hatte dasselbe Resultat.
>> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
>> ich einige nicht liefern kann - ".doc" und ähnliches
> > [...]
>
>Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
>.doc-Dateien erzeugen.
Das liegt u.a. daran dass Microsoft das Format nie offengelegt hat und
alle Exportfunktionen anderer Softwae durch Reverse Engineering des
komplexen Formates entstehen mussten.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Marco Moock
Nov 17, 2022, 4:43:55 AM11/17/22
to
Am 17.11.2022 um 10:41:23 Uhr schrieb Marc Haber:
> Die aber oft genug in Word dann nicht so aussehen wie beabsichtigt.
> Das liegt u.a. daran dass Microsoft das Format nie offengelegt hat und
> alle Exportfunktionen anderer Softwae durch Reverse Engineering des
> komplexen Formates entstehen mussten.
docx wurde aber wohl veröffentlicht, trotzdem ist LO nicht komplett
> Die aber oft genug in Word dann nicht so aussehen wie beabsichtigt.
> Das liegt u.a. daran dass Microsoft das Format nie offengelegt hat und
> alle Exportfunktionen anderer Softwae durch Reverse Engineering des
> komplexen Formates entstehen mussten.
damit kompatibel.
Marc Haber
Nov 17, 2022, 7:11:21 AM11/17/22
to
.docx-Export¹ meines Angebots sehr seltsam formatiert aussah wenn man
ihn in Word öffnete, gibt es von mir nur noch PDFs oder in
Ausnahmefällen docs die ich selbst in Word gespeichert und geprüft
habe.
Das taugt für "ich muss importieren und exportieren weil ich das
Produkt wechsle", nicht aber für ernsthafte Kollaboration wo das
Dokument mehrmals hin- und her geht.
Grüße
Marc
¹ ich weiß nicht mehr welches der zwei Formate es war
Marco Moock
Nov 17, 2022, 12:02:20 PM11/17/22
to
Am 17.11.2022 um 17:34:29 Uhr schrieb Beate Goebel:
> Marco Moock schrieb am 17 Nov 2022
> Hast Du das Konvertieren mal selbst probiert? Das macht man nur
> einmal!
Ja, das war 2022, als ich für mein Azubi-Abschlussprojekt ne Doku
schreiben musste. Die MS-Leute wollten das als docx. Im LO funktioniert
dieses docx dann problemlos, in MS Office nicht mehr. Und wenn die dann
was geändert haben und das in LO zurückkommt, stimmt so Vieles an der
Formatierung, Seitenvorlagen und Positionen nicht mehr.
> Marco Moock schrieb am 17 Nov 2022
> einmal!
Ja, das war 2022, als ich für mein Azubi-Abschlussprojekt ne Doku
schreiben musste. Die MS-Leute wollten das als docx. Im LO funktioniert
dieses docx dann problemlos, in MS Office nicht mehr. Und wenn die dann
was geändert haben und das in LO zurückkommt, stimmt so Vieles an der
Formatierung, Seitenvorlagen und Positionen nicht mehr.
Alexander Ausserstorfer
Dec 18, 2022, 3:02:02 AM12/18/22
to
In article <tib92p$6b2$1...@sirius.aeon.icebear.cloud>,
sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
was das ist. Passieren kann dabei _rein gar nichts _.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> ich einige nicht liefern kann - ".doc" und ähnliches -, einiges besagte
> Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
> und einiges schlicht untauglich für den Transport der relevanten
> Information ist.
Diese Vorgehensweise halte ich für falsch. Zum einen gibt es tatsächlich
Systeme, die gar keine Dateinamenserweiterungen oder -enden verwenden
oder gebrauchen, zum anderen besagt diese Endung ja nicht, daß es sich
tatsächlich um dieses eine Datenformat handelt.
Die Entwicklung geht immer mehr dahin, daß alles automatisiert abläuft -
und die Menschen leider nicht mehr verstehen und wissen, was sie da
eigentlich noch tun. Von daher dürften nicht nur die von Dir vielen
beschriebenen Probleme herrühren.
> ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
> BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
> Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
> Politik und gegebenenfalls Fachverbände und vielleicht sogar
> Wirtschaftskunden auf dem Schirm?
Gibt es eigentlich einen Verein für ausnahmslos _alle (!)_
Computersysteme, der für seine Mitglieder neben einem Mittelungsblatt
auch noch Dienste im Internet anbietet wie Usenetserver, E-Mail-Server,
Webserver, Netzlaufwerke, Suchmaschinen und solches Zeugs und der NICHT
wirtschaftlich orientiert ist? Dem es vorrangig um die Förderung und
Verbreitung des Wissens und der Vernetzung der Mitglieder untereinander
geht?
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
Die Dateinamenserweiterungen sind nichtssagend. Üblicherweise läßt man
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
was das ist. Passieren kann dabei _rein gar nichts _.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> ich einige nicht liefern kann - ".doc" und ähnliches -, einiges besagte
> Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
> und einiges schlicht untauglich für den Transport der relevanten
> Information ist.
Systeme, die gar keine Dateinamenserweiterungen oder -enden verwenden
oder gebrauchen, zum anderen besagt diese Endung ja nicht, daß es sich
tatsächlich um dieses eine Datenformat handelt.
Die Entwicklung geht immer mehr dahin, daß alles automatisiert abläuft -
und die Menschen leider nicht mehr verstehen und wissen, was sie da
eigentlich noch tun. Von daher dürften nicht nur die von Dir vielen
beschriebenen Probleme herrühren.
> ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
> BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
> Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
> Politik und gegebenenfalls Fachverbände und vielleicht sogar
> Wirtschaftskunden auf dem Schirm?
Computersysteme, der für seine Mitglieder neben einem Mittelungsblatt
auch noch Dienste im Internet anbietet wie Usenetserver, E-Mail-Server,
Webserver, Netzlaufwerke, Suchmaschinen und solches Zeugs und der NICHT
wirtschaftlich orientiert ist? Dem es vorrangig um die Förderung und
Verbreitung des Wissens und der Vernetzung der Mitglieder untereinander
geht?
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Henning Hucke
Dec 19, 2022, 7:37:36 AM12/19/22
to
Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
> [...]
Alexander, herzlichen Dank für den Beitrag, der im Zweifelsfall anderen
weiter hilft.
Was Du schreibst, ist mir zum einen klar, zum anderen und insbesondere
mein Reden. Ganz besonders, weil sich beim "Mail-Attachment-Typ" die
Schlange ja in den Schwanz beißt: Wenn ich eh gerade eine Mail
analysiere, warum kann ich dann nicht eine an diese Mail angehängte Mail
analysieren. Ja, natürlich nur bis zu einer gewissen Tiefe, weil
ansonsten die Vermutung einer Mailbombe nicht mehr ganz abwegig ist
aber grundsätzlich ja schon.
Ja, und anhand der Dateiname-Endung zu analysieren (oder eben auch
nicht) ist erst recht Lötzinn. Vielleicht sollte ich es temporär so
einstellen, dass die Datei eine ".txt"-Endung bekommt aber der MIME-Type
dennoch der richtige/zutreffende bleibt. Aber auch das sind Massnahmen,
die eigentlich nicht notwendig sein sollten.
> [...]
ist nicht wirklich gemeinnützig, noch betreibst er insbesondere eigene
Technik.
Auch habe ich meine Zweifel, dass das so funktionieren würde. Außerdem
verwenden die meisten (fachfremden) Firmen inzwischen Dienstleister, die
es besser wissen sollten und müßten. Nicht selten - sei es in der Beratung
für Inhouse- bzw. On-Premise-Lösungen, sei es über Lösungen in der
Infrastruktur von spezialisierten Anbietern - dürften allerdings die
Kosten eine nennenswerte Rolle spielen. Und wenn man an dieser Stelle
spart, kommt eben etwas wie das beschriebene heraus...
Mit freundlichem Gruß,
Henning
--
Forecast, n:
A prediction of the future, based on the past, for
which the forecaster demands payment in the present.
> [...]
> Die Dateinamenserweiterungen sind nichtssagend. Üblicherweise läßt man
> sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
> was das ist. Passieren kann dabei _rein gar nichts _.
> [...]
> sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
> was das ist. Passieren kann dabei _rein gar nichts _.
Alexander, herzlichen Dank für den Beitrag, der im Zweifelsfall anderen
weiter hilft.
Was Du schreibst, ist mir zum einen klar, zum anderen und insbesondere
mein Reden. Ganz besonders, weil sich beim "Mail-Attachment-Typ" die
Schlange ja in den Schwanz beißt: Wenn ich eh gerade eine Mail
analysiere, warum kann ich dann nicht eine an diese Mail angehängte Mail
analysieren. Ja, natürlich nur bis zu einer gewissen Tiefe, weil
ansonsten die Vermutung einer Mailbombe nicht mehr ganz abwegig ist
aber grundsätzlich ja schon.
Ja, und anhand der Dateiname-Endung zu analysieren (oder eben auch
nicht) ist erst recht Lötzinn. Vielleicht sollte ich es temporär so
einstellen, dass die Datei eine ".txt"-Endung bekommt aber der MIME-Type
dennoch der richtige/zutreffende bleibt. Aber auch das sind Massnahmen,
die eigentlich nicht notwendig sein sollten.
> [...]
> Gibt es eigentlich einen Verein für ausnahmslos _alle (!)_
> Computersysteme, der für seine Mitglieder neben einem Mittelungsblatt
> auch noch Dienste im Internet anbietet wie Usenetserver, E-Mail-Server,
> Webserver, Netzlaufwerke, Suchmaschinen und solches Zeugs und der NICHT
> wirtschaftlich orientiert ist? Dem es vorrangig um die Förderung und
> Verbreitung des Wissens und der Vernetzung der Mitglieder untereinander
> geht?
Gibt es nach meiner Kenntnis nicht. Zwar existiert der ECO e.V. aber der
> Computersysteme, der für seine Mitglieder neben einem Mittelungsblatt
> auch noch Dienste im Internet anbietet wie Usenetserver, E-Mail-Server,
> Webserver, Netzlaufwerke, Suchmaschinen und solches Zeugs und der NICHT
> wirtschaftlich orientiert ist? Dem es vorrangig um die Förderung und
> Verbreitung des Wissens und der Vernetzung der Mitglieder untereinander
> geht?
ist nicht wirklich gemeinnützig, noch betreibst er insbesondere eigene
Technik.
Auch habe ich meine Zweifel, dass das so funktionieren würde. Außerdem
verwenden die meisten (fachfremden) Firmen inzwischen Dienstleister, die
es besser wissen sollten und müßten. Nicht selten - sei es in der Beratung
für Inhouse- bzw. On-Premise-Lösungen, sei es über Lösungen in der
Infrastruktur von spezialisierten Anbietern - dürften allerdings die
Kosten eine nennenswerte Rolle spielen. Und wenn man an dieser Stelle
spart, kommt eben etwas wie das beschriebene heraus...
Mit freundlichem Gruß,
Henning
--
A prediction of the future, based on the past, for
which the forecaster demands payment in the present.
Henning Hucke
Dec 19, 2022, 9:37:29 AM12/19/22
to
Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Am 14.10.2022 um 11:10 schrieb Henning Hucke:
>
>> [...]
>> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
>> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
>> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
>> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
>> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
>> ".txt"-Attachment hatte dasselbe Resultat.
>> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
>> ich einige nicht liefern kann - ".doc" und ähnliches
>> [...]
>
> Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
> .doc-Dateien erzeugen.
Hallo Sebastian,
> Am 14.10.2022 um 11:10 schrieb Henning Hucke:
>
>> [...]
>> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
>> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
>> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
>> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
>> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
>> ".txt"-Attachment hatte dasselbe Resultat.
>> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
>> ich einige nicht liefern kann - ".doc" und ähnliches
>> [...]
>
> Doch, Du kannst. OpenOffice und dessen Derivate können natürlich auch
> .doc-Dateien erzeugen.
erm... Ich/man kann vieles. Man kann auch mit einer Zahnbürste eine
Saturn-V-Rakete blitzblank putzen, es ist nur mäßig sinnvoll (es so zu
tun) und nicht sonderlich hilfreich.
Wie sollte man auf sinnvolle Weise eine Mail in einem .doc(c)? abbilden,
wo es doch nicht (nur) um den Mail-Body geht?...
> Davon abgesehen finde ich es aber schon einigermaßen seltsam, dass man
> einerseits .eml-Anhänge zurückweist, .doc aber akzeptiert. (.doc kann
> (schad-)makro-versucht sein, das neuere .docx hingegen nicht.)
dort) ist auf mehreren Ebenen und in mehreren Aspekten "einigermaßen
seltsam"...
Mit freundlichem Gruß,
Henning
--
In practise there is.
Yogi Beer
Alexander Ausserstorfer
Dec 21, 2022, 2:04:07 AM12/21/22
to
In article <tnpje7$drb$1...@sirius.aeon.icebear.cloud>,
sondern z. B. auch hexdezimale Werte darstellen können. Weiß vielleicht
nicht jeder.
> Alexander, herzlichen Dank für den Beitrag, der im Zweifelsfall anderen
> weiter hilft.
> Was Du schreibst, ist mir zum einen klar, zum anderen und insbesondere
> mein Reden. Ganz besonders, weil sich beim "Mail-Attachment-Typ" die
> Schlange ja in den Schwanz beißt: Wenn ich eh gerade eine Mail
> analysiere, warum kann ich dann nicht eine an diese Mail angehängte Mail
> analysieren. Ja, natürlich nur bis zu einer gewissen Tiefe, weil
> ansonsten die Vermutung einer Mailbombe nicht mehr ganz abwegig ist
> aber grundsätzlich ja schon.
Vielleicht noch ein konkretes Beispiel von mir zu diesem Thema.
Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von mir
'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
Aufwand betreiben möchte):
Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
zum Beispiel folgende Zeile:
- --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
Content-Transfer-Encoding: BASE64
Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
Zeilen eigentlich
--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
Content-Transfer-Encoding: BASE64
lauten müßten. Da ist also ein Strich zuviel.
Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar nichts
an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil nichts
angezeigt wird! Wie kommen die Leute denn auf solche Aussagen?
Es waren Leute mit Linux und FreeBSD darunter. Ich habe denen dann
mitgeteilt, daß sie den ersten Strich in der entsprechenden Zeile
entfernen müssen. Natürlich stimmt dann die Signatur nicht mehr. Aber -
oh Wunder! - plötzlich konnten ihre E-Mail-Programme die E-Mail
anzeigen!
Nun habe ich mit Computern eigentlich nicht viel am Hut und bin schon
froh, wenn ich überhaupt den Ein- oder Ausschaltknopf finde. Aber
manchmal muß man halt von Hand eingreifen, wenn etwas nicht
funktioniert. Man muß die Dinge halt zerlegen und den Fehler eingrenzen.
Nur schien das außer mir niemand gemacht zu haben. Das gab mir schon zu
denken.
Den Programmfehler zu finden, das ist jedoch ein ganz anderes Thema.
Gruß,
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
> > [...]
> > Die Dateinamenserweiterungen sind nichtssagend. Üblicherweise läßt man
> > sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
> > was das ist. Passieren kann dabei _rein gar nichts _.
> > [...]
!StrongEd oder !Zap sind (Programmier)Editoren, welche nicht nur ASCII,
> Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
> > [...]
> > Die Dateinamenserweiterungen sind nichtssagend. Üblicherweise läßt man
> > sie auf !StrongEd oder !Zap fallen und sieht einfach nach, also rein,
> > was das ist. Passieren kann dabei _rein gar nichts _.
> > [...]
sondern z. B. auch hexdezimale Werte darstellen können. Weiß vielleicht
nicht jeder.
> Alexander, herzlichen Dank für den Beitrag, der im Zweifelsfall anderen
> weiter hilft.
> Was Du schreibst, ist mir zum einen klar, zum anderen und insbesondere
> mein Reden. Ganz besonders, weil sich beim "Mail-Attachment-Typ" die
> Schlange ja in den Schwanz beißt: Wenn ich eh gerade eine Mail
> analysiere, warum kann ich dann nicht eine an diese Mail angehängte Mail
> analysieren. Ja, natürlich nur bis zu einer gewissen Tiefe, weil
> ansonsten die Vermutung einer Mailbombe nicht mehr ganz abwegig ist
> aber grundsätzlich ja schon.
Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von mir
'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
Aufwand betreiben möchte):
Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
zum Beispiel folgende Zeile:
- --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
Content-Transfer-Encoding: BASE64
Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
Zeilen eigentlich
--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
Content-Transfer-Encoding: BASE64
lauten müßten. Da ist also ein Strich zuviel.
Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar nichts
an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil nichts
angezeigt wird! Wie kommen die Leute denn auf solche Aussagen?
Es waren Leute mit Linux und FreeBSD darunter. Ich habe denen dann
mitgeteilt, daß sie den ersten Strich in der entsprechenden Zeile
entfernen müssen. Natürlich stimmt dann die Signatur nicht mehr. Aber -
oh Wunder! - plötzlich konnten ihre E-Mail-Programme die E-Mail
anzeigen!
Nun habe ich mit Computern eigentlich nicht viel am Hut und bin schon
froh, wenn ich überhaupt den Ein- oder Ausschaltknopf finde. Aber
manchmal muß man halt von Hand eingreifen, wenn etwas nicht
funktioniert. Man muß die Dinge halt zerlegen und den Fehler eingrenzen.
Nur schien das außer mir niemand gemacht zu haben. Das gab mir schon zu
denken.
Den Programmfehler zu finden, das ist jedoch ein ganz anderes Thema.
Gruß,
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Stefan Froehlich
Dec 21, 2022, 11:02:56 AM12/21/22
to
On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
> Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von
> mir 'leer' wäre. [...]
> Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von
> Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
> zum Beispiel folgende Zeile:
>
> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
> Zeilen eigentlich
>
> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> lauten müßten. Da ist also ein Strich zuviel.
> Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
> E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
> nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
> nichts angezeigt wird! Wie kommen die Leute denn auf solche
> Aussagen?
Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
Selbst in der IT wird nur eine Minderheit dazu in der Lage sein, und
auch da stellt sich die Frage: Wie kommen die denn eigentlich dazu?
> Nun habe ich mit Computern eigentlich nicht viel am Hut und bin
> schon froh, wenn ich überhaupt den Ein- oder Ausschaltknopf finde.
> Aber manchmal muß man halt von Hand eingreifen, wenn etwas nicht
> funktioniert. Man muß die Dinge halt zerlegen und den Fehler
> eingrenzen. Nur schien das außer mir niemand gemacht zu haben.
> Das gab mir schon zu denken.
ist. Wenn mir ein zu cholerischen Anfällen neigender Kunde so etwas
schickt, werde ich vermutlich den Fehler suchen, finden und
stillschweigend beheben, um ihn bloß nicht aufzuregen. Bei weniger
dramatischen Fällen werde ich "Deine Mail ist kaputt"
zurückschreiben und den Aufwand zur Lösung des Problems damit zu
demjenigen weiterschieben, der es verursacht hat. Soll sich der doch
um bessere Software umsehen.
Bei Menschen, mit denen mich weiter nichts verbindet, würde ich
solche Emails evt. auch einfach ungelesen löschen.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Alexander Ausserstorfer
Dec 23, 2022, 2:02:33 AM12/23/22
to
In article <1t63a32d07i3bdc91n3e8%sfro...@Froehlich.Priv.at>,
???????????????
Davon verstehe ich nichts. Den Begriff kenne ich nicht. Und trotzdem
bekam ich durch einen schnellen Vergleich heraus, woran es hakt. Und
obwohl ich nicht einmal deren Systeme kenne, konnte ich ihnen mitteilen,
was sie machen müssen, damit ihre Programme die E-Mail verarbeiten
können. Das hat dann ja auch funktioniert.
Ich will daher 'mal behaupten, daß Deine Aussage so falsch ist.
> Selbst in der IT wird nur eine Minderheit dazu in der Lage sein, und
> auch da stellt sich die Frage: Wie kommen die denn eigentlich dazu?
Was weiß ich. Aber vielleicht handelt es sich um jene Leute, die noch
die Happy Computer oder sowas in der Art bezogen. Heutzutage gibt es
sowas ja leider nicht mehr. Wobei wir damit jetzt wohl genau wieder bei
dem Thema zurück sind, um was es hier ursprünglich ja ging. Wer oder was
fördert eigentlich solche Kenntnisse oder Fähigkeiten? Die Computerbild?
Ich meine aber, um einen einfachen Text- oder Programmiereditor zu
verwenden, braucht man doch keine besonderen Fähigkeiten oder
Kenntnisse!
> Soll sich der doch um bessere Software umsehen.
Das ist einfach gesagt. Für RISC OS gibt es nicht soviele Programme.
Allerdings mage ich das System recht gerne, weil es sehr praktisch und
recht durchschaubar ist.
Und: Was ist besser? Muß das ganz automatisch das sein, was der
überwiegende Teil der Menschheit verwendet oder tut oder denkt? Das
halte ich nicht nur für falsch, sondern vor allem auch für hochnäsig,
vorurteilsbehaftet.
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
>>
>> Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
>> E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
>> nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
>> nichts angezeigt wird! Wie kommen die Leute denn auf solche
>> Aussagen?
> Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
> Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
^^^^^^^^^^^^^^^
> On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
>>
>> Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
>> E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
>> nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
>> nichts angezeigt wird! Wie kommen die Leute denn auf solche
>> Aussagen?
> Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
> Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
???????????????
Davon verstehe ich nichts. Den Begriff kenne ich nicht. Und trotzdem
bekam ich durch einen schnellen Vergleich heraus, woran es hakt. Und
obwohl ich nicht einmal deren Systeme kenne, konnte ich ihnen mitteilen,
was sie machen müssen, damit ihre Programme die E-Mail verarbeiten
können. Das hat dann ja auch funktioniert.
Ich will daher 'mal behaupten, daß Deine Aussage so falsch ist.
> Selbst in der IT wird nur eine Minderheit dazu in der Lage sein, und
> auch da stellt sich die Frage: Wie kommen die denn eigentlich dazu?
die Happy Computer oder sowas in der Art bezogen. Heutzutage gibt es
sowas ja leider nicht mehr. Wobei wir damit jetzt wohl genau wieder bei
dem Thema zurück sind, um was es hier ursprünglich ja ging. Wer oder was
fördert eigentlich solche Kenntnisse oder Fähigkeiten? Die Computerbild?
Ich meine aber, um einen einfachen Text- oder Programmiereditor zu
verwenden, braucht man doch keine besonderen Fähigkeiten oder
Kenntnisse!
> Soll sich der doch um bessere Software umsehen.
Allerdings mage ich das System recht gerne, weil es sehr praktisch und
recht durchschaubar ist.
Und: Was ist besser? Muß das ganz automatisch das sein, was der
überwiegende Teil der Menschheit verwendet oder tut oder denkt? Das
halte ich nicht nur für falsch, sondern vor allem auch für hochnäsig,
vorurteilsbehaftet.
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Michael Bäuerle
Dec 23, 2022, 4:37:25 AM12/23/22
to
Alexander Ausserstorfer wrote:
> In article <1t63a32d07i3bdc91n3e8%sfro...@Froehlich.Priv.at>,
> Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> > On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
> > >
> > > Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
> > > Zeilen eigentlich
> > >
> > > --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> > > Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> > > Content-Transfer-Encoding: BASE64
> > >
> > > lauten müßten. Da ist also ein Strich zuviel.
> > >
> > > Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
> > > E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
> > > nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
> > > nichts angezeigt wird! Wie kommen die Leute denn auf solche
> > > Aussagen?
>
> > Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
> > Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
> ^^^^^^^^^^^^^^^
> ???????????????
>
> Davon verstehe ich nichts. Den Begriff kenne ich nicht.
MIME steht für "Multipurpose Internet Mail Extensions".
> In article <1t63a32d07i3bdc91n3e8%sfro...@Froehlich.Priv.at>,
> Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> > On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
> > >
> > > Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
> > > Zeilen eigentlich
> > >
> > > --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> > > Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> > > Content-Transfer-Encoding: BASE64
> > >
> > > lauten müßten. Da ist also ein Strich zuviel.
> > >
> > > Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
> > > E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
> > > nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
> > > nichts angezeigt wird! Wie kommen die Leute denn auf solche
> > > Aussagen?
>
> > Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
> > Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
> ^^^^^^^^^^^^^^^
> ???????????????
>
> Davon verstehe ich nichts. Den Begriff kenne ich nicht.
Siehe: <https://www.rfc-editor.org/rfc/rfc2045>
Mit Container ist hier eine "entity" vom Typ "multipart" gemeint.
Diese kann mehrere Teile enthalten, die durch eine "boundary" getrennt
werden: <https://www.rfc-editor.org/rfc/rfc2046#section-5.1>
|
| [...]
| The Content-Type field for multipart entities requires one parameter,
| "boundary". The boundary delimiter line is then defined as a line
| consisting entirely of two hyphen characters ("-", decimal value 45)
| followed by the boundary parameter value from the Content-Type header
| field, optional linear whitespace, and a terminating CRLF.
Vor der deklarierten "boundary" müssen immer zwei Bindestriche bzw.
Minuszeichen ("--") stehen, wie du oben richtig erkannt hast.
| [...]
| The boundary delimiter line following the last body part is a
| distinguished delimiter that indicates that no further body parts
| will follow. Such a delimiter line is identical to the previous
| delimiter lines, with the addition of two more hyphens after the
| boundary parameter value.
Wenn diese Verpackung nicht richtig gemacht wird, kann die Software
des Empfängers den Inhalt ggf. nicht anzeigen bzw. extrahieren.
Stefan Froehlich
Dec 23, 2022, 5:40:29 AM12/23/22
to
On Fri, 23 Dec 2022 07:22:06 Alexander Ausserstorfer wrote:
> In article <1t63a32d07i3bdc91n3e8%sfro...@Froehlich.Priv.at>,
> Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
>>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf,
>>> daß die Zeilen eigentlich
>>>
>>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>>> Content-Transfer-Encoding: BASE64
>>>
>>> lauten müßten. Da ist also ein Strich zuviel.
>>>
>>> Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
>>> E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
>>> nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
>>> nichts angezeigt wird! Wie kommen die Leute denn auf solche
>>> Aussagen?
>
>> Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
>> Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
> ^^^^^^^^^^^^^^^
> ???????????????
>
> Davon verstehe ich nichts. Den Begriff kenne ich nicht. Und
> trotzdem bekam ich durch einen schnellen Vergleich heraus, woran
> es hakt.
Du schaffst das, ich schaffe das. 90% der Benutzer wüssten nicht
> In article <1t63a32d07i3bdc91n3e8%sfro...@Froehlich.Priv.at>,
> Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Wed, 21 Dec 2022 07:30:04 Alexander Ausserstorfer wrote:
>>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf,
>>> daß die Zeilen eigentlich
>>>
>>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>>> Content-Transfer-Encoding: BASE64
>>>
>>> lauten müßten. Da ist also ein Strich zuviel.
>>>
>>> Nun kann !Pluto solche E-Mails problemlos verarbeiten. Andere
>>> E-Mail-Programme haben aber ihre Probleme damit. Sie zeigen gar
>>> nichts an. Das heißt aber nicht, daß die E-Mail leer ist! Nur weil
>>> nichts angezeigt wird! Wie kommen die Leute denn auf solche
>>> Aussagen?
>
>> Von den Empfängern seiner Emails zu erwarten, dass sie sich mit den
>> Details von MIME-Containern auseinandersetzen ist schon sehr mutig.
> ^^^^^^^^^^^^^^^
> ???????????????
>
> Davon verstehe ich nichts. Den Begriff kenne ich nicht. Und
> trotzdem bekam ich durch einen schnellen Vergleich heraus, woran
> es hakt.
einmal, wie sie ihre Mail als Plaintext anzeigen und noch weniger,
wie sie den ändern könnten - falls das überhaupt möglich ist.
> Wobei wir damit jetzt wohl genau wieder bei dem Thema zurück sind,
> um was es hier ursprünglich ja ging. Wer oder was fördert
> eigentlich solche Kenntnisse oder Fähigkeiten? Die Computerbild?
spannend; aber ich habe halt auch eine MIME-Bibliothek für den
Eigenbedarf programmiert. Es ist vollkommen akzeptabel, wenn sich
jemand *solche* Klimmzüge nicht antun möchte und umgekehrt eher
impertinent, das als Sender vom Empfänger zu erwarten.
>> Soll sich der doch um bessere Software umsehen.
> Das ist einfach gesagt. Für RISC OS gibt es nicht soviele
> Programme. Allerdings mage ich das System recht gerne, weil es
> sehr praktisch und recht durchschaubar ist.
dafür Klimmzüge nötig. Wenig charmant.
> Und: Was ist besser? Muß das ganz automatisch das sein, was der
> überwiegende Teil der Menschheit verwendet oder tut oder denkt?
> Das halte ich nicht nur für falsch, sondern vor allem auch für
> hochnäsig, vorurteilsbehaftet.
wirklich guten Grund dafür haben.
Im übrigen finde ich es höchst irritierend, wenn sich Software so
wie von Dir beschrieben verhält. Das hätte schon längst als
katastrophaler Bug auffallen müssen, weshalb die Vermutung
naheliegt, dass entweder die Konfiguration kaputt ist oder sonst
noch jemand seine Finger im Spiel hat. Dem nachzugehen fände ich
höchst sinnvoll.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Henning Hucke
Dec 23, 2022, 11:37:46 AM12/23/22
to
Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
Hallo Alexander,
> [...]
Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
(!)
boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
definiert hat, dann ist "- --..." definitiv der flasche
MIME-Part-Trenner aber "--..." ist regelrecht kaputt. Letzteres wird nur
aus dem Grund funktionieren, weil sich die Entwickler anderer Software
augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
what you emit and as tollerant as necessary in what you accept." gehalten
haben.
Außerdem fehlt mir noch die MIME Part Closure "--<boundary>--\n". Das
korrekte MIME Part Opening wäre "--<boundary>\n".
Inkorrekt sind beide Sachen. Siehe RFCs 204{5,6,7,8,9}.
> [...]
Mit freundlichem Gruß,
Henning
--
Hallo Alexander,
> [...]
> Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von mir
> 'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
> festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
> folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
> Aufwand betreiben möchte):
>
> Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
> zum Beispiel folgende Zeile:
>
> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
> Zeilen eigentlich
>
> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> lauten müßten. Da ist also ein Strich zuviel.
erm... Wie Radio Erivan sagen würde: "So in etwa aber auch nur fast.".
> 'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
> festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
> folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
> Aufwand betreiben möchte):
>
> Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
> zum Beispiel folgende Zeile:
>
> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
> Zeilen eigentlich
>
> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
> Content-Transfer-Encoding: BASE64
>
> lauten müßten. Da ist also ein Strich zuviel.
Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
(!)
boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
definiert hat, dann ist "- --..." definitiv der flasche
MIME-Part-Trenner aber "--..." ist regelrecht kaputt. Letzteres wird nur
aus dem Grund funktionieren, weil sich die Entwickler anderer Software
augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
what you emit and as tollerant as necessary in what you accept." gehalten
haben.
Außerdem fehlt mir noch die MIME Part Closure "--<boundary>--\n". Das
korrekte MIME Part Opening wäre "--<boundary>\n".
Inkorrekt sind beide Sachen. Siehe RFCs 204{5,6,7,8,9}.
> [...]
Mit freundlichem Gruß,
Henning
--
Eike Rathke
Dec 23, 2022, 1:46:49 PM12/23/22
to
* Henning Hucke, 2022-12-23 15:41 UTC:
>> ergibt sich in den E-Mails
>> zum Beispiel folgende Zeile:
>>
>> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
Nein.
Leider unterschlägt der OP, wie genau mit gpg signiert wird und ob und
wenn welche Content-Type Header es einfügt und was vielleicht noch von
Belang in der message wäre, aber aus dem Kontext nehme ich an, dass es
oldstyle inline PGP signature ist.
> erm... Wie Radio Erivan sagen würde: "So in etwa aber auch nur fast.".
> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
> (!)
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
Wenn schon, dann müsste es boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
*ohne* die "--" definieren ...
> definiert hat, dann ist "- --..." definitiv der flasche
> MIME-Part-Trenner aber "--..." ist regelrecht kaputt.
... dann waere "--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP" als Trenner korrekt.
*Aber* wenn so ein MIME-Multipart eine oldstyle PGP inline Signatur
bekommt, dann wird daraus korrekterweise
- --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
weil der gesamte Datenteil inklusive der boundaries signiert ein Block
ist, und etwaige "--..." Trenner mit "- --..." escaped werden weil
inline clear-sign selber diese Header und Trenner hat:
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Siehe https://www.rfc-editor.org/rfc/rfc4880#section-7 und
https://www.rfc-editor.org/rfc/rfc4880#section-7.1
Wenn der empfangende MUA das als leer darstellt, dann ist der natürlich
kaputt, aber inline PGP über MIME-Multipart *kann* nicht funktionieren
wenn ein empfangender MUA nicht so schlau ist das "zurückzuunescapen".
> Letzteres wird nur
> aus dem Grund funktionieren, weil sich die Entwickler anderer Software
> augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
> what you emit and as tollerant as necessary in what you accept." gehalten
> haben.
Naja. Das ist halt RFC 4880. Was aber nicht dafür gedacht ist ("Note
that this framework is not intended to be reversible") MIME zu kapseln.
Wenn statt des seit 15 Jahren praxisgemäß deprecated oldstyle inline PGP
signature Quatsch ein anständiges PGP/MIME signature verwendet werden
würde, dann würden nested MIME multipart entstehen und alles wäre gut.
Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
> Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
>> Wenn man mit !Pluto und gpg E-Mails signiert,
Das "mit gpg signiert" ist hier relevant.
>> Wenn man mit !Pluto und gpg E-Mails signiert,
>> ergibt sich in den E-Mails
>> zum Beispiel folgende Zeile:
>>
>> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
Leider unterschlägt der OP, wie genau mit gpg signiert wird und ob und
wenn welche Content-Type Header es einfügt und was vielleicht noch von
Belang in der message wäre, aber aus dem Kontext nehme ich an, dass es
oldstyle inline PGP signature ist.
> erm... Wie Radio Erivan sagen würde: "So in etwa aber auch nur fast.".
> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
> (!)
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
*ohne* die "--" definieren ...
> definiert hat, dann ist "- --..." definitiv der flasche
> MIME-Part-Trenner aber "--..." ist regelrecht kaputt.
*Aber* wenn so ein MIME-Multipart eine oldstyle PGP inline Signatur
bekommt, dann wird daraus korrekterweise
- --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
weil der gesamte Datenteil inklusive der boundaries signiert ein Block
ist, und etwaige "--..." Trenner mit "- --..." escaped werden weil
inline clear-sign selber diese Header und Trenner hat:
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Siehe https://www.rfc-editor.org/rfc/rfc4880#section-7 und
https://www.rfc-editor.org/rfc/rfc4880#section-7.1
Wenn der empfangende MUA das als leer darstellt, dann ist der natürlich
kaputt, aber inline PGP über MIME-Multipart *kann* nicht funktionieren
wenn ein empfangender MUA nicht so schlau ist das "zurückzuunescapen".
> Letzteres wird nur
> aus dem Grund funktionieren, weil sich die Entwickler anderer Software
> augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
> what you emit and as tollerant as necessary in what you accept." gehalten
> haben.
that this framework is not intended to be reversible") MIME zu kapseln.
Wenn statt des seit 15 Jahren praxisgemäß deprecated oldstyle inline PGP
signature Quatsch ein anständiges PGP/MIME signature verwendet werden
würde, dann würden nested MIME multipart entstehen und alles wäre gut.
Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Alexander Ausserstorfer
Dec 24, 2022, 1:33:10 AM12/24/22
to
Am 23.12.2022 um 11:40 schrieb Stefan Froehlich
> Es ist vollkommen akzeptabel, wenn sich jemand *solche* Klimmzüge
> nicht antun möchte und umgekehrt eher impertinent, das als Sender vom
> Empfänger zu erwarten.
Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich erwarte
schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
behauptet wurde) oder einfach schlicht nicht angezeigt wurde. Wie kann
denn eine E-Mail leer sein, wenn sie mehrere hundert Kilobyte groß ist?
Das ist mehr als unlogisch. Man braucht sich die Sachen ja nur
anzusehen. Mehr ist das ja schließlich nicht.
> Im übrigen finde ich es höchst irritierend, wenn sich Software so wie
> von Dir beschrieben verhält. Das hätte schon längst als
> katastrophaler Bug auffallen müssen, weshalb die Vermutung naheliegt,
> dass entweder die Konfiguration kaputt ist oder sonst noch jemand
> seine Finger im Spiel hat.
Oder GPG wurde damit einfach nie wirklich von jemanden genutzt. Ich
kenne aber auch fast niemanden, der es eigentlich nutzt. Den meisten
Menschen scheint es völlig egal zu sein, wenn ihre E-Mails in Klartext
übertragen werden. Daß sie so aber von Computerprogrammen völlig
problemlos durchgeschaut werden können, sollte doch jedem klar sein.
A.
> Es ist vollkommen akzeptabel, wenn sich jemand *solche* Klimmzüge
> nicht antun möchte und umgekehrt eher impertinent, das als Sender vom
> Empfänger zu erwarten.
schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
behauptet wurde) oder einfach schlicht nicht angezeigt wurde. Wie kann
denn eine E-Mail leer sein, wenn sie mehrere hundert Kilobyte groß ist?
Das ist mehr als unlogisch. Man braucht sich die Sachen ja nur
anzusehen. Mehr ist das ja schließlich nicht.
> Im übrigen finde ich es höchst irritierend, wenn sich Software so wie
> von Dir beschrieben verhält. Das hätte schon längst als
> katastrophaler Bug auffallen müssen, weshalb die Vermutung naheliegt,
> dass entweder die Konfiguration kaputt ist oder sonst noch jemand
> seine Finger im Spiel hat.
kenne aber auch fast niemanden, der es eigentlich nutzt. Den meisten
Menschen scheint es völlig egal zu sein, wenn ihre E-Mails in Klartext
übertragen werden. Daß sie so aber von Computerprogrammen völlig
problemlos durchgeschaut werden können, sollte doch jedem klar sein.
A.
Alexander Ausserstorfer
Dec 24, 2022, 1:44:30 AM12/24/22
to
Hallo Henning,
Am 23.12.2022 um 16:41 schrieb Henning Hucke:
> Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
>
>> [...]
>> Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von mir
>> 'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
>> festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
>> folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
>> Aufwand betreiben möchte):
>>
>> Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
>> zum Beispiel folgende Zeile:
>>
>> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
>
> erm... Wie Radio Erivan sagen würde: "So in etwa aber auch nur fast.".
>
> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
> definiert ist. Wenn "!Pluto" - was auch immer das sein mag
Kannst ja gerne 'mal ausprobieren:
http://www.avisoft.f9.co.uk/pluto/index.htm
- hoffentlich
> (!)
>
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> definiert hat, dann ist "- --..." definitiv der flasche
> MIME-Part-Trenner aber "--..." ist regelrecht kaputt. Letzteres wird nur
> aus dem Grund funktionieren, weil sich die Entwickler anderer Software
> augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
> what you emit and as tollerant as necessary in what you accept." gehalten
> haben.
>
> Außerdem fehlt mir noch die MIME Part Closure "--<boundary>--\n". Das
> korrekte MIME Part Opening wäre "--<boundary>\n".
>
> Inkorrekt sind beide Sachen. Siehe RFCs 204{5,6,7,8,9}.
>
>> [...]
vielen Dank für die Hinweise (auch von den anderen). Den Quelltext von
!Pluto habe ich mittlerweile da. Da habe ich wohl noch viel Arbeit vor
mir, zumal ich kein Programmierer bin und mich da eigentlich auch gar
nicht auskenne. Schrieb bisher nur einige kleinere Programme in BASIC
wie POKE 53281,0 oder sowas in der Art. Aber irgendwie will da bisher
niemand was tun. Dann muß man halt leider wieder selbst Hand anlegen und
durch's Feuer gehen. Die Computergeschäfte wollen einem sowieso nie
helfen und was reparieren. Ach, es ist doch immer dasselbe.
Danke & ciao,
A.
Am 23.12.2022 um 16:41 schrieb Henning Hucke:
> Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
>
>> [...]
>> Einige Leute hatten sich bei mir beschwert, daß eine E-Mail von mir
>> 'leer' wäre. Ich habe die entsprechende E-Mail angeschaut und
>> festgestellt, daß sie überhaupt nicht leer ist. Das Problem ist
>> folgendes (und kann jeder nachvollziehen, wenn er den entsprechenden
>> Aufwand betreiben möchte):
>>
>> Wenn man mit !Pluto und gpg E-Mails signiert, ergibt sich in den E-Mails
>> zum Beispiel folgende Zeile:
>>
>> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> Durch Vergleich mit E-Mails aus anderen Programmen fiel mir auf, daß die
>> Zeilen eigentlich
>>
>> --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>> Content-Type: image/jpeg; Name="Bauparzelle_Grub.JPG"
>> Content-Transfer-Encoding: BASE64
>>
>> lauten müßten. Da ist also ein Strich zuviel.
>
> erm... Wie Radio Erivan sagen würde: "So in etwa aber auch nur fast.".
>
> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
> definiert ist. Wenn "!Pluto" - was auch immer das sein mag
http://www.avisoft.f9.co.uk/pluto/index.htm
- hoffentlich
> (!)
>
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> definiert hat, dann ist "- --..." definitiv der flasche
> MIME-Part-Trenner aber "--..." ist regelrecht kaputt. Letzteres wird nur
> aus dem Grund funktionieren, weil sich die Entwickler anderer Software
> augenscheinlich "passend" an das RFC-Motto "Be as precise as possible in
> what you emit and as tollerant as necessary in what you accept." gehalten
> haben.
>
> Außerdem fehlt mir noch die MIME Part Closure "--<boundary>--\n". Das
> korrekte MIME Part Opening wäre "--<boundary>\n".
>
> Inkorrekt sind beide Sachen. Siehe RFCs 204{5,6,7,8,9}.
>
>> [...]
!Pluto habe ich mittlerweile da. Da habe ich wohl noch viel Arbeit vor
mir, zumal ich kein Programmierer bin und mich da eigentlich auch gar
nicht auskenne. Schrieb bisher nur einige kleinere Programme in BASIC
wie POKE 53281,0 oder sowas in der Art. Aber irgendwie will da bisher
niemand was tun. Dann muß man halt leider wieder selbst Hand anlegen und
durch's Feuer gehen. Die Computergeschäfte wollen einem sowieso nie
helfen und was reparieren. Ach, es ist doch immer dasselbe.
Danke & ciao,
A.
Laurenz Trossel
Dec 24, 2022, 8:26:21 AM12/24/22
to
On 2022-12-24, Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich erwarte
> schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
> behauptet wurde) oder einfach schlicht nicht angezeigt wurde.
Wenn du defekte Mails verschickst, ist das dein Problem. Nicht das des
> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich erwarte
> schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
> behauptet wurde) oder einfach schlicht nicht angezeigt wurde.
Empfängers.
Viele in Unternehmen eingesetzte Mailsysteme erlauben den Empfängern nicht,
an Metadaten herumzufummeln (oder diese überhaupt zu sehen).
> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
kompliziert, inkompatibel und nutzlos.
> Den meisten
> Menschen scheint es völlig egal zu sein, wenn ihre E-Mails in Klartext
> übertragen werden.
der Regel verschlüsselt.
> Daß sie so aber von Computerprogrammen völlig
> problemlos durchgeschaut werden können, sollte doch jedem klar sein.
Gebiet wärst.
Helmut Waitzmann
Dec 25, 2022, 12:27:58 PM12/25/22
to
Alexander Ausserstorfer <bavari...@chiemgau-net.de>:
technisch betrachtet, nicht leer: Allein der Nachrichtenvorspann
ist immer vorhanden. Trotzdem kann es sein, dass der Empfänger
keinen Inhalt sehen kann. Ob in der Nachricht nichts zu
sehen ist, weil sie außer der Verwaltungsinformation keinen
weiteren Inhalt enthält oder weil der weitere Inhalt defekt ist,
können viele Empfänger heutzutage nicht entscheiden.
Ob die Verwaltungsinformation einer Nachricht nun wenige oder
mehrere hundert Kilobyte groß sein kann, können heutzutage
ebenfalls nicht mehr viele Empfänger richtig einschätzen.
Verschicke beispielsweise ein vom Scanner erhaltenes Photo, das
nur ein weißes leeres Blatt Papier darstellt. Die Nachricht wird
sicher Nutzdaten enthalten, aber für den technisch unbeleckten
Empfänger trotzdem leer aussehen.
> Man braucht sich die Sachen ja nur anzusehen. Mehr ist das ja
> schließlich nicht.
Schon. Aber ohne Fachwissen kann man nicht unterscheiden, welcher
Teil der Nachricht nun Verwaltungsinformation ist und welcher
Nachrichteninhalt ist.
>
>> Im übrigen finde ich es höchst irritierend, wenn sich Software
>> so wie von Dir beschrieben verhält. Das hätte schon längst als
>> katastrophaler Bug auffallen müssen, weshalb die Vermutung
>> naheliegt, dass entweder die Konfiguration kaputt ist oder
>> sonst noch jemand seine Finger im Spiel hat.
>
> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
>
Du solltest dem Fehler nachgehen. Ich vermute zunächst mal eine
Fehlkonfiguration beim Zusammenspiel von GPG und dem
Mailerprogramm.
> Ich kenne aber auch fast niemanden, der es eigentlich nutzt. Den
> meisten Menschen scheint es völlig egal zu sein, wenn ihre
> E-Mails in Klartext übertragen werden. Daß sie so aber von
> Computerprogrammen völlig problemlos durchgeschaut werden
> können, sollte doch jedem klar sein.
Recht hast du, und schön wär's, wenn das Wissen allgemein bekannt
wäre.
Ich habe beispielsweise kürzlich jemandem (geschäftlich)
geschrieben, dass ich meine Nachrichten gerne digital signieren
würde, um Herkunfts‐ und Fälschungssicherheit zu haben.
Als Antwort erhielt ich den Vorschlag, die Personalnummer
hinzuzufügen, dann könne meine Nachricht zweifelsfrei mir
zugeordnet werden.
Internetführerschein jetzt! Ein wesentlicher Inhalt müsste sein,
ein (einfaches) Exemplar an Malware zu bauen und eine
E‐Mail‐Nachricht mit falschem Absender zu verschicken. Wenn man
nicht selber irgendeine Form von Digitalbetrug gemacht hat,
glaubt man nicht, dass das möglich ist.
> Am 23.12.2022 um 11:40 schrieb Stefan Froehlich
>
>> Es ist vollkommen akzeptabel, wenn sich jemand *solche*
>> Klimmzüge nicht antun möchte und umgekehrt eher impertinent,
>> das als Sender vom Empfänger zu erwarten.
>
> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich
> erwarte schon, daß jemand unterscheiden kann, ob da eine E-Mail
> "leer" ist (wie behauptet wurde) oder einfach schlicht nicht
> angezeigt wurde. Wie kann denn eine E-Mail leer sein, wenn sie
> mehrere hundert Kilobyte groß ist? Das ist mehr als unlogisch.
Das ist es heutzutage leider nicht mehr. Jede Nachricht ist,
>
>> Es ist vollkommen akzeptabel, wenn sich jemand *solche*
>> Klimmzüge nicht antun möchte und umgekehrt eher impertinent,
>> das als Sender vom Empfänger zu erwarten.
>
> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich
> erwarte schon, daß jemand unterscheiden kann, ob da eine E-Mail
> "leer" ist (wie behauptet wurde) oder einfach schlicht nicht
> angezeigt wurde. Wie kann denn eine E-Mail leer sein, wenn sie
> mehrere hundert Kilobyte groß ist? Das ist mehr als unlogisch.
technisch betrachtet, nicht leer: Allein der Nachrichtenvorspann
ist immer vorhanden. Trotzdem kann es sein, dass der Empfänger
keinen Inhalt sehen kann. Ob in der Nachricht nichts zu
sehen ist, weil sie außer der Verwaltungsinformation keinen
weiteren Inhalt enthält oder weil der weitere Inhalt defekt ist,
können viele Empfänger heutzutage nicht entscheiden.
Ob die Verwaltungsinformation einer Nachricht nun wenige oder
mehrere hundert Kilobyte groß sein kann, können heutzutage
ebenfalls nicht mehr viele Empfänger richtig einschätzen.
Verschicke beispielsweise ein vom Scanner erhaltenes Photo, das
nur ein weißes leeres Blatt Papier darstellt. Die Nachricht wird
sicher Nutzdaten enthalten, aber für den technisch unbeleckten
Empfänger trotzdem leer aussehen.
> Man braucht sich die Sachen ja nur anzusehen. Mehr ist das ja
> schließlich nicht.
Teil der Nachricht nun Verwaltungsinformation ist und welcher
Nachrichteninhalt ist.
>
>> Im übrigen finde ich es höchst irritierend, wenn sich Software
>> so wie von Dir beschrieben verhält. Das hätte schon längst als
>> katastrophaler Bug auffallen müssen, weshalb die Vermutung
>> naheliegt, dass entweder die Konfiguration kaputt ist oder
>> sonst noch jemand seine Finger im Spiel hat.
>
> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
>
Fehlkonfiguration beim Zusammenspiel von GPG und dem
Mailerprogramm.
> Ich kenne aber auch fast niemanden, der es eigentlich nutzt. Den
> meisten Menschen scheint es völlig egal zu sein, wenn ihre
> E-Mails in Klartext übertragen werden. Daß sie so aber von
> Computerprogrammen völlig problemlos durchgeschaut werden
> können, sollte doch jedem klar sein.
wäre.
Ich habe beispielsweise kürzlich jemandem (geschäftlich)
geschrieben, dass ich meine Nachrichten gerne digital signieren
würde, um Herkunfts‐ und Fälschungssicherheit zu haben.
Als Antwort erhielt ich den Vorschlag, die Personalnummer
hinzuzufügen, dann könne meine Nachricht zweifelsfrei mir
zugeordnet werden.
Internetführerschein jetzt! Ein wesentlicher Inhalt müsste sein,
ein (einfaches) Exemplar an Malware zu bauen und eine
E‐Mail‐Nachricht mit falschem Absender zu verschicken. Wenn man
nicht selber irgendeine Form von Digitalbetrug gemacht hat,
glaubt man nicht, dass das möglich ist.
Marc Haber
Dec 26, 2022, 3:20:09 AM12/26/22
to
Laurenz Trossel <m...@example.invalid> wrote:
>Viele in Unternehmen eingesetzte Mailsysteme erlauben den Empfängern nicht,
>an Metadaten herumzufummeln (oder diese überhaupt zu sehen).
Viele in Unternehmen eingesetzte Softwarepakete (insbesondere
>Viele in Unternehmen eingesetzte Mailsysteme erlauben den Empfängern nicht,
>an Metadaten herumzufummeln (oder diese überhaupt zu sehen).
Ticketsysteme und Systeme für Customer Relationship Management)
verschicken Mails, die technisch so unsauber und inkorrekt sind, dass
sie alle Alarmglocken im Spamfilter auslösen und am Endbenutzer
aussehen als wären sie auf Butterbrotpapier geschrieben.
Jeder Porno-Spammer bekommt das inzwischen sauberer hin.
Grüße
Marc
Alexander Ausserstorfer
Dec 26, 2022, 4:23:53 AM12/26/22
to
Am 24.12.2022 um 14:26 schrieb Laurenz Trossel:
> On 2022-12-24, Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
>
>> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich erwarte
>> schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
>> behauptet wurde) oder einfach schlicht nicht angezeigt wurde.
>
> Wenn du defekte Mails verschickst, ist das dein Problem. Nicht das des
> Empfängers.
Darum ging es nicht. Es war ein Beispiel. Es ging darum, warum viele
> On 2022-12-24, Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
>
>> Ich erwarte von niemanden, daß er einen Fehler erkennt. Aber ich erwarte
>> schon, daß jemand unterscheiden kann, ob da eine E-Mail "leer" ist (wie
>> behauptet wurde) oder einfach schlicht nicht angezeigt wurde.
>
> Wenn du defekte Mails verschickst, ist das dein Problem. Nicht das des
> Empfängers.
Leute heutzutage Computer verwenden, aber letzten Endes rein gar nichts
(mehr) davon verstehen.
> Viele in Unternehmen eingesetzte Mailsysteme erlauben den Empfängern nicht,
> an Metadaten herumzufummeln (oder diese überhaupt zu sehen).
Sache gar nicht mehr hingelassen und nur noch bevormundet wird. Das
halte ich für gefährlich. Aber anscheinend sind heutzutage leider
inzwischen viele Systeme so. Alles wird abgesperrt. Sowas möchte ich
nicht unbedingt verwenden müssen.
>> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
>
> Signaturen und Verschlüsselung in E-Mails sind ziemlich tot. Viel zu
> kompliziert, inkompatibel und nutzlos.
>> Den meisten
>> Menschen scheint es völlig egal zu sein, wenn ihre E-Mails in Klartext
>> übertragen werden.
>
> Werden sie nicht. Der Transport zwischen Mailservern erfolgt heutzutage in
> der Regel verschlüsselt.
auf den Mailservern liegen die E-Mails unverschlüsselt vor und werden
dadurch natürlich von Software gescannt und gefiltert. Das merke ich z.
B. bei meinem eigenen Provider. Man hat ständig Ärger, wenn man
Programme anhängen will, weil der die abschneidet (wenn man die Mails
nicht verschlüsselt). In einem Fall hat mein Provider die E-Mail einfach
nicht zugestellt. Das CAD-Programm vom Autor war nie bei mir angekommen.
Er hatte es mir dann per Post zugestellt. Erst, nachdem ich mich beim
Provider darüber beschwert hatte, führten die sowas wie einen
Spam-Ordner ein. Der aber nur umständlich über ein Webinterface
erreichbar ist.
Um sowas zu wissen, braucht man doch keinen Eduard Snowden. Was wollte
der jetzt eigentlich?
>> Daß sie so aber von Computerprogrammen völlig
>> problemlos durchgeschaut werden können, sollte doch jedem klar sein.
>
> Jaja. Du erweckst nicht gerade den Eindruck, daß du ein Experte auf dem
> Gebiet wärst.
wird, das weiß ich auch nicht. Darum ging es hier doch wohl eigentlich.
A.
Henning Hucke
Dec 27, 2022, 6:37:34 AM12/27/22
to
Eike Rathke <erack+nu...@posteo.de> wrote:
Hallo Eike,
> [...]
Freiheitsgrad (siehe auch entsprechende RFCs) und werden gerne mit
"zusätzlichen" Bindestrichen prefixed; zumindest ist so etwas legitim
und zulässig.
>> definiert hat, dann ist "- --..." definitiv der flasche
>> MIME-Part-Trenner aber "--..." ist regelrecht kaputt.
>
> ... dann waere "--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP" als Trenner korrekt.
Erm...
Bei einer Boundary
boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
wäre der MIME part introducer
----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
und der MIME part terminator
----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP--
bei einer anderen Boundary entsprechend anders.
> *Aber* wenn so ein MIME-Multipart eine oldstyle PGP inline Signatur
> bekommt, dann wird daraus korrekterweise
>
> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>
> weil der gesamte Datenteil inklusive der boundaries signiert ein Block
> ist, und etwaige "--..." Trenner mit "- --..." escaped werden weil
> inline clear-sign selber diese Header und Trenner hat:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> -----BEGIN PGP SIGNATURE-----
> -----END PGP SIGNATURE-----
Wohl wahr. Aber das alles hat dann als solches nichts mehr mit MIME zu
tun (sondern damit, wie inline PGP das escapet).
> [...]
Wir sind nicht auseinander, wie sprechen nur von unterschiedlichen
Sachen; u.a. weil der OP relevante Informationen nicht geliefert hat /
nicht liefern konnte.
MfG Henning
--
Applause, n:
The echo of a platitude from the mouth of a fool.
-- Ambrose Bierce
Hallo Eike,
> [...]
>> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
>> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
>> (!)
>
>> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> Wenn schon, dann müsste es boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
> *ohne* die "--" definieren ...
das ist eine nicht zutreffende Aussage. Boundaries haben einen hohen
>> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
>> (!)
>
>> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> Wenn schon, dann müsste es boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
> *ohne* die "--" definieren ...
Freiheitsgrad (siehe auch entsprechende RFCs) und werden gerne mit
"zusätzlichen" Bindestrichen prefixed; zumindest ist so etwas legitim
und zulässig.
>> definiert hat, dann ist "- --..." definitiv der flasche
>> MIME-Part-Trenner aber "--..." ist regelrecht kaputt.
>
> ... dann waere "--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP" als Trenner korrekt.
Bei einer Boundary
boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
wäre der MIME part introducer
----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
und der MIME part terminator
----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP--
bei einer anderen Boundary entsprechend anders.
> *Aber* wenn so ein MIME-Multipart eine oldstyle PGP inline Signatur
> bekommt, dann wird daraus korrekterweise
>
> - --5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
>
> weil der gesamte Datenteil inklusive der boundaries signiert ein Block
> ist, und etwaige "--..." Trenner mit "- --..." escaped werden weil
> inline clear-sign selber diese Header und Trenner hat:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> -----BEGIN PGP SIGNATURE-----
> -----END PGP SIGNATURE-----
tun (sondern damit, wie inline PGP das escapet).
> [...]
Wir sind nicht auseinander, wie sprechen nur von unterschiedlichen
Sachen; u.a. weil der OP relevante Informationen nicht geliefert hat /
nicht liefern konnte.
MfG Henning
--
Applause, n:
The echo of a platitude from the mouth of a fool.
-- Ambrose Bierce
Stefan Claas
Dec 27, 2022, 1:36:29 PM12/27/22
to
Alexander Ausserstorfer <bavari...@chiemgau-net.de> wrote:
> Am 24.12.2022 um 14:26 schrieb Laurenz Trossel:
> > On 2022-12-24, Alexander Ausserstorfer
> > <bavari...@chiemgau-net.de> wrote:
> >> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
> >
> > Signaturen und Verschlüsselung in E-Mails sind ziemlich tot. Viel zu
> > kompliziert, inkompatibel und nutzlos.
>
> Was gibt es für Alternativen?
Bitte nicht lachen ...
> Am 24.12.2022 um 14:26 schrieb Laurenz Trossel:
> > On 2022-12-24, Alexander Ausserstorfer
> > <bavari...@chiemgau-net.de> wrote:
> >> Oder GPG wurde damit einfach nie wirklich von jemanden genutzt.
> >
> > Signaturen und Verschlüsselung in E-Mails sind ziemlich tot. Viel zu
> > kompliziert, inkompatibel und nutzlos.
>
> Was gibt es für Alternativen?
Es reicht doch für vertrauliche email Kommunitaion, wo der Empfänger
wissen muss das der Sender auch der richtige ist und kein spam erhält,
kostenpflichtige oder kostenlose De-Mail[1] mit BSI zertifiziertem
Kartenleser und nPA aus und dazu ein eIDAS[2] zertifiziertes .pdf
Dokument, kostenpflichtig je nach Signaturstufe oder eben nicht.
Die Digitale Signatur ist dann rechtssicher und gleicht der einer
handschriftlichen, wie bei Verträgen usw. und den .pdf Inhalt kann
man mit seiner Wahl von Werkzeugen einfach verschlüsseln, bevor das
.pdf Dokument, eIDAS konform signiert und per De-Mail verssendet wird.
Solche eIDAS zertifizierten Dokumente kann man auch online[3]
überprüfen, falls man Linux Anwender ist und kein Adobe Reader hat.
Eigentlich alles eine prima Sache, für .de und EU, nur nutzen sollte man
es auch.
[1] https://www.fp-demail.de/
[2] https://cloud.sign-me.de/signature/start
[3]
<https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation>
https://digital-strategy.ec.europa.eu/en/policies/discover-eidas
Grüße
Stefan
Henning Hucke
Dec 28, 2022, 6:37:43 AM12/28/22
to
Stefan Claas <sace...@gmail.com> wrote:
> [...]
Es gibt inzwischen so viele Artikel, die u.a. gerade in diesem
Themenebereich die nicht nur schlecht umgesetzten, sondern regelrecht
als solche kaputten Konzepte beleuchten, dass zumindest ich über Deine
regelrechte Empfehlung von DE-Mail noch nicht mal mehr lachen kann.
Ich bin über die Jahre sogar über Artikel gestolpert, die sich sachlich
fundiert und realitätsbezogen /bemüht/ haben, DE-Mail als sinnvolle
aber noch nicht in den relevanten Bereichen vernünftig implementierte
Plattform zu identifizieren, /konnten/ aber nur meist kaputte Konzepte
und/oder von zureichend weit entfernte Implementationen konstatieren.
DE-Mail war (und ist damit weiterhin und es wird sich daran auch nichts
ändern, so lange "DE-Mail" in etwa das benamst, was es ursprünglich und
bisher war) eine Todgeburt mit Ansage und grandioser Bestätigung dieser
Ansage.
Warum ich nicht auf Dein(e) "Argument(e)" eingehe? Weil ich dann nur
Excerpts von Sachen schreiben könnte, deren Suche und Nachlesen /Dir/
deutlich weniger Aufwand abverlangen würde, als mir die Excerpts
zusammenzuschreiben.
Mit freundlichem Gruß,
Henning
PS: Sig was generated totally randomly...
--
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> [...]
>> > Signaturen und Verschlüsselung in E-Mails sind ziemlich tot. Viel zu
>> > kompliziert, inkompatibel und nutzlos.
>>
>> Was gibt es für Alternativen?
>
> Bitte nicht lachen ...
>
> Es reicht doch für vertrauliche email Kommunitaion, wo der Empfänger
> wissen muss das der Sender auch der richtige ist und kein spam erhält,
> kostenpflichtige oder kostenlose De-Mail[1] mit BSI zertifiziertem
> Kartenleser und nPA aus und dazu ein eIDAS[2] zertifiziertes .pdf
> Dokument, kostenpflichtig je nach Signaturstufe oder eben nicht.
>
> Die Digitale Signatur ist dann rechtssicher und gleicht der einer
> handschriftlichen, wie bei Verträgen usw. und den .pdf Inhalt kann
> man mit seiner Wahl von Werkzeugen einfach verschlüsseln, bevor das
> .pdf Dokument, eIDAS konform signiert und per De-Mail verssendet wird.
>
> Solche eIDAS zertifizierten Dokumente kann man auch online[3]
> überprüfen, falls man Linux Anwender ist und kein Adobe Reader hat.
>
>
> Eigentlich alles eine prima Sache, für .de und EU, nur nutzen sollte man
> es auch.
Ach Stefan! (Ich hoffe, dass ich nicht einen Troll füttere!)
>> > kompliziert, inkompatibel und nutzlos.
>>
>> Was gibt es für Alternativen?
>
> Bitte nicht lachen ...
>
> Es reicht doch für vertrauliche email Kommunitaion, wo der Empfänger
> wissen muss das der Sender auch der richtige ist und kein spam erhält,
> kostenpflichtige oder kostenlose De-Mail[1] mit BSI zertifiziertem
> Kartenleser und nPA aus und dazu ein eIDAS[2] zertifiziertes .pdf
> Dokument, kostenpflichtig je nach Signaturstufe oder eben nicht.
>
> Die Digitale Signatur ist dann rechtssicher und gleicht der einer
> handschriftlichen, wie bei Verträgen usw. und den .pdf Inhalt kann
> man mit seiner Wahl von Werkzeugen einfach verschlüsseln, bevor das
> .pdf Dokument, eIDAS konform signiert und per De-Mail verssendet wird.
>
> Solche eIDAS zertifizierten Dokumente kann man auch online[3]
> überprüfen, falls man Linux Anwender ist und kein Adobe Reader hat.
>
>
> Eigentlich alles eine prima Sache, für .de und EU, nur nutzen sollte man
> es auch.
Es gibt inzwischen so viele Artikel, die u.a. gerade in diesem
Themenebereich die nicht nur schlecht umgesetzten, sondern regelrecht
als solche kaputten Konzepte beleuchten, dass zumindest ich über Deine
regelrechte Empfehlung von DE-Mail noch nicht mal mehr lachen kann.
Ich bin über die Jahre sogar über Artikel gestolpert, die sich sachlich
fundiert und realitätsbezogen /bemüht/ haben, DE-Mail als sinnvolle
aber noch nicht in den relevanten Bereichen vernünftig implementierte
Plattform zu identifizieren, /konnten/ aber nur meist kaputte Konzepte
und/oder von zureichend weit entfernte Implementationen konstatieren.
DE-Mail war (und ist damit weiterhin und es wird sich daran auch nichts
ändern, so lange "DE-Mail" in etwa das benamst, was es ursprünglich und
bisher war) eine Todgeburt mit Ansage und grandioser Bestätigung dieser
Ansage.
Warum ich nicht auf Dein(e) "Argument(e)" eingehe? Weil ich dann nur
Excerpts von Sachen schreiben könnte, deren Suche und Nachlesen /Dir/
deutlich weniger Aufwand abverlangen würde, als mir die Excerpts
zusammenzuschreiben.
Mit freundlichem Gruß,
Henning
PS: Sig was generated totally randomly...
--
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Stefan Claas
Dec 28, 2022, 1:22:25 PM12/28/22
to
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Stefan Claas <sace...@gmail.com> wrote:
> > [...]
> >> > Signaturen und Verschlüsselung in E-Mails sind ziemlich tot.
> >> > Viel zu kompliziert, inkompatibel und nutzlos.
> >>
> >> Was gibt es für Alternativen?
> >
> > Bitte nicht lachen ...
> >
> > Es reicht doch für vertrauliche email Kommunitaion, wo der Empfänger
> > wissen muss das der Sender auch der richtige ist und kein spam
> > erhält, kostenpflichtige oder kostenlose De-Mail[1] mit BSI
> > zertifiziertem Kartenleser und nPA aus und dazu ein eIDAS[2]
> > zertifiziertes .pdf Dokument, kostenpflichtig je nach Signaturstufe
> > oder eben nicht.
> >
> > Die Digitale Signatur ist dann rechtssicher und gleicht der einer
> > handschriftlichen, wie bei Verträgen usw. und den .pdf Inhalt kann
> > man mit seiner Wahl von Werkzeugen einfach verschlüsseln, bevor das
> > .pdf Dokument, eIDAS konform signiert und per De-Mail verssendet
> > wird.
> >
> > Solche eIDAS zertifizierten Dokumente kann man auch online[3]
> > überprüfen, falls man Linux Anwender ist und kein Adobe Reader hat.
> >
> >
> > Eigentlich alles eine prima Sache, für .de und EU, nur nutzen
> > sollte man es auch.
>
> Ach Stefan! (Ich hoffe, dass ich nicht einen Troll füttere!)
Nein, tust du nicht!
> Stefan Claas <sace...@gmail.com> wrote:
> > [...]
> >> > Signaturen und Verschlüsselung in E-Mails sind ziemlich tot.
> >> > Viel zu kompliziert, inkompatibel und nutzlos.
> >>
> >> Was gibt es für Alternativen?
> >
> > Bitte nicht lachen ...
> >
> > Es reicht doch für vertrauliche email Kommunitaion, wo der Empfänger
> > wissen muss das der Sender auch der richtige ist und kein spam
> > erhält, kostenpflichtige oder kostenlose De-Mail[1] mit BSI
> > zertifiziertem Kartenleser und nPA aus und dazu ein eIDAS[2]
> > zertifiziertes .pdf Dokument, kostenpflichtig je nach Signaturstufe
> > oder eben nicht.
> >
> > Die Digitale Signatur ist dann rechtssicher und gleicht der einer
> > handschriftlichen, wie bei Verträgen usw. und den .pdf Inhalt kann
> > man mit seiner Wahl von Werkzeugen einfach verschlüsseln, bevor das
> > .pdf Dokument, eIDAS konform signiert und per De-Mail verssendet
> > wird.
> >
> > Solche eIDAS zertifizierten Dokumente kann man auch online[3]
> > überprüfen, falls man Linux Anwender ist und kein Adobe Reader hat.
> >
> >
> > Eigentlich alles eine prima Sache, für .de und EU, nur nutzen
> > sollte man es auch.
>
> Ach Stefan! (Ich hoffe, dass ich nicht einen Troll füttere!)
> Es gibt inzwischen so viele Artikel, die u.a. gerade in diesem
> Themenebereich die nicht nur schlecht umgesetzten, sondern regelrecht
> als solche kaputten Konzepte beleuchten, dass zumindest ich über Deine
> regelrechte Empfehlung von DE-Mail noch nicht mal mehr lachen kann.
gibt, die scheinbar alle selber De-Mail noch nie nutzten und sich
Über Unzulänglichkeiten bei regulärer email nicht beschweren, wie
spam, scammer, Trojaner, Jugendschutz, Rechtsicherheit usw.
> Warum ich nicht auf Dein(e) "Argument(e)" eingehe? Weil ich dann nur
> Excerpts von Sachen schreiben könnte, deren Suche und Nachlesen /Dir/
> deutlich weniger Aufwand abverlangen würde, als mir die Excerpts
> zusammenzuschreiben.
Grüße
Stefan
Eike Rathke
Dec 28, 2022, 2:12:37 PM12/28/22
to
* Henning Hucke, 2022-12-27 11:37 UTC:
--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
ist, dann hat die (uns nicht mitgeteilte) *Definition*
boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
zu lauten.
Schreibst du ja eigentlich auch selbst:
> Bei einer Boundary
>
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> wäre der MIME part introducer
>
> ----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
> Eike Rathke <erack+nu...@posteo.de> wrote:
>> [...]
>>> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
>>> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
>>> (!)
>>
>>> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>>
>> Wenn schon, dann müsste es boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>> *ohne* die "--" definieren ...
>
> das ist eine nicht zutreffende Aussage.
Doch doch. Wenn der *verwendete* Trenner (MIME part introducer)
>> [...]
>>> Es kommt weniger darauf an, was "dort" steht, sondern was als "boundary"
>>> definiert ist. Wenn "!Pluto" - was auch immer das sein mag - hoffentlich
>>> (!)
>>
>>> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>>
>> Wenn schon, dann müsste es boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>> *ohne* die "--" definieren ...
>
> das ist eine nicht zutreffende Aussage.
--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
ist, dann hat die (uns nicht mitgeteilte) *Definition*
boundary="5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
zu lauten.
Schreibst du ja eigentlich auch selbst:
> Bei einer Boundary
>
> boundary="--5a38311bd6d4/Ni0HMurwCVm1MiSSrKP"
>
> wäre der MIME part introducer
>
> ----5a38311bd6d4/Ni0HMurwCVm1MiSSrKP
Henning Hucke
Dec 29, 2022, 4:37:25 AM12/29/22
to
Stefan Claas <sace...@gmail.com> wrote:
Hallo Stefan,
> [...]
Diskurs.
>> Es gibt inzwischen so viele Artikel, die u.a. gerade in diesem
>> Themenebereich die nicht nur schlecht umgesetzten, sondern regelrecht
>> als solche kaputten Konzepte beleuchten, dass zumindest ich über Deine
>> regelrechte Empfehlung von DE-Mail noch nicht mal mehr lachen kann.
>
> Man sollte aber mal nachdenken, warum es so viele Gegner von De-Mail
> gibt, die scheinbar alle selber De-Mail noch nie nutzten und sich
> Über Unzulänglichkeiten bei regulärer email nicht beschweren, wie
> spam, scammer, Trojaner, Jugendschutz, Rechtsicherheit usw.
Erm...
Multiple Ebenen!
1. Gegner von DE-Mail, die DE-Mail noch nie selbst genutzt haben.
Ehrlich? Es gibt diverse sachliche, weniger sachliche und sogar
unsachliche Gründe, warum potentielle User sich gegen DE-Mail
entschieden haben. Sachliche Gründe setzen meistens bereits (Meilen
weit) vor dem User Interface und User Experience Aspekten an.
2. SPAM, SCAM, Trojaner.
DE-Mail ist grundsätzlich nicht besser und nicht schlechter gegen die
genannten unschönen Sachen gefeit, als klassische E-Mail. Der Effekt, der
diesen Eindruck fördert, ist, dass es sich um ein (weitestgehend)
geschlossenes System handelt und man Absender (besser) identifizieren
und damit zur Rechenschaft ziehen kann.
Last but not least: Selbst wenn man unreflektiert zugesteht, dass diese
Aspekte bei DE-Mail besser sind als bei klassischer Mail, so waren das
nach meiner Kenntnis nie /Ziele/ von DE-Mail, also bestenfalls
Nebenefekte, vielleicht sogar gewünschte aber dennoch nichts anderes.
3. Jugendschutz, Rechtsicherheit.
Ich weiß nicht, was Du mit Jugendschutz meinst; vermutlich, dass keine
DickPics durch die Gegend geschickt werden. Aber ehrlich? Ich verwende
seit fünfunddreißig Jahren Mail und habe mit so etwas noch nie zu tun
gehabt. Wenn man das also bei Mail bekommt, dann *will* man das. Und
dass das bei DE-Mail *nie* passiert ist/wäre, müßte erst noch bewiesen
werden.
Rechtssicherheit: Unterstellter Weise ist das so. Ich möchte auch
annehmen, dass es inzwischenb rechtliche Klärungen durch Gerichte gab.
Aber mir wäre nicht bekannt, dass diese die naive Annahme (das alles und
jegliches per DE-Mail zugestellte in jedem Fall als Zugestellt und
rechtlich bindend anzusehen ist) ausnahmslos betätigt worden ist.
Und selbst wenn insbesondere letzteres der Fall wäre, so wäre gerade das
ein sinnvoller Grund, DE-Mail /nicht/ zu nutzen. Denn wenn man selbst in
einem ausgeprägteren Urlaub DE-Mail lesen muss, um nicht in Verzug zu
geraten, dann würde ich als Globetrotter deutscher Nationalität oder
heutzutage als weltbürgerlicher Digital Citizen und Digital Worker
geradezu vermeiden, mir ein DE-Mail-Konto anzulachen.
Zudem: FÜr einiges, was man mit DE-Mail "lösen" wollte und durchaus auch
für "zentrale Anliegen" hätte es DE-Mail gar nicht bedurft, sondern
lediglich der Erweiterung bestehender E-Mail-Systeme, insbesondere der
Mail-Reader und eventuell des Protokolls, dass eh extensibale ist.
Und mit obigem habe ich mich ausschließlich auf die von Dir genannten
Aspekte konzentriert und bin gar nicht mal auf weitere und relevantere
Aspekte von DE-Mail eingegangen, die kaputt sind.
> [...]
Mit freundlichem Gruß,
Henning
--
Honesty is for the most part less profitable than dishonesty.
-- Plato
Hallo Stefan,
> [...]
>> Ach Stefan! (Ich hoffe, dass ich nicht einen Troll füttere!)
>
> Nein, tust du nicht!
das freut mich; und ich freue mich auf einen produktiven sachlichen
>
> Nein, tust du nicht!
Diskurs.
>> Es gibt inzwischen so viele Artikel, die u.a. gerade in diesem
>> Themenebereich die nicht nur schlecht umgesetzten, sondern regelrecht
>> als solche kaputten Konzepte beleuchten, dass zumindest ich über Deine
>> regelrechte Empfehlung von DE-Mail noch nicht mal mehr lachen kann.
>
> Man sollte aber mal nachdenken, warum es so viele Gegner von De-Mail
> gibt, die scheinbar alle selber De-Mail noch nie nutzten und sich
> Über Unzulänglichkeiten bei regulärer email nicht beschweren, wie
> spam, scammer, Trojaner, Jugendschutz, Rechtsicherheit usw.
Multiple Ebenen!
1. Gegner von DE-Mail, die DE-Mail noch nie selbst genutzt haben.
Ehrlich? Es gibt diverse sachliche, weniger sachliche und sogar
unsachliche Gründe, warum potentielle User sich gegen DE-Mail
entschieden haben. Sachliche Gründe setzen meistens bereits (Meilen
weit) vor dem User Interface und User Experience Aspekten an.
2. SPAM, SCAM, Trojaner.
DE-Mail ist grundsätzlich nicht besser und nicht schlechter gegen die
genannten unschönen Sachen gefeit, als klassische E-Mail. Der Effekt, der
diesen Eindruck fördert, ist, dass es sich um ein (weitestgehend)
geschlossenes System handelt und man Absender (besser) identifizieren
und damit zur Rechenschaft ziehen kann.
Last but not least: Selbst wenn man unreflektiert zugesteht, dass diese
Aspekte bei DE-Mail besser sind als bei klassischer Mail, so waren das
nach meiner Kenntnis nie /Ziele/ von DE-Mail, also bestenfalls
Nebenefekte, vielleicht sogar gewünschte aber dennoch nichts anderes.
3. Jugendschutz, Rechtsicherheit.
Ich weiß nicht, was Du mit Jugendschutz meinst; vermutlich, dass keine
DickPics durch die Gegend geschickt werden. Aber ehrlich? Ich verwende
seit fünfunddreißig Jahren Mail und habe mit so etwas noch nie zu tun
gehabt. Wenn man das also bei Mail bekommt, dann *will* man das. Und
dass das bei DE-Mail *nie* passiert ist/wäre, müßte erst noch bewiesen
werden.
Rechtssicherheit: Unterstellter Weise ist das so. Ich möchte auch
annehmen, dass es inzwischenb rechtliche Klärungen durch Gerichte gab.
Aber mir wäre nicht bekannt, dass diese die naive Annahme (das alles und
jegliches per DE-Mail zugestellte in jedem Fall als Zugestellt und
rechtlich bindend anzusehen ist) ausnahmslos betätigt worden ist.
Und selbst wenn insbesondere letzteres der Fall wäre, so wäre gerade das
ein sinnvoller Grund, DE-Mail /nicht/ zu nutzen. Denn wenn man selbst in
einem ausgeprägteren Urlaub DE-Mail lesen muss, um nicht in Verzug zu
geraten, dann würde ich als Globetrotter deutscher Nationalität oder
heutzutage als weltbürgerlicher Digital Citizen und Digital Worker
geradezu vermeiden, mir ein DE-Mail-Konto anzulachen.
Zudem: FÜr einiges, was man mit DE-Mail "lösen" wollte und durchaus auch
für "zentrale Anliegen" hätte es DE-Mail gar nicht bedurft, sondern
lediglich der Erweiterung bestehender E-Mail-Systeme, insbesondere der
Mail-Reader und eventuell des Protokolls, dass eh extensibale ist.
Und mit obigem habe ich mich ausschließlich auf die von Dir genannten
Aspekte konzentriert und bin gar nicht mal auf weitere und relevantere
Aspekte von DE-Mail eingegangen, die kaputt sind.
> [...]
Mit freundlichem Gruß,
Henning
--
-- Plato
Stefan Claas
Dec 29, 2022, 11:23:52 AM12/29/22
to
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Stefan Claas <sace...@gmail.com> wrote:
>
> Hallo Stefan,
Hallo Henning,
> Stefan Claas <sace...@gmail.com> wrote:
>
> Hallo Stefan,
> 3. Jugendschutz, Rechtsicherheit.
> Ich weiß nicht, was Du mit Jugendschutz meinst; vermutlich, dass keine
> DickPics durch die Gegend geschickt werden. Aber ehrlich? Ich verwende
> seit fünfunddreißig Jahren Mail und habe mit so etwas noch nie zu tun
> gehabt. Wenn man das also bei Mail bekommt, dann *will* man das. Und
> dass das bei DE-Mail *nie* passiert ist/wäre, müßte erst noch bewiesen
> werden.
de.soc-datenschutz z.B. schon das EU weite Thema oft angesprochen
und irgendwie müssen sich ja Straftäter an Jugemdliche ranmachen.
Ob das nun über chatts, wie Messenger Dienste oder email usw. passiert
it mir ebenfalls unbekannt, nur wäre da m.M. ein Dienst weniger
(De-Mail) wo sich Leute das dann sicherlich nicht trauen würden, wegen
der benötigten Identifikation, zwecks Nutzung des Dienstes.
> Rechtssicherheit: Unterstellter Weise ist das so. Ich möchte auch
> annehmen, dass es inzwischenb rechtliche Klärungen durch Gerichte gab.
> Aber mir wäre nicht bekannt, dass diese die naive Annahme (das alles
> und jegliches per DE-Mail zugestellte in jedem Fall als Zugestellt und
> rechtlich bindend anzusehen ist) ausnahmslos betätigt worden ist.
>
> Und selbst wenn insbesondere letzteres der Fall wäre, so wäre gerade
> das ein sinnvoller Grund, DE-Mail /nicht/ zu nutzen. Denn wenn man
> selbst in einem ausgeprägteren Urlaub DE-Mail lesen muss, um nicht in
> Verzug zu geraten, dann würde ich als Globetrotter deutscher
> Nationalität oder heutzutage als weltbürgerlicher Digital Citizen und
> Digital Worker geradezu vermeiden, mir ein DE-Mail-Konto anzulachen.
im Vergleich, obwohl u.U. kostenpflichtig, zu komplizierten digitalen
PGP Signaturen und Verschlüsselung, wobei ich beide Dienste in der
Nutzung als einfacher ansehe, ohne sich deshalb komplett von
klassischer email zu lösen. Halt ein zusätzliches Angebot, wenn
klassische Dienste ala regulärer email für verschiedene Anwendungen
nach Jahrzehnten sich ebenfalls nicht durchgesetzt haben (OpenPGP).
> Zudem: FÜr einiges, was man mit DE-Mail "lösen" wollte und durchaus
> auch für "zentrale Anliegen" hätte es DE-Mail gar nicht bedurft,
> sondern lediglich der Erweiterung bestehender E-Mail-Systeme,
> insbesondere der Mail-Reader und eventuell des Protokolls, dass eh
> extensibale ist.
hätte man für .de z.B. De-Mail nicht ins Leben gerufen. Mal sehen wie
das EU weit bei eIDAS wird. Länderübergreifend hätte man De-Mail
sicherlich auch exportieren können und via Gateways wären dann auch
ausländische "De"-Mail Dienste erreichbar.
Grüße
Stefan
Heiko Steve Digby
Jan 24, 2023, 3:11:39 PM1/24/23
to
Ich bin auch schon so lange mit Computern Unterweg, mit 12 Jahren das war 1983 hatte ich einige Computer von Commodore 116, bis c64 und PC 80286, 80386, 80486, 586, bis heutige Computer.
Erst bei PC Dr-Dos, dann Ms-Dos, Windows, Linux, Unix SCO, und Mac naja vieles eben.
Henning Hucke schrieb am Freitag, 14. Oktober 2022 um 11:37:41 UTC+2:
> Hallo *,
>
> als Admin bin ich seit 1994 unterwegs. Von Anfang an bezüglich
> Linux/Unix und Netzwerk, weiteres ist mit den Jahren und der Technik
> dazu gekommen.
> Mit Computern bin ich grundsätzlich seit Ende der 1970er unterwegs,
> mit einem eigenen seit etwa 1982.
>
> Im Laufe der Jahre entwickeln man vermutlich ein paar Steckenpferde und
> sei es nur, weil sie als Indikator für merkwürdige oder gar
> Fehlentwicklungen dienen zu können scheinen.
> Eines meiner solchen Steckenpferde ist "Mail"; vom Aufbau, Funktion und
> Möglichkeiten von Mails über Mail-Systeme allgemein bis hin zu mail
> processing etc pp. Mein Wissen in diesem - aber Gott sei Dank nicht nur
> diesem - Bereich dürfte mit "Expertenniveau" nicht vollkommen
> unzutreffend charakterisiert sein, wiewohl es natürlich und sicherlich
> ITler gibt, die (auch) in diesem Bereich mehr/tieferes Wissen als ich
> haben.
>
> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
> triggern.
> "Arbeit" differenziere ich von "Unannehmlichkeiten" dadurch, dass nicht
> hier und da mal eine maildrop/procmail-Regel nachgeschäft, eine regex
> mehr als vom Standard vorgesehen aufgebohrt werden muss, sondern man
> echte Schwierigkeiten hat, seine Informationen/Anliegen los und
> gegebenenfalls gefixt zu bekommen, weil auf jedem der Wege Fallstricke
> lauern, die man zum einen vorher nicht kennt, weil sie nirgendwo
> kommuniziert werden, zum anderen auch nicht (so einfach) um sie herum
> kommt und es aus diesem Grund sinnvoll ist, zunächst einen anderen Weg zu
> versuchen (der dann gerne wider Erwartung ebenfalls nicht funktioniert),
> bevor man das Unternehmen unternimmt, um einen Fallstrick herum zu kommen.
>
> Das hat damit begonnen, dass gegen Mitte der 2010er Jahre verwendete
> funktionierende legitime E-Mail-Adressen angeblich keine E-Mail-Adressen
> mehr waren - gefühlt zuerst bei Versicherungen bei denen man (sinnvoller
> Weise, wie auch anderswo) solche als Login-Namen verwendet hat /
> verwenden sollte, diese aber als angebliche Nicht-E-Mail-Adressen
> *strikt* (read: nicht nach einem "Sind Sie sicher, dass sie diese
> E-Mail-Adresse verwenden wollen und Mails an diese ankommen?" akzeptiert
> worden wären) abgelehnt wurden -, ging damit weiter, dass beim
> Arbeitgeber im Mail-System Adressen wie "vert...@firmen.domain"
> eingetragen waren aber auf der Web-Seite "Vert...@firmen.domain"
> verwendet wurde oder man bei einem Dienstleister "user...@meine.domain"
> hinterlegt hat aber die - auch die wichtigen! - Mails an
> "USER...@MEINE.DOMAIN" verschickt werden und endet nicht mit dem, was
> ich gleich beschreibe.
>
> Wir verstehen uns bitte richtig! Das vorbeschriebene sind /Beispiele/!
> Es ist nicht nur das und es sind nicht unbedingt die "schlimmsten
> Sachen". Aber der ein oder andere, der sich ebenfalls mit Mail-Sachen
> etwas spezifischer auskennt, versteht vermutlich die Tragweite.
>
> Das folgende ist ein Beispiel für das, was ich meine, wenn ich schreibe,
> dass es inzwischen Arbeit triggert.
>
> Natürlich bin auch ich krankenversichert. Und ich lasse mir durchaus
> nicht ungerne Newsletter auch von meiner Krankenkasse mailen, weil man
> über manche Sachen dann doch auf dem laufenden bleibt, wofür man
> ansonsten regelmäßig explizit recherchieren müsste.
> Es ist nicht schlimm, dass diese Newsletter einen HTML-Teil haben; in
> bestimmten Situationen öffne ich den HTML-Teil durchaus in einem
> entsprechenden Reader oder öffne ihn in einem HTML-Browser, um mir die
> Informationen anzusehen. Aber mein Standard-Mailreader, den ich auch
> gerne mal von unterwegs von meinem Tablet aus verwende, verwendet Curses
> und stellt vorzugsweise den Plain-Text-Teil dar, rendert aber sogar den
> HTML-Teil vernünftig, wenn dieser nicht allzu blödsinnig und mit allzu
> vielen Grafiken gestaltet ist, wenn kein Text-Plain-Teil vorhanden ist.
> So weit, so durchaus gut.
>
> Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
> einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
> wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu schreiben
> - Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass jeder
> versteht, warum das so ist.
>
> Der entscheidende Teil ist aber der folgende:
> Natürlich hat die Krankenkasse eine Support-Mail-Adresse und ein
> "E-Mail-Formular" auf der Web-Seite und weiteres.
> Nun wollte ich die obige Information der Krankenkasse zukommen lassen
> und als Beispiel auch die (nur der Vollständigkeit halber erwähnt: um
> den HTML-Teil erleichterte Infomail-Mail, damit die Bearbeiter
> tatsächlich den Plain-Text-Teil angezeigt bekommen) Infomail.
> akzeptiert nur eine (zu) geringe Anzahl von Zeichen für die eigentliche
> Nachricht und sieht keine Attachments vor.
> Als nächstes habe ich das "Postfach" bei der Krankenkassen versucht. Das
> funktionierte bis zum Absenden wunderbar, triggerte beim Absenden aber
> einen unspezifische Fehler, sodass ich auf diesem Weg meine
> Informationen ebenfalls nicht einkippen kann.
> Schlussendlich habe ich die Mail mit meinem Anliegen und der
> angenommen wurde aber bisher keine Reaktion, geschweigedenn eine Antwort
> erhalten und denke auch, dass sich das nicht ändern wird, vermutlich die
> Mails im Nirwana oder einem nie gelesenen maildrop landen.
> Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
> Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
> mit an die Mail an den Support zu bappen, zu machen)!?
>
> Mit freundlichem aber etwas ratlosen Gruß,
> Henning
> --
> You have an ambitious nature and may make a name for yourself.
Erst bei PC Dr-Dos, dann Ms-Dos, Windows, Linux, Unix SCO, und Mac naja vieles eben.
Henning Hucke schrieb am Freitag, 14. Oktober 2022 um 11:37:41 UTC+2:
> Hallo *,
>
> als Admin bin ich seit 1994 unterwegs. Von Anfang an bezüglich
> Linux/Unix und Netzwerk, weiteres ist mit den Jahren und der Technik
> dazu gekommen.
> Mit Computern bin ich grundsätzlich seit Ende der 1970er unterwegs,
> mit einem eigenen seit etwa 1982.
>
> Im Laufe der Jahre entwickeln man vermutlich ein paar Steckenpferde und
> sei es nur, weil sie als Indikator für merkwürdige oder gar
> Fehlentwicklungen dienen zu können scheinen.
> Eines meiner solchen Steckenpferde ist "Mail"; vom Aufbau, Funktion und
> Möglichkeiten von Mails über Mail-Systeme allgemein bis hin zu mail
> processing etc pp. Mein Wissen in diesem - aber Gott sei Dank nicht nur
> diesem - Bereich dürfte mit "Expertenniveau" nicht vollkommen
> unzutreffend charakterisiert sein, wiewohl es natürlich und sicherlich
> ITler gibt, die (auch) in diesem Bereich mehr/tieferes Wissen als ich
> haben.
>
> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
> triggern.
> "Arbeit" differenziere ich von "Unannehmlichkeiten" dadurch, dass nicht
> hier und da mal eine maildrop/procmail-Regel nachgeschäft, eine regex
> mehr als vom Standard vorgesehen aufgebohrt werden muss, sondern man
> echte Schwierigkeiten hat, seine Informationen/Anliegen los und
> gegebenenfalls gefixt zu bekommen, weil auf jedem der Wege Fallstricke
> lauern, die man zum einen vorher nicht kennt, weil sie nirgendwo
> kommuniziert werden, zum anderen auch nicht (so einfach) um sie herum
> kommt und es aus diesem Grund sinnvoll ist, zunächst einen anderen Weg zu
> versuchen (der dann gerne wider Erwartung ebenfalls nicht funktioniert),
> bevor man das Unternehmen unternimmt, um einen Fallstrick herum zu kommen.
>
> Das hat damit begonnen, dass gegen Mitte der 2010er Jahre verwendete
> funktionierende legitime E-Mail-Adressen angeblich keine E-Mail-Adressen
> mehr waren - gefühlt zuerst bei Versicherungen bei denen man (sinnvoller
> Weise, wie auch anderswo) solche als Login-Namen verwendet hat /
> verwenden sollte, diese aber als angebliche Nicht-E-Mail-Adressen
> *strikt* (read: nicht nach einem "Sind Sie sicher, dass sie diese
> E-Mail-Adresse verwenden wollen und Mails an diese ankommen?" akzeptiert
> worden wären) abgelehnt wurden -, ging damit weiter, dass beim
> Arbeitgeber im Mail-System Adressen wie "vert...@firmen.domain"
> eingetragen waren aber auf der Web-Seite "Vert...@firmen.domain"
> verwendet wurde oder man bei einem Dienstleister "user...@meine.domain"
> hinterlegt hat aber die - auch die wichtigen! - Mails an
> "USER...@MEINE.DOMAIN" verschickt werden und endet nicht mit dem, was
> ich gleich beschreibe.
>
> Wir verstehen uns bitte richtig! Das vorbeschriebene sind /Beispiele/!
> Es ist nicht nur das und es sind nicht unbedingt die "schlimmsten
> Sachen". Aber der ein oder andere, der sich ebenfalls mit Mail-Sachen
> etwas spezifischer auskennt, versteht vermutlich die Tragweite.
>
> Das folgende ist ein Beispiel für das, was ich meine, wenn ich schreibe,
> dass es inzwischen Arbeit triggert.
>
> Natürlich bin auch ich krankenversichert. Und ich lasse mir durchaus
> nicht ungerne Newsletter auch von meiner Krankenkasse mailen, weil man
> über manche Sachen dann doch auf dem laufenden bleibt, wofür man
> ansonsten regelmäßig explizit recherchieren müsste.
> Es ist nicht schlimm, dass diese Newsletter einen HTML-Teil haben; in
> bestimmten Situationen öffne ich den HTML-Teil durchaus in einem
> entsprechenden Reader oder öffne ihn in einem HTML-Browser, um mir die
> Informationen anzusehen. Aber mein Standard-Mailreader, den ich auch
> gerne mal von unterwegs von meinem Tablet aus verwende, verwendet Curses
> und stellt vorzugsweise den Plain-Text-Teil dar, rendert aber sogar den
> HTML-Teil vernünftig, wenn dieser nicht allzu blödsinnig und mit allzu
> vielen Grafiken gestaltet ist, wenn kein Text-Plain-Teil vorhanden ist.
> So weit, so durchaus gut.
>
> Es ist in Ordnung, wenn der Newsletter einen Plain-Text-Teil hat, der
> einfach nur grottig ist, weil ein Newsletter nicht wichtig ist. Aber
> wenn das bei einer nicht unwichtigen - um nicht "wichtigen" zu schreiben
> - Infomail der Fall ist, wird es schon gefährlich; ich hoffe, dass jeder
> versteht, warum das so ist.
>
> Der entscheidende Teil ist aber der folgende:
> Natürlich hat die Krankenkasse eine Support-Mail-Adresse und ein
> "E-Mail-Formular" auf der Web-Seite und weiteres.
> Nun wollte ich die obige Information der Krankenkasse zukommen lassen
> und als Beispiel auch die (nur der Vollständigkeit halber erwähnt: um
> den HTML-Teil erleichterte Infomail-Mail, damit die Bearbeiter
> tatsächlich den Plain-Text-Teil angezeigt bekommen) Infomail.
>
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> Mein erster Versuch war eine Mail mit der (angepassten) Infomail als
> Attachment an die Support-E-Mail-Adresse. Das Resultat war, dass man
> sich - per Antwort-Mail - für den Erhalt der Mail bedankte, einem das
> Anliegen des Kunden wichtig sei aber man ".eml"-Attachments nicht
> annehmen würde. Der anschliessende Versuch mit dem Gedöns als
> ".txt"-Attachment hatte dasselbe Resultat.
> Es wurde eine Liste von akzeptieren Attachments mitgeliefert, von denen
> ich einige nicht liefern kann - ".doc" und ähnliches -, einiges besagte
> Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
> und einiges schlicht untauglich für den Transport der relevanten
> Information ist.
> Als nächstes habe ich das "E-Mail-Kontakt-Formular" versucht. Dieses
> Arbeit triggert, die ich vorerst vermeiden will - ".pdf" und ähnliches -
> und einiges schlicht untauglich für den Transport der relevanten
> Information ist.
> akzeptiert nur eine (zu) geringe Anzahl von Zeichen für die eigentliche
> Nachricht und sieht keine Attachments vor.
> Als nächstes habe ich das "Postfach" bei der Krankenkassen versucht. Das
> funktionierte bis zum Absenden wunderbar, triggerte beim Absenden aber
> einen unspezifische Fehler, sodass ich auf diesem Weg meine
> Informationen ebenfalls nicht einkippen kann.
> Schlussendlich habe ich die Mail mit meinem Anliegen und der
> (angepassten) Infomail als Attachment an
> "postm...@krankenkassen.domain" gemailt, die erstaunlicherweise sogar
> angenommen wurde aber bisher keine Reaktion, geschweigedenn eine Antwort
> erhalten und denke auch, dass sich das nicht ändern wird, vermutlich die
> Mails im Nirwana oder einem nie gelesenen maildrop landen.
>
> ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
> BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
>
> Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
> Politik und gegebenenfalls Fachverbände und vielleicht sogar
> Wirtschaftskunden auf dem Schirm?
> Kann jemand hier diese Erfahrungen sekundieren und/oder hat einen guten
> ICH WERDE MEINE INFORMATION NICHT LOS! SOBALD ES ETWAS TECHNISCHER WIRD,
> BEKOMMT MAN DIE NICHT (MEHR) AN DIE DIENSTLEISTER LOS!
>
> Hat der CCC so etwas insbesondere in seinen Beratungssessions für die
> Politik und gegebenenfalls Fachverbände und vielleicht sogar
> Wirtschaftskunden auf dem Schirm?
> Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
> Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
> mit an die Mail an den Support zu bappen, zu machen)!?
>
> Mit freundlichem aber etwas ratlosen Gruß,
> Henning
> --
> You have an ambitious nature and may make a name for yourself.
Alexander Ausserstorfer
Mar 17, 2023, 1:25:52 PM3/17/23
to
In article <tidq8i$qbk$3...@sirius.aeon.icebear.cloud>,
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Marco Moock <mo...@posteo.de> wrote:
> Mit Verlaub: Das bezweifele ich.
Ich denke, viele Leute haben einfach keine Ahnung, was sie da tun. Da wird
die Digitalisierung nahezu täglich heruntergebetet und die Leute sollen
und müssen es nutzen, aber sie können kaum damit umgehen. Das fängt schon
im Büro beim Tippen mit 10-Fingern an und geht dann über
Verbindungseinstellungen hinaus bis zur richtigen Bedienung von
Programmen. Das führt dann zur entsprechenden Bevormundung durch Webseiten
oder so, denn etwas anderes können sie halt nicht. Interessiert sie aber
auch nicht. Ist jedenfalls meine Beobachtung.
Einen E-Mail-Reader richtig einzustellen und zu bedienen ist da halt nicht
ganz so einfach. Aber eigentlich unheimlich "geil", wenn man es einmal
kann. Ist auch ganz interessant, wenn man jemanden fragt, was eine
Netiquette ist. Wer weiß das heute schon noch?
Eine ganz nette Zusammenfassung fand ich z. B. hier:
https://email.tugraz.at/
Stellt sich dann nur noch die Frage, wer das auch versteht.
Irgendwie geht anscheinend die Entwicklung dahin, daß alles immer
zentraler und ein Dienst nur noch von einem einzigen Anbieter beherrscht
wird. E-Mails und News sind ja dezentrale Dienste, an denen viele
Anbieter beteiligt sind oder sein können. Was in meinen Augen gut oder
besser ist, weil es nicht so leicht von jemanden kontrolliert werden
kann.
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Marco Moock <mo...@posteo.de> wrote:
>> Am 14.10.2022 um 09:10:49 Uhr schrieb Henning Hucke:
>>
>>> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
>>> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
>>> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
>>> triggern.
>>
>> Die meisten Leute wollen das leider so.
>>
>>> In den letzten Jahren (tm) fällt unter anderem auf, dass Mail immer
>>> schlechter umgesetzt, immer weniger brauchbar wird. Seit etwa zwei
>>> Jahren beginnen unzureichende Implementierungen regelrecht Arbeit zu
>>> triggern.
>>
> Mit Verlaub: Das bezweifele ich.
Ich denke, viele Leute haben einfach keine Ahnung, was sie da tun. Da wird
die Digitalisierung nahezu täglich heruntergebetet und die Leute sollen
und müssen es nutzen, aber sie können kaum damit umgehen. Das fängt schon
im Büro beim Tippen mit 10-Fingern an und geht dann über
Verbindungseinstellungen hinaus bis zur richtigen Bedienung von
Programmen. Das führt dann zur entsprechenden Bevormundung durch Webseiten
oder so, denn etwas anderes können sie halt nicht. Interessiert sie aber
auch nicht. Ist jedenfalls meine Beobachtung.
Einen E-Mail-Reader richtig einzustellen und zu bedienen ist da halt nicht
ganz so einfach. Aber eigentlich unheimlich "geil", wenn man es einmal
kann. Ist auch ganz interessant, wenn man jemanden fragt, was eine
Netiquette ist. Wer weiß das heute schon noch?
Eine ganz nette Zusammenfassung fand ich z. B. hier:
https://email.tugraz.at/
Stellt sich dann nur noch die Frage, wer das auch versteht.
Irgendwie geht anscheinend die Entwicklung dahin, daß alles immer
zentraler und ein Dienst nur noch von einem einzigen Anbieter beherrscht
wird. E-Mails und News sind ja dezentrale Dienste, an denen viele
Anbieter beteiligt sind oder sein können. Was in meinen Augen gut oder
besser ist, weil es nicht so leicht von jemanden kontrolliert werden
kann.
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Alexander Ausserstorfer
Mar 25, 2023, 2:18:30 AM3/25/23
to
In article <tib92p$6b2$1...@sirius.aeon.icebear.cloud>,
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
[E-Mails]
> Kann jemand hier diese Erfahrungen sekundieren und/oder hat einen guten
> Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
> Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
> mit an die Mail an den Support zu bappen, zu machen)!?
Jetzt 'mal etwas ironisch geschrieben (oder auch nicht), weil ich diesen
Gesichtspunkt hier bisher gar nicht fand: Die E-Mail ist heute doch
hoffnungslos veraltet. Das Web ist voll mit solchen Hinweisen. Man sollte
bessere, und vor allem sicherere (?) Systeme (wie z. B. Facebook)
verwenden.
Die Entwicklung geht doch dahin, daß heute jeder Anbieter sein eigenes
Süppchen kocht.
1. Das sieht dann so aus, daß ich im (Web-)Portal meiner Bank meine
Kontoauszüge finde, aber in einem anderen (Web-)Portal wieder meine
Lohnzettel (Gehaltsabrechnungen). Unter dem Gesichtspunkt der
Datensicherheit mag das ja vielleicht gar nicht so unklug sein (?).
Weil - zumindest aus der Sicht des Anwenders - alles dezentral abgelegt
wird. Aber es produziert dem Anwender Arbeit. Statt einen Briefkasten
zu öffnen, hat man mehrere.
2. Und Daten klaut. Ganz nebenbei wird man noch mit Werbung von der Bank
oder vom Steuerberater zugeschüttet, weil man, damit man ins Portal
kommt, über deren Webseite gehen muß. E-Mails sind vielleicht auch
unerwünscht. Weil die Betreiber damit (fast) keine Kontrolle über den
Anwender haben. Oder nicht soviel.
Und wenn man ganz viel Pech hat, kommt man an die persönlichen Dokumente
gar nicht mehr ran, weil man dazu einen speziellen Webbrowser oder ein
spezielles Programm braucht, was aber auf dem heimischen System gar nicht
läuft oder lauffähig ist. Falls es irgend jemand nicht weiß: Es gibt auch
noch andere Betriebssysteme als Microsoft Windows, Aplle MacOS, iOS,
Android oder Linux (?). Oder man hat gar kein System und keinen Zugang.
Was tut eigentlich die Politik?
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
[E-Mails]
> Kann jemand hier diese Erfahrungen sekundieren und/oder hat einen guten
> Rat, wie man damit vernünftig umgehen kann (abseits des Rats, sich die
> Arbeit, die Infomail einfach zu einem PDF zu backen und als Attachment
> mit an die Mail an den Support zu bappen, zu machen)!?
Gesichtspunkt hier bisher gar nicht fand: Die E-Mail ist heute doch
hoffnungslos veraltet. Das Web ist voll mit solchen Hinweisen. Man sollte
bessere, und vor allem sicherere (?) Systeme (wie z. B. Facebook)
verwenden.
Die Entwicklung geht doch dahin, daß heute jeder Anbieter sein eigenes
Süppchen kocht.
1. Das sieht dann so aus, daß ich im (Web-)Portal meiner Bank meine
Kontoauszüge finde, aber in einem anderen (Web-)Portal wieder meine
Lohnzettel (Gehaltsabrechnungen). Unter dem Gesichtspunkt der
Datensicherheit mag das ja vielleicht gar nicht so unklug sein (?).
Weil - zumindest aus der Sicht des Anwenders - alles dezentral abgelegt
wird. Aber es produziert dem Anwender Arbeit. Statt einen Briefkasten
zu öffnen, hat man mehrere.
2. Und Daten klaut. Ganz nebenbei wird man noch mit Werbung von der Bank
oder vom Steuerberater zugeschüttet, weil man, damit man ins Portal
kommt, über deren Webseite gehen muß. E-Mails sind vielleicht auch
unerwünscht. Weil die Betreiber damit (fast) keine Kontrolle über den
Anwender haben. Oder nicht soviel.
Und wenn man ganz viel Pech hat, kommt man an die persönlichen Dokumente
gar nicht mehr ran, weil man dazu einen speziellen Webbrowser oder ein
spezielles Programm braucht, was aber auf dem heimischen System gar nicht
läuft oder lauffähig ist. Falls es irgend jemand nicht weiß: Es gibt auch
noch andere Betriebssysteme als Microsoft Windows, Aplle MacOS, iOS,
Android oder Linux (?). Oder man hat gar kein System und keinen Zugang.
Was tut eigentlich die Politik?
A.
--
http://home.chiemgau-net.de/ausserstorfer/
0 new messages