CoKo schrieb am 4. September 2004 0:20
> Claw schrieb am 3. September 2004 21:41
>
> > CoKo schrieb am 3. September 2004 19:16
> >
> > > Sorry, aber ich musste gerade erst wieder IP-Filter einrichten, um
> > > mehrere Schwemmen von Emails mit Absenderadresse inet@microsoft.com,
> > > kommend von Dial-Ups aus 7 verschiedenen Staaten, zu blocken, nur
> > > damit der SMTP-Daemon entlastet wird. Auch hier würde die
> > > Absenderauthentifizierung über DNS-Erweiterungen o.ä. bombastische
> > > Dienste leisten!
> >
> > In dem Fall kann ich dir Greylisting empfehlen.
>
> Graylisting hat den gleichen Nachteil wie alle Anti-Spam Tools: Die
> Verbindung zum Server wird erst einmal aufgebaut - und sei es nur, um
> Header zu senden. Dieses beschäftigt den SMTP Daemon und kann im
> Ernstfall bis zum DoS führen. Wie auch immer: Derartiges beschäftigt
> die CPU nicht unerheblich - ich nannte Stückzahlen und CPU-Last
> bereits in einem früheren Posting. Und genau derartiges gilt es zu
> vermeiden.
Die Stückzahlen sind zwar recht beeindrucken aber die hohe CPU Last
wird doch wohl eher durch die Contentanalyse und den Virenscanner
verursacht und die kommen erst zum Einsatz wenn die Mail schon
komplett auf dem Server ist.
Mal schnell den Header zu überprüfen ist im Gegensatz zum
Virenscanner doch ne Kleinigkeit und der CPU Verbrauch ist im
Vergleich kaum der Rede wert.
Du könntest ja auch die Direkteinlieferung von DialUp Netzen blocken.
Damit wäre ein Großteil der Wurmplage auch vom Tisch.
> IP-Filtering hilft dabei enorm, muss jedoch aus Sicherheitsgründen
> immer manuell angestoßen werden - und am besten vor dem Mailserver,
> nicht auf dem Mailserver. Und siehe da - die CPU findet wieder Zeit
> für wichtigeres.
> BTW: Graylisting funktioniert nicht immer, denn einige SMTP
> Implementationen verweigern die erneute Zusendung, wenn sie ein DSN
> 4.0.0 (Persistent Transient Failure) zurück bekommen. Kurzer Auszug
> aus den RFC:
>
> 4.X.X Persistent Transient Failure
>
> A persistent transient failure is one in which the message as
> sent is valid, but some temporary event prevents the
> successful
> sending of the message. Sending in the future may be
> successful.
>
> Es gibt keine Grundlage, dass derart abgewiesene Mails noch einmal
> gesendet (re-queued) werden sollten. In der Regel erhält der Absender
> eine Nachricht und das wars.
Ich kenne keinen MTA der die Mail nicht wieder in die Warteschlange
stellt.
Alle MTAs die ich bisher getestet habe, haben einen weiteren
Zustellversuch gemacht. Erst 4 Stunden nach Absenden wird überhaupt
eine Warnung rausgegeben.
> Für die Server, die wir betreuen, benötigen wir zuverlässigere
> Lösungen.
Und welche wären das ?
Auch bei SenderID & SPF ist der Header schon gesendet bevor überhaupt
geprüft werden kann ob der Absender möglicherweise korrekt ist.
Greylisting ist zwar nicht die Antwort auf alles aber es entlastet
den Virenscanner und den Spamfilter wesentlich und man kann es
durchaus in Kombination mit anderen AntiSpam Methoden verwenden.
Ein Beispiel:
Eine Mail kommt auf dem Mailserver an. Die Headerprüfung zeigt, daß
sie lt. SPF nicht über den korrekten Mailserver verschickt wurde. Die
Mail wird gegreylistet.
Eine andere Mail kommt an. Die Headerprüfung zeigt, daß sie über den
korrekten Mailserver für die Absenderdomain verschickt wurde. Die
Mail wird nicht gegreylistet sondern sofort zugestellt.
> Claw schrieb am 3. September 2004 21:41
>
> > CoKo schrieb am 3. September 2004 19:16
> >
> > > Sorry, aber ich musste gerade erst wieder IP-Filter einrichten, um
> > > mehrere Schwemmen von Emails mit Absenderadresse inet@microsoft.com,
> > > kommend von Dial-Ups aus 7 verschiedenen Staaten, zu blocken, nur
> > > damit der SMTP-Daemon entlastet wird. Auch hier würde die
> > > Absenderauthentifizierung über DNS-Erweiterungen o.ä. bombastische
> > > Dienste leisten!
> >
> > In dem Fall kann ich dir Greylisting empfehlen.
>
> Graylisting hat den gleichen Nachteil wie alle Anti-Spam Tools: Die
> Verbindung zum Server wird erst einmal aufgebaut - und sei es nur, um
> Header zu senden. Dieses beschäftigt den SMTP Daemon und kann im
> Ernstfall bis zum DoS führen. Wie auch immer: Derartiges beschäftigt
> die CPU nicht unerheblich - ich nannte Stückzahlen und CPU-Last
> bereits in einem früheren Posting. Und genau derartiges gilt es zu
> vermeiden.
Die Stückzahlen sind zwar recht beeindrucken aber die hohe CPU Last
wird doch wohl eher durch die Contentanalyse und den Virenscanner
verursacht und die kommen erst zum Einsatz wenn die Mail schon
komplett auf dem Server ist.
Mal schnell den Header zu überprüfen ist im Gegensatz zum
Virenscanner doch ne Kleinigkeit und der CPU Verbrauch ist im
Vergleich kaum der Rede wert.
Du könntest ja auch die Direkteinlieferung von DialUp Netzen blocken.
Damit wäre ein Großteil der Wurmplage auch vom Tisch.
> IP-Filtering hilft dabei enorm, muss jedoch aus Sicherheitsgründen
> immer manuell angestoßen werden - und am besten vor dem Mailserver,
> nicht auf dem Mailserver. Und siehe da - die CPU findet wieder Zeit
> für wichtigeres.
> BTW: Graylisting funktioniert nicht immer, denn einige SMTP
> Implementationen verweigern die erneute Zusendung, wenn sie ein DSN
> 4.0.0 (Persistent Transient Failure) zurück bekommen. Kurzer Auszug
> aus den RFC:
>
> 4.X.X Persistent Transient Failure
>
> A persistent transient failure is one in which the message as
> sent is valid, but some temporary event prevents the
> successful
> sending of the message. Sending in the future may be
> successful.
>
> Es gibt keine Grundlage, dass derart abgewiesene Mails noch einmal
> gesendet (re-queued) werden sollten. In der Regel erhält der Absender
> eine Nachricht und das wars.
Ich kenne keinen MTA der die Mail nicht wieder in die Warteschlange
stellt.
Alle MTAs die ich bisher getestet habe, haben einen weiteren
Zustellversuch gemacht. Erst 4 Stunden nach Absenden wird überhaupt
eine Warnung rausgegeben.
> Für die Server, die wir betreuen, benötigen wir zuverlässigere
> Lösungen.
Und welche wären das ?
Auch bei SenderID & SPF ist der Header schon gesendet bevor überhaupt
geprüft werden kann ob der Absender möglicherweise korrekt ist.
Greylisting ist zwar nicht die Antwort auf alles aber es entlastet
den Virenscanner und den Spamfilter wesentlich und man kann es
durchaus in Kombination mit anderen AntiSpam Methoden verwenden.
Ein Beispiel:
Eine Mail kommt auf dem Mailserver an. Die Headerprüfung zeigt, daß
sie lt. SPF nicht über den korrekten Mailserver verschickt wurde. Die
Mail wird gegreylistet.
Eine andere Mail kommt an. Die Headerprüfung zeigt, daß sie über den
korrekten Mailserver für die Absenderdomain verschickt wurde. Die
Mail wird nicht gegreylistet sondern sofort zugestellt.