AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Thema durchsuchen
Ansicht
Themen-Optionen

1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)

Ein Thema von jobo · begonnen am 27. Jul 2012 · letzter Beitrag vom 30. Jul 2012
 
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#11

AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment

  Alt 27. Jul 2012, 21:49
Dass sich so viele Leute per Mail irgendeinen Mist einfangen, liegt aber an ganz anderen Gründen, die sich auch nicht durch technische Maßnahmen beheben lassen
Einspruch. Großes Problem an der Krypto-Geschichte war, dass die Datei aussah, wie ein Dokument und die Nutzer es eben öffnen wollten (worauf es aber ausgeführt wurde). Öffnen ist etwas anderes als Ausführen. Die Geschichte wäre weit harmloser ausgegangen, wenn:
  1. Im Dateibrowser auf den ersten Blick ersichtlich wäre, ob es sich um Daten oder Executable handelt.
  2. Vom Dateibrowser besser zwischen Öffnen und Ausführen unterschieden würde.
Doch, das könnte man besser machen. Von vielen anderen Dateibrowsern wird es besser gemacht. Natürlich steckt auch Psychologie dahinter, aber nicht einzig und allein. Ob ich direkt im Mailprogramm schon drauf reinfalle oder erst nach dem Entpacken im Dateibrowser, ist letztlich egal.
Ich glaube, ich sagte in einem anderen Thread, ich wäre auf eine solche Mail nicht reingefallen. Und da bin ich mir auch zu 95% sicher, einfach weil ich den oben genannten Punkten nicht erlegen bin. Konqueror führt eine Datei nicht per Doppelklick aus (Öffnen schon, aber nicht Ausführen!), und in Konqueror sehen Executables auch anders aus.

Aber es ist nunmal total Wayne, ob die Datei zuvor in einem Archiv lag oder nicht ¹

Zitat:
Zum Beispiel weil Outlook direkt angehangene Executables direkt ausfiltert (das mehr oder minder völlig zu recht) - und zwar ohne den Nutzer darüber zu benachrichtigen*
Und wenn ich mir jetzt einen Client schreibe, der automatisch alle Archive rauswirft, darf die dann auch keiner mehr verschicken? Wenn der Empfänger keine haben will - sein Problem, ich bin meinem Part nachgekommen, ich habe die Daten verschickt, der Fehler liegt dann nicht auf der Absenderseite. Für die Empfängerseite kann ich nichts für.

Nicht dass ich jemals Binaries verschicken würde. Ich würde eine tar.gz mit dem Quellcode verschicken, damit kann man schließlich viel mehr anfangen. Aber das sei jedem selbst überlassen. Das Internet ist allübergreifend über alle Betriebssysteme, Mailclients und Dateibrowser, da ist es unsinnig, Konventionen an einzelne davon anzulehnen - denn es sind eben immer nur einzelne, eine Allround-Lösung, die überall perfekt ist, gibt es sowieso nicht - also einfach halten, keinen großen Aufwand betreiben, und sich nicht zu sehr auf ein Empfängersystem fixieren - es lohnt sich einfach nicht.





¹) bzw. in der UNIX-Welt ist es um einiges sicherer, es als Direktanhang zu haben, als es zu extrahieren. Denn beim Extrahieren wird das +x-Flag ggf. automatisch gesetzt, bei einer direkt angehängten Executable muss ich es erst selbst setzen. Und das heißt dann ja schon, dass ich es Ausführen will, Lesen kann ich sie ja auch ohne

Geändert von implementation (27. Jul 2012 um 22:07 Uhr)
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:48 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz