Mails von manchen Sender benötigen 15 Minuten bis sie beim Server ankommen

[NorbertFe 2.035]

Naja gibt schon noch ein paar mehr Möglichkeiten für greylisting . Und greylisting an sich kann pauschal auch nicht zwischen dynamisch oder statischen ips unterscheiden, wäre auch irgendwie sinnlos, da kaum noch jemand überhaupt Nachrichten von dynamischen ips annimmt. Kennst du eine implementation, welche das auf diesem Kriterium abfängt?

bearbeitet 7. August 2018 von NorbertFe

[Revan 14]

Auszug aus dem Manual der UTM:

 

Zitat

Use greylisting: Greylisting basically means the temporary rejection of emails for a certain amount of time. Typically, a mail server using greylisting will record the following pieces of information for all incoming messages:

• The sender address
• The IP address of the host the message is sent from
• The recipient address
• The message subject

This data set is checked against the SMTP proxy's internal database; if the data set has not been seen before, a record is created in the database along with a special time stamp describing it. This data set causes the email to be rejected for a period of five minutes. After that time the data set is known to the proxy and the message will be accepted when it is sent again. Note that the data set will expire after a week if it is not updated within this period.

 

Laugt meinen Logfiles sind auf jeden Fall immer wieder Sender betroffen die innerhalb der erwähnten Woche mehrere Mails schicken.

Da O365 ja nun mit einer recht großen Anzahl von IPs arbeitet läuft die Implementation der UTM hier anscheinend ins Leere.

bearbeitet 8. August 2018 von Revan

[NorbertFe 2.035]

vor 30 Minuten schrieb Revan:

Da O365 ja nun mit einer recht großen Anzahl von IPs arbeitet läuft die Implementation der UTM hier anscheinend ins Leere.

Ich sag ja, die UTM ist viel zu unflexibel diesbezüglich. Und da hat sich seit Jahren auch nichts dran geändert.

[gelöscht 0]

vor 10 Stunden schrieb NorbertFe:

Naja gibt schon noch ein paar mehr Möglichkeiten für greylisting . Und greylisting an sich kann pauschal auch nicht zwischen dynamisch oder statischen ips unterscheiden, wäre auch irgendwie sinnlos, da kaum noch jemand überhaupt Nachrichten von dynamischen ips annimmt. Kennst du eine implementation, welche das auf diesem Kriterium abfängt?

Kann es natülich nicht, aber es wäre hier für Sophos geradezu trivial erst die IP gegen eine Blacklist zu prüfen, ist sie dort drauf gibt es ein 5xx zurück, ist sie nicht drauf und auch nicht in der Graylist Tabelle eben ein 4xx. 

 

Graylisting mag ganz gut funktionieren wenn du 2-3MTAs hast die die Graylist Tabelle in RealTime untereinander austauschen können. Große Installationen können das nicht, ausserdem akzeptieren die User, wie auch beim TO hier, keinen 15min delay. Weiterhin kannn auch nicht jeder gewährleisten, dass der Retry immer von der selben Quell-IP kommt, so auch wie hier in dem eigentlichen Problem des Threads. 

 

Aus meiner Sich überwiegen deshalb die Nachteile für Graylisting dessen nutzen. Vor 10-15Jahren hätte ich das noch anders herum geschrieben. Weiterhin wäre interessant wie viel % an SPAM trotz Graylisting durchkommt, also wie viele SPAM Sender auch einen Retry nach einem 4xx machen.

 

BTW: Was hat das Thema überhaupt in einem Exchange Forum zu suchen?

 

ASR

 

[NorbertFe 2.035]

vor 1 Minute schrieb ASR:

Kann es natülich nicht, aber es wäre hier für Sophos geradezu trivial erst die IP gegen eine Blacklist zu prüfen, ist sie dort drauf gibt es ein 5xx zurück, ist sie nicht drauf und auch nicht in der Graylist Tabelle eben ein 4xx. 

Dann bräuchte man aber nur die Reihenfolge der Tests ändern. ;) Alles was auf der Blacklist steht wird geblacklistet und der Rest landet im Greylisting.

 

vor 3 Minuten schrieb ASR:

Graylisting mag ganz gut funktionieren wenn du 2-3MTAs hast die die Graylist Tabelle in RealTime untereinander austauschen können.

Ich hab dazu nen SQL Server laufen. (nein nicht redundant) und ja, wir reden hier von UTM und Konsorten, also eher nicht von Kundengrößen im O365 Style.

 

vor 3 Minuten schrieb ASR:

ausserdem akzeptieren die User, wie auch beim TO hier, keinen 15min delay.

Pfft... Ganz ehrlich, erstens halten sich diese Verzögerungen bei meinen Kunden stark in Grenzen (hängt ja oft auch vom Absenderverhalten ab) und zweitens: Email ist kein Realtime Kommunikationsmittel. Ja ich kann meinen Kunden und Nutzern genau das sagen.

 

vor 6 Minuten schrieb ASR:

Weiterhin wäre interessant wie viel % an SPAM trotz Graylisting durchkommt, also wie viele SPAM Sender auch einen Retry nach einem 4xx machen.

Hab bei einen Servern gerade mal nachgeschaut. Da sinds um die 6% (fürs erste Halbjahr 2018) die im Greylisting hängenbleiben. Interessanter wäre eher, wieviel von den 6% wären im Zweifel in anderen Filtern hängen geblieben. Die durchschnittliche Verzögerung hier betrug übrigens ca. 20 Minuten. Ich gehe davon aus, dass da einige Ausreißer nach oben für diesen schlechten Wert sorgen, die dann eben erst nach mehreren Stunden den zweiten oder dritten Zustellversuch unternehmen.

 

vor 8 Minuten schrieb ASR:

BTW: Was hat das Thema überhaupt in einem Exchange Forum zu suchen?

Gibts ein passenderes? Die ursprüngliche Vermutung des TO war, dass der Mailserver Schuld hat. ;)

 

Bye

Norbert