Mail > Größe Dateianhang

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • torquato schrieb:

    gritsch schrieb:

    Nein, es ist komplett Sinnlos. Denn entweder man entzippt die Dateien … oder man lässt es sein. in eine 20 MB Zip-datei kannst du auch keine Bombe packen welche der entzipper nicht erkennen könnte. Dann kann er die mail immer noch ablehen.
    Du weißt schon, was eine Zip-Bombe ist, oder?

    Ein Virenscanner müßte komplett entzippen, um auch komplett auf Schadcode zu prüfen*. 42.zip** ist z.B. nur 42 kB groß, weit unter 20 MB, bläht sich dann aber auf 4,5 PB auf. Petabyte!!!
    Wieviele solcher Dateien würde es brauchen, um auch große Mailserver zu plätten, wenn sie komplett durchentzippen würden? Geschweige denn davon, daß der durchschnittliche Mailempfänger auch nicht besonders glücklich beim Empfang solch einer Datei sein dürfte.

    *Sinnhaftigkeit eines Scans außen vor gelassen.
    **OK, 42.zip ist soweit bekannt. Das läßt sich auch locker ohne Entpacken anhand der Signatur wegschmeißen. Ich würde aber keinen Pfifferling darauf verwetten, daß nicht irgend jemand anderes etwas 'besseres' liefert.
    du hast aber schon gesehen dass ich geschrieben habe dass sich sowas leicht erkennen lässt! Wenn beim Entzippen plötzlich mehr als 1GB aus einer datei rauskommen würden (er muss die nichtmal entpacken dafür) dann bricht man einfach ab und wirft die mail zurück. Aber eine Mail die 3 MB und entpackt 20 oder 30 MB ist zurückzuwerfen ist einfach nur schwachsinn!

  • Weshalb sollte der Anhang komplett übertragen werden müssen um abgelehnt zu werden? Hierfür gibt es eine Quota, sobald diese erreicht ist, wird abgelehnt, egal was denn noch kommen mag.

    Das Limit, welches aktuell von den Servern akzeptiert wird, ist ein vielfaches von dem, vor ein paar Jahren. Die 4 MB finde ich aber doch ein wenig mickrig, eMail Accounts welche 40 MB Anhänge schlucken sind wohl eine grosse Seltenheit. Daher würde ich mir überlegen, anders zu versenden, bspw. per FTP, Anhang aufteilen, anderer Mailaccount, etc.

    Schöne Grüsse
    Wolf

  • Wolf schrieb:

    Weshalb sollte der Anhang komplett übertragen werden müssen um abgelehnt zu werden? Hierfür gibt es eine Quota, sobald diese erreicht ist, wird abgelehnt, egal was denn noch kommen mag.
    Es geht hier aber darum dass sich apples SMTP unserer meinung nach falsch verhällt weil er die mail zuerst komplett annimmt, dateien darin entpackt und dann diese größe verwendet...

  • Wolf schrieb:


    Daher würde ich mir überlegen, anders zu versenden, bspw. per FTP, Anhang aufteilen, anderer Mailaccount, etc.
    Daher würde ich einfach MailDrop verwenden (ist per default ja aktiviert). Man kann dazu auch die dateigröße einstellen ab welcher maildrop verwendet wird. Ansonsten wird gern wetransfer verwendet. (betrifft natürlich immer nur dateien bei denen privacy und co keine rolle spielen).

  • gritsch schrieb:

    Wenn beim Entzippen plötzlich mehr als 1GB aus einer datei rauskommen würden … dann bricht man einfach ab und wirft die mail zurück.

    Also doch ein Größenlimit der entzippten Datei sinnvoll?

    Vergleiche mit:

    gritsch schrieb:

    dann aber komischerweise die entpackte größe als indikator ob es die mail wegen zu großem inhalt ablehnt oder nicht (macht komplett keinen sinn).
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Wolf schrieb:

    Weshalb sollte der Anhang komplett übertragen werden müssen um abgelehnt zu werden? Hierfür gibt es eine Quota, sobald diese erreicht ist, wird abgelehnt, egal was denn noch kommen mag.
    Einen Stream in der Übertragung abzubrechen, ist ein extrem unsauberes Verfahren. Der Mail-Server kann dann dem Client nicht mehr mitteilen, warum er die Mail ablehnt.

    Ganz abgesehen davon, ist dein OSI-Argument unsinnig, weil das Mail-Protokoll nicht auf dieser Ebene arbeitet.
    „Meine Komplikation hatte eine Komplikation.“

  • torquato schrieb:

    gritsch schrieb:

    Wenn beim Entzippen plötzlich mehr als 1GB aus einer datei rauskommen würden … dann bricht man einfach ab und wirft die mail zurück.
    Also doch ein Größenlimit der entzippten Datei sinnvoll?

    Vergleiche mit:

    gritsch schrieb:

    dann aber komischerweise die entpackte größe als indikator ob es die mail wegen zu großem inhalt ablehnt oder nicht (macht komplett keinen sinn).

    Zip-Bomben sind keine gültigen dateien und werden per se abgelehnt und wie erklärt auch sehr einfach erkennbar!

  • gritsch schrieb:

    torquato schrieb:

    gritsch schrieb:

    Wenn beim Entzippen plötzlich mehr als 1GB aus einer datei rauskommen würden … dann bricht man einfach ab und wirft die mail zurück.
    Also doch ein Größenlimit der entzippten Datei sinnvoll?
    Vergleiche mit:

    gritsch schrieb:

    dann aber komischerweise die entpackte größe als indikator ob es die mail wegen zu großem inhalt ablehnt oder nicht (macht komplett keinen sinn).

    Zip-Bomben sind keine gültigen dateien und werden per se abgelehnt und wie erklärt auch sehr einfach erkennbar!
    Das einzige, was eine Zip-Bombe zu einer Bombe macht, ist es, daß der entpackte Zustand für zu groß erachtet wird. Ob eine Zip-Bombe eine gültige Datei ist, wird einzig und allein (und relativ willkürlich) an der entzippten Größe festgelegt. Der Dateiinhalt ist ansonsten (normalerweise) komplett irrelevant.

    Du hast zuerst argumentiert, daß die entzippte Größe unwichtig sei. "macht komplett keinen sinn". Dann aber sagst Du, daß es ganz normal ist, wenn der Mailserver sich die entpackte Größe anguckt.

    Ich wollte nur darauf hinweisen, daß es für einen Mail-Server durchaus gute Gründe gibt, da mal einen Blick drauf zu werfen.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • macmoonshine schrieb:

    Wolf schrieb:

    Daher würde ich mir überlegen, anders zu versenden, bspw. per FTP, Anhang aufteilen, anderer Mailaccount, etc.
    FTP, ja klar. Sowas hat man vielleicht 1990 gemacht.
    Nicht doch. Linux kernel sourcen werden noch bis 31.03.2017 via FTP übertragen. Und sie sind bestimmt nicht die letzten...
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    gritsch schrieb:

    torquato schrieb:

    gritsch schrieb:

    Wenn beim Entzippen plötzlich mehr als 1GB aus einer datei rauskommen würden … dann bricht man einfach ab und wirft die mail zurück.
    Also doch ein Größenlimit der entzippten Datei sinnvoll?Vergleiche mit:

    gritsch schrieb:

    dann aber komischerweise die entpackte größe als indikator ob es die mail wegen zu großem inhalt ablehnt oder nicht (macht komplett keinen sinn).

    Zip-Bomben sind keine gültigen dateien und werden per se abgelehnt und wie erklärt auch sehr einfach erkennbar!
    Das einzige, was eine Zip-Bombe zu einer Bombe macht, ist es, daß der entpackte Zustand für zu groß erachtet wird. Ob eine Zip-Bombe eine gültige Datei ist, wird einzig und allein (und relativ willkürlich) an der entzippten Größe festgelegt. Der Dateiinhalt ist ansonsten (normalerweise) komplett irrelevant.
    Du hast zuerst argumentiert, daß die entzippte Größe unwichtig sei. "macht komplett keinen sinn". Dann aber sagst Du, daß es ganz normal ist, wenn der Mailserver sich die entpackte Größe anguckt.

    Ich wollte nur darauf hinweisen, daß es für einen Mail-Server durchaus gute Gründe gibt, da mal einen Blick drauf zu werfen.
    Nein, den Mailserver geht es nichts an ob meine dateien entpackt 1 kb oder 1tb sind. Wenn sie ihm zu groß sind zu extrahieren und zu überprüfen dann soll ers lassen. Ich hab ihn nie darum gebeten. Und die spec sieht das auch nicht vor!
    Also e-mails bitte an ihrer größe messen und nicht an der größe der entpackten anhänge.

  • torquato schrieb:

    macmoonshine schrieb:

    Wolf schrieb:

    Daher würde ich mir überlegen, anders zu versenden, bspw. per FTP, Anhang aufteilen, anderer Mailaccount, etc.
    FTP, ja klar. Sowas hat man vielleicht 1990 gemacht.
    Nicht doch. Linux kernel sourcen werden noch bis 31.03.2017 via FTP übertragen. Und sie sind bestimmt nicht die letzten...
    Naja, die haben ihre Anfänge ja nun eindeutig in den Neunzigern. ;)
    „Meine Komplikation hatte eine Komplikation.“