wie geht ihr mit sich wiederholenden Mailabruf um

[PADARU-IT | Pascal Rudolf]

Hey,

Warum werden denn die dns Einstellungen hier nicht passend gesetzt, sodass 
die redundante Persistenz gleich mal ausgeschlossen wird?
--
Pascal Rudolf
Inhaber

	

Mobil: +49 1777 2595 32
rudolf at padaru.de - padaru.de
Bielebohstrasse 10, 02736 Beiersdorf


Am 27. März 2020 20:06:24 schrieb Markus Winkler <ml at irmawi.de>:

> On 27.03.20 18:25, Ronny Seffner wrote:
>>> Der Kunde soll das tatsächliche Problem lösen und entsprechend der real
>>> vorkommenden Größen der E-Mails die Limits auf seiner Exchange-Büchse
>>> setzen. Fertig.
>>>
>> Dazu muss ich doch erstmal merken, dass das Problem besteht.
>
> Richtig. Und ich habe ja auch nicht geschrieben, dass Du solche m. E.
> sinnvollen Checks wie Dein Traffic-Monitoring nicht mehr betreiben
> solltest. ;-)
>
> > Entweder etabliere ich ein Warnsystem an POP3, was Wiederholungen feststellt
>
> Du hast einen konkreten Fall geschildert, bei dem zig-fache Downloads
> derselben Mail stattfinden. Ich muss gestehen, dass ich nicht genau weiß,
> ob man das im Normalfall anhand den Logs überhaupt überhaupt feststellen
> kann. Eine Chance bestünde wohl nur, wenn das bei Dovecot zu Errors führen
> würde, was es aber in dieser speziellen Konstellation wohl eher nicht der
> Fall sein dürfte, denke ich. Und es könnte ja auch die Situation bestehen,
> dass dieses Postfach von mehreren Clients aus abgefragt wird und nur einer
> von denen final löscht - damit wäre das Verhalten also sogar normal. Solche
> Setups habe ich real schon viele Male erlebt.
>
> Außerdem: Es könnte die Situation geben, dass Dein Kunde tatsächlich viele
> Mails größeren Umfangs bekommt - da würdest Du im Netzwerk-Monitoring zwar
> den gleichen Effekt beobachten, der Grund dafür wäre aber völlig legitim.
>
> > oder ich trete das RZ-Trafficmonitoring in die Tonne.
>
> Genau das würde ich _nicht_ machen. ;-) Das Netzwerk-Monitoring ist eines
> der wichtigsten, um Anomalien dieser Art festzustellen (neben dem
> Monitoring u. a. der Logs auf Fehler, die aber halt nur einen Teil der
> denkbaren Probleme aufdecken können).
>
>> Allerdings wollte ich es eben als Indiz für Auffälligkeiten nehmen.
>
> Eben!
>
> Welche Möglichkeiten Dein Monitoring bietet:
>
>> Hat ja funktioniert nun will ich die Erkenntnis aber automatisieren, so 
>> dass die nächste Warnung dann den Einbruch auf dem Server markiert oder 
>> einen nextcloud-Nutzer als Filesharer demaskiert.
>
> um das evtl. Automatisieren zu können, kann ich Dir nicht sagen, da ich
> nicht weiß, welches Du verwendest.
>
> Neben klassischen Monitoringsystemen können z. T. auch manche Hypervisor
> ergänzend solche Metriken überwachen und Alarm schlagen. Da muss man sich
> die konkret eingesetzten Produkte und Technologien anschauen, was damit
> machbar ist.
>
> Am Ende des Tages wird es, ganz allgemein formuliert, eine Kombination aus
> einer ganzen Reihe von Maßnahmen sein, um solche Störenfriede zu erkennen.
> Und ganz ohne (weitere) manuelle Analyse wird es wohl letztlich auch nicht
> gehen.
>
> Aber noch mal zum konkret geschilderten Fall: Dort ist die Lage ja
> eindeutig, das Problem bekannt und ganz einfach aus der Welt zu schaffen.
> Dort würde ich, ehrlich gesagt, keine Zeit vergeuden und nicht lange mit
> dem Kunde diskutieren.
>
> Viele Grüße
> Markus

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listen.jpberlin.de/pipermail/dovecot/attachments/20200329/a18a1cc2/attachment.html>