![]() |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Eine EXE sollte immer gepackt verschickt werden, um beim Adressaten und den dazwischenliegenden Admins gar nicht erst den Verdacht aufkommen zu lassen, man führe Böses im Schilde.
Ein DAX-Konzern verlangt sogar, das der Name der ZIP Datei das Wort ***** enthalten muss. Dieses Zauberwort ist nur wenigen bekannt und so hält man sich anonym gezippte und damit unerwünschte EXEn vom Hals. Es sollte beim Adressaten einiges an bewusster Arbeit nötig sein, um die EXE bei sich zu speichern und auszuführen. Nur so lassen sich einigermaßen zuverlässig die Ich-klick-Dich-TrojanerVirenbefälle vermeiden. Denn der Anwender ist leider zu blöd. |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Hat beim Krypto-Trojaner ja gut geholfen...
|
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment
Zitat:
* Ja, ich weiß, dass Outlook kein Mailprogramm sondern eine Krankheit ist, aber das ändert nichts daran, dass man nicht immer weiß, ob der Empfänger diesen Müll verwendet. Zitat:
MfG Dalai |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment
Zitat:
Wenn du einen Virus prüfen lässt und genau weisst, dass es sich um einen Virus handelt, dann klickst du nach dem Hochladen auf den Teufel :twisted:. Falls du deine eigene Delphi-Exe hochgeladen hast, dann klickst du auf den Engel :angel:. (wobei du natürlich sicher sein solltest, dass dein Entwicklungsrechner nicht virenverseucht ist und deine Exe nach dem Linken von einem Virus befallen wurde) Da die meisten Benutzer sich kooperativ verhalten und keine mutwillig falschen Bewertungen abgeben, ist eine höhere Anzahl von Teufeln ein starker Hinweis, dass es ein Virus ist (obwohl vielleicht keiner der Virenscanner den Virus kennt). |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment
Zitat:
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 :shock: ¹ Zitat:
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 :lol: |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Zitat:
|
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment
Zitat:
Allerdings würde ich selbst das für mich ohnehin nicht umstellen, da eine direkt verschickte Exe zu 99% ohnehin ein Virus ist. Deshalb habe ich das im Gegenteil auf meinem Server explizit eingestellt, weil es dort nicht standardmäßig so war. Zitat:
(Ja, die GUI der 2013er Version ist in der Preview dermaßen kontrastarm, das gefällt mir auch nicht...) |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Also ich versteh hier so ein paar Aspekte nicht.
In meinem Fall geht es um eine geschäftliche Email. Der Empfänger hat quasi den Inhalt mehr oder weniger bestellt. (vielleicht sogar bezahlt ;) ) Es macht doch null Unterschied, auf welchem Weg ich das Ding nun zum "Empfänger" bekomme, weder technisch, noch welches Produkt ich dafür einsetzte (abgesehen von den mehr oder weniger intransparenten Automatismen, die mich bei einigen Produkten schützen bzw. unterstützen wollen). Es gibt erstmal nur 2 Möglichkeiten: Entweder meine Datei ist sauber (wovon ich normalerweise ausgehe) oder sie ist verseucht. Der letzte Fall ist der interessante. Ich bin nämlich selbst unbemerkt ein Virenopfer geworden. Eine weitere Möglichkeit ist eben ein Fehlalarm eines AV Systems, darum ging es mir hier. Und vor allem, wie man das verifizieren kann. Bei mir läuft ein serverbasiertes System das Emails, Dateisystem und Internetzugriffe prüft, plus FF plugin, das script ausführung unterbindet. Das System wird automatisch aktualsiert, warnt bei mangelnder Aktualität, kostest Geld usw. . Eben wie das heute so ist. Ich wähne mich also erstmal auf der sicheren Seite. Ja ich weiß, es könnte uns auch der Himmel auf den Kopf fallen. Warum soll nicht das verschickt werden, worum es auch wirklich geht? Gezippt war es tatsächlich, um Bandbreite zu sparen. Sourcen statt EXE würde ich in dem Fall auch nicht verschicken, das entspricht nicht dem vorliegenden Geschäftsmodell. Die Sache mit der Signatur wäre da auch noch mal interessant. Kann ich einen Virus "ungestört" verschicken, wenn ich die Email nur schön signiere? Also es geht mir nicht darum Aufwand zu treiben, damit ein Alarm abgewürgt wird, sondern es geht lediglich darum, mit geringst möglichem Aufwand, einen (Fehl)alarm zu verifizieren. |
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Zitat:
Zitat:
Zitat:
|
AW: 1 und 1 verhindert email Annahme mit Delphi EXE attachment (erledigt)
Zitat:
Mich wundert es nur, was teilweise für Empfehlungen gekommen sind. So jetzt auch von Dir. Was ändert es am Problem, wenn der Kunde es bei mir downloaden kann und seine AV dann trotzdem Alarm macht? Und wieso keine Exe verschicken? Ich fahr ja auch nicht mit dem Taxi, wenn ich ein eigenes Auto hab. Wenn es mein Job wäre, den ganzen Tag Programme zu deployen, würde ich es vermutlich anders machen. Aber so eine pauschale, unbegründete Warnung finde ich sinnlos. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:33 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