Re: E-Mail mit leerem Betreff

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Thomas Krug (no-spam_at_siw.de)
Date: 05/28/04

  • Next message: Jens Baier: "Q._Ordner_nicht_zu_erreichen?=" 
    Date: Fri, 28 May 2004 08:51:10 +0200

    Jochen Ruhland <Jochen-NODOT-ruhland@gmx.de> wrote:
    > Hi,
    >
    > "Thomas Krug" <no-spam@siw.de> schrieb:
    >> Anhänge z.B. mit PIF will wohl kaum einer haben und werden denke ich
    >> mal auch nicht wirklich gewollt verschickt. Warum soll sich der
    >> Virenscanner damit abplagen, wenn das schon auf SMTP-Ebene geblockt
    >> werden kann?!
    >
    > falsche Ebene.
    >
    > Das Blocken/Ausfiltern von unerwünschten Attachements hat nichts mehr
    > mit SMTP zu tun, für SMTP besteht die Mail aus allen Zeilen die im
    > DATA-Part gesendet wurden. Die Aufgabe diesen Part in seine
    > MIME-Blöcke zu zerlegen ist nicht mehr Sache des SMTP-Servers, dazu
    > ist er garnicht kompetent genug.

    Klar ist der kompetent genug, muss man ihm halt reinprogrammieren.
    Streng genommen sind die Zeilen im "DATA"-Teil nur Datensosse für den SMTP
    Server, richtig. Die Interpretation des Inhalts ist nicht eigentliche
    Aufgabe des SMTP Protokolls.
    Ein Virenscan ist auch nicht eigentliche Aufgabe eines Mailservers und
    trotzdem willst Du ihn als Funktion haben, oder?
    -> Der "schaun wir mal grob drüber"-Inhaltsscan entlastet den eigentlichen
    (CPU-intensiven) Virenscanner und erklärt dem Absender gleich während der
    SMTP Kommunikation (genauer: nach dem DATA) daß diese EMail unerwünscht ist.

    Nächste Stufe wäre eine Automatik, daß ein Absender dann erstmal in
    Quarantäne gesteckt wird, d.h. daß der Paketfilter dann erstmal für n
    Minuten keine Verbindungen von dieser IP annimmt, sofern sich sowas häuft.
    -> wäre sehr effektiv gegen Wurmschleudern, die schubweise von einer IP
    Emails reinschicken wollen
    -> ist jedoch gefährlich, wenn jmd. IP-spoofing erfolgreich durchführen
    könnte

    >> Eine
    >> Email muß bei mir durch 8 Filtersysteme durch und die CPU-intensiven
    >> sind nun mal die Spamfilter und Virenfilter, die nach dem
    >> eigentlichen Empfang der Email an die Reihe kommen. Also ist eine
    >> Filterung bzw. ggf. ein Ablehnen einer Email "möglichst weit vorne"
    >> durchaus nützlich.
    >
    > ebent. In der Ebene zwischen SMTP und AV-Scanner.
    >
    >> Ja, wenn der andere Mailserver keine Ahnung von SMTP hätte.
    >> Eine 5xx-Meldung erkennen die aber in den allermeisten Fällen als
    >> permanenten Fehler und lassen das mit dem erneuten Versenden.
    >
    > jein.

    Also einer der das nicht erkennt arbeitet nicht RFC konform (siehe unten,
    der Teil mit dem "5" = permanenter Fehler ist kein "SHOULD" sondern ein
    "MUST").
    Aber kann natürlich durchaus sein, daß solche Kandidaten auch mal eine Email
    senden wollen (siehe unten, daher 552.... als Fehlermeldung) :-(

    >> When an SMTP server returns a permanent error status (5yz) code
    >> after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT
    >> make any subsequent attempt to deliver that message. The SMTP
    >> client retains responsibility for delivery of that message and may
    >> either return it to the user or requeue it for a subsequent attempt
    >> (see section 4.5.4.1).
    >
    > mit "Server" ist hier der empfangende Mailserver gemeint, der den
    > gerade empfangenen DATA-Part nicht nehr weiter verarbeiten darf, der
    > "Client" ist hier die Maschine, die den teil ursprünglich absenden
    > wollte, und das kann auch ein Relay-Server in einer Kette sein.

    Klar, das ist immer für die aktuelle Kommunikation der Sender und der
    Empfänger. Die zwei, die sich momentan unterhalten.
    Also wenn der empfangende Server ein 5xx ausgibt, hat er die Mail zu
    verwerfen (er darf sie nicht irgendwohin zustellen). Der sendende
    SMTP-Client soll sich dann gefälligst darum kümmern, was er mit der Mail
    anstellen könnte (also weiteren MX versuchen oder NDR an den Benutzer
    erzeugen).

    >>> [...] SMTP client retains responsibility for the message,
    >>> but SHOULD not again attempt delivery to the same server [...]
    >
    > ebent. Es bleibt ihm ja unbeommen sein Glück am nächsten MX-Record zu
    > probieren ...

    Ja. Der zweite MX sollte dasselbe System haben, das ist richtig.
    Eine abgelehnte Email würde dann ggf. an jedem MX-Eintrag einmal
    "Probezugestellt" werden.

    Die meisten Sachen, die da abgelehnt werden, sind sicherlich die PIFs usw.
    der aktuellen Würmer.
    Das ist einfach eine Güterabwägung, wo man den Krempel abblockt. Die
    mehrfachen Sendeversuche des SMTP-Senders tun IMHO weniger weh danach als
    einen Virenscanner anzuwerfen und die Mail (im Fall eines Wurms) dann
    RFC-widrig im Nirvana verschwinden zu lassen. Ansonsten bräcuhete man einen
    NDR, also auch wieder etwas Traffic.

    Die ein, zwei Emails, bei denen sich tatsächlich Mitarbeiter z.B. eine
    (geblockte) SCR Datei schicken wollen verursachen dann eben Sendeversuche an
    allen MX-Einträgen.
    Bei 2 MX Einträgen ist das dann genau einmal mehr Traffic über die Leitung
    zum Empfangen (einmal müsstest Du die Email eh annehmen). Du würdest Dir
    dafür den Viren-/Spam-Scan sparen und den NDR, falls der Anhang doch
    abgelehnt werden soll.

    >> Der Sender hätte dann aber extrem viel Freude, wenn er sehr große
    >> Emails per SMTP senden wollte, die einfach zu groß für den Empfänger
    >> sind. Die würden dann nämlich ebenfalls wieder und wieder als
    >> vergeblicher Sendeversuch übertragen werden.
    >
    > Hinter dem DATA-Part gibt es lt. RFC genau vier mögliche Errorcodes:
    >
    > 552 -> Too much mail data.
    >
    >> Clients SHOULD treat a 552 code in
    >> this case as a temporary, rather than permanent, failure so the logic
    >> below works.

    laut RFC nur im Zusammenhang mit der falschen RFC 821 und bei Überschreiten
    der max. Anzahl der RCPTs
    Ansonsten ist's natürlich ein permanenter Fehler.

    > 554 -> Transaction failed
    > sagt ja logisch nur aus, daß dieser Versuch gescheitert ist ...
    >
    > 451 -> Requested action aborted: error in processing
    > 452 -> Requested action not taken: insufficient system storage
    > sind ja eh temporär.

    Aus der RFC:

    > If the verb is initially accepted and the 354 reply issued, the
    > DATA command should fail only if the mail transaction was
    > incomplete (for example, no recipients), or if resources were
    > unavailable (including, of course, the server unexpectedly
    > becoming unavailable), or if the server determines that the
    > message should be rejected for policy or other reasons.

    D.h. als Antwort auf ein DATA darf der Server dem Client durchaus auch eine
    Fehlermeldung geben.

    > An SMTP server SHOULD send only the reply codes listed in this
    > document. An SMTP server SHOULD use the text shown in the examples
    > whenever appropriate.

    D.h. man sollte nur die vorgeschlagenen Error-Codes verwenden
    Als Antwort auf ein DATA wäre das 552 / 554 / 451 / 452

    > Consequently, a sender-SMTP MUST be prepared to handle codes not
    > specified in this document and MUST do so by interpreting the first
    > digit only.

    D.h. ein sendender Client muss den Fehlercode anhand der ersten Ziffer
    erkennen. Tut er das nicht, verhält er sich nicht rfc-konform (Kandidaten,
    die sich nicht daran halten, gibt's jedoch bestimmt).

    Ich hab meinen SMTP-Server so eingerichtet, daß er ein
    552 we don't accept email with this type of attachment (#5.7.1)
    zurückgibt. Das ist nicht ganz sauber, weil's eben ein 552 ist (=Mail zu
    groß), aber im Text wird erklärt warum und wieso.
    Es müßte auch ein 571 - Fehler funktionieren, aber Du hast Recht - wer weiß,
    was ein SMTP-Sender damit anstellt (auch wenn er laut RFC nur die "5"
    verwenden sollte). Daher der 552, den jeder Sender handhaben sollte und aus
    Selbstzweck schonmal nicht ignorieren sollte.

    Fehlercode 571 (wäre passender als 552):
     permanent (5.x.x),
     Security or Policy Status (x.7.x)
     Delivery not authorized, message refused (x.7.1)

    Über den Sinn und Unsinn können wir hier recht lang diskutieren...
    IMHO ist es wie gesagt besser, diesen Krempel möglichst "weit vorne"
    abzublocken, um die CPU-intensiven Scans deutlich zu entlasten. Das ist
    immernoch besser als wenn man dann so viele Mails bekomt, dass sie gar nicht
    mehr von den Virenscannern abgearbeitet werden können (soll die Tage ja hin
    und wieder auch bei großen Läden vorkommen).

    Viele Grüße
    Thomas.

  • Next message: Jens Baier: "Q._Ordner_nicht_zu_erreichen?="

    Relevant Pages

    • Re: Leerer eMail Body ? - John Rhotons VB-eMail Versand
      ... > hier ein Auszug aus einer generierten Mail: ... Kommunikation mit dem SMTP Server zu tun. ...
      (microsoft.public.de.access)
    • Re: "Offenes" SMTP-Relay mal anders
      ... IOW wer SMTP spricht, spricht ein Protokoll, dessen Zweck es ist, Mail ... Nein, die Annahme, dass jeder irgendwie per Scan gefundene Server, der ...
      (de.comp.security.misc)
    • Re: e-Mailversand vom PDA mit Visual Studio 2005?
      ... Clients den Port 25 des E-Mail Servers connecten und den Email Text ... SMTP selbst kann aber auch eine Anmeldung verarbeiten ... ... Wenn Du Dich mit dem Server verbindest, ... Example POP3 Session" ...
      (microsoft.public.de.german.windowsce.entwickler)
    • Re: Exchange2000, Sperren des Mail-Versands für bestimmte benutzer
      ... Wie kann ich pro benutzer angeben wer welchen SMTP verwendend darf? ... > Wir verwenden bei eine Firma einen Exchange2000 Server mit ca. 100 ... > internes Mail funktioniert. ...
      (microsoft.public.de.exchange)
    • Re: "Offenes" SMTP-Relay mal anders
      ... Server zugreifen, ... ein SMTP-Server zu bewerten sein. ... Aber zum Ziel kommt die Mail auch nicht. ... sondern weil dieser Dienst auf dem Default-Port für SMTP auf ...
      (de.comp.security.misc)