Laufzeit eMails sehr lange

  • Thread starter Thread starter imagica
  • Start date Start date
I

imagica

Guest
Hallo!

Auf unserem Server tritt folgendes Problem auf: Schickt man Emails von außerhalb auf email-Accounts unseres Servers, so muss man teilweise 1/2 bis 1 Stunde warten, bis diese ankommen (normale textmails). Die Absendezeit ist korrekt, es dauert nur so lange bis die im Client erscheinen.

Ich hatte schon Tests gemacht, und das Greylisting ausgeschaltet aber daran lag es auch nicht.

Hat vielleicht jemand noch einen Tipp freundlicherweise?
Gruß Marco

Server: SuSe Linux 10.3
Plesk: 9.5.1
 
ja, es gibt auch zeitnahe Zustellungen. Es betrifft so ungefähr 1 von 10 Mails.

Das Problem tritt vorwiegend bei mails auf, die von den Absendern *@t-systems.de und *@telekom.de gesendet werden (lt. Kunde).

Würde es helfen, diese in die whitelist aufzunehmen?

Bzw. wie kann ich der Sache auf den Grund gehen?

Gruß Marco
 
In den Headern der Mails kannst du nachvollziehen wo die Verzögerung auftritt.
Wenn Ein Server "dazwischen" ausgelastete ist und die Verzögerung hervorruft kannst du wenig dagegen machen.

Schlimmstenfalls ist es der lokalen Mailserver der Gegenstelle der die Mail sammelt und nur alle 15 Minuten verschickt. Damit dauert es mal 1 Minuten mal 10 Minuten, je nachdem wann die 15 wieder um sind.
 
also, es scheint wohl doch definitiv an greylisting zu hängen. Die logs den entfernten Mail-Servers haben bei den betreffenden Mails fehler gemeldet (weil erst abgelehnt durch gl unseres Servers), und haben einen erneuten Zustellversuch 20 Min später gestartet. Das ist genau die Verzögerung, die der Kunde gemeldet hatte.

Habe gl nun abgeschaltet und spamschutz auf basis der dns Blackholelisten eingerichtet.

Gruß Marco
 
Das empfehl ich defintiv _nicht_.
Mal eine kleine Statistik einer meiner Server ab dem 25. (also < 5 Tage)
(Nur auf Greylisting und Host-lookup bezogen, Spamassassin, ClamAV und Co sind da noch aussen vor)


Total einkommend: 22783
Falscher Hostname: 14299
Greylisting positives: 8284
Zugestellte Emails[*]: 200

{*}: An Spamassassin/ClamAV weitergereicht

Der Server wuerde mir was pfeifen wenn der arme Spamassassin soviel arbeiten muesste... (auch wenns nur 3.3 Emails pro Minute sind ^^)

Natuerlich koennte man das durch einen SPF-Lookup (sofern vorhanden) kombiniert mit einer Whitelist um einiges beschleunigen...
 
Die Zahlen sprechen natürlich für sich, aber eine Sache lässt sich aus ihnen ja nicht ableiten:

Wie viele der 8284 durch Greylisting geblockten Spammails wären auch durch DNSBLs abgewiesen worden?

Sicherlich ist Greylisting ne feine Sache (nutze es selbst teilweise), aber wenn ein Kunde darauf besteht, dass seine Mails ohne Verzögerung ankommen, ist es halt leider unbrauchbar.


der Andi
 
Ich denke Spamassassin haette die Emails zum Gros auch abgefangen.
Mein Punkt ist allerdings nicht die (zugegebenermassen beachtliche :D ) Leistung von Greylistung, sondern dass Greylisting nur sehr wenig Leistung bedarf und komplett autark funktioniert waehrend du bei DNS-BL's dich vom Betreiber, der Vollstaendigkeit sowie Korrektheit der Liste und die Errechbarkeit der solchen abhaengig machst. Des weiteren bedarf der Lookup-Prozess nicht zu negligierender Leistung.

[EDIT]
In dem Fall biete dem Kunden die Option Greylisting zu deaktivieren :)
Ich plane fuer mein Webinterface eine Option wo der Kunde ausserdem den Dienst kurzzeitig fuer einzelne Postfaecher in den "Direkt freigeben"-Modus setzen kann - zb indem das System seine letzten Logins auf IMAP/POP3 beruecksichtigt. Weniger als 20Minuten her? Hopp, neue Emails durch :)

[EDIT2]
Ein (ebenfalls RFC-konformer Trick) ist ausserdem 2 MX-Server zu setzen wobei der erste (hoeher priorisierter Eintrag) auf einen nicht existenten Server zielt, und zweiterer auf den korrekten. Viele Spammer versuchen nur einen Zustellversuch...
Ausserdem gibts noch Stuttering usw welches ebenfalls kaum die Durchstellgeschwindigkeit verringert
 
Last edited by a moderator:
Hab bei mir ebenfalls mal schnell die Mail Logs für meinen privaten Mailserver danach ausgewertet:

Für Monat April:
  • Total Versuche: 5.052
  • Abgewiesen: 3800
  • Davon DNSBLs: 3192
  • Greylisting: 848
  • Angenommen: 404

Bei mir kommt DNSBL (policyd-weight) vor Greylisting. Ist also beides aktiv.
Die Blacklists halten aber das gröbste schon vom Greylisting ab. :)
 
Hast du einen speziellen Grund fuer die Reihenfolge "DNS vor Greylisting"? Ich finde es anders rum logischer, lasse mich aber gerne vom Gegenteil ueberzeugen :)
 
Hi ...

Interessanter Vergleich wie ich finde. Nur mal zur Info in diesem Zusammenhang die Daten von meinem Server nur vom heutigen Tag seit 0:00 Uhr bis jetzt - also knappe 22 Stunden:

* Total Versuche: 6091
* Abgewiesen: 6052
* Davon DNSBLs: 870
* Greylisting: 0
* Angenommen: 39

Ich nutze Spamdyke (weil Qmail) und fahre ohne Greylisting sehr gut, der Großteil wird von Spamdyke abgefangen ohne die DNSBLs. Von den 39 legitimen Mails heute war keine Spam, der Einsatz von Spamassassin oder Greylisting ist hier nicht nötig.

Liegt aber beim Server hier primär daran, dass der Großteil (>98%) der eingehenden emails an Adressen geht, die auf dem System nicht vorhanden sind. Nur ein ganz geringer Anteil geht an die existenten Adressen.

Denke mal, es kommt ganz auf das allgemeine Spammer-Verhalten an, wie man den Server konfigurieren sollte, je nach dem, auf was so am meisten gespammt wird.
 
d4f said:
Hast du einen speziellen Grund fuer die Reihenfolge "DNS vor Greylisting"?
Click to expand...

Die Grundüberlegung war, DNSBL weißt die Mails mit 500er Fehler ab. D.h. sie werden beim sendenden MTA aus der Queue geworfen. Bei einem 400er würde er es ja irgendwann wieder versuchen.
Ursprünglich wollte ich beides mal testen, also Greylisting vor DNSBL und andersrum (aktuelle Konfig). Ich war bisher allerdings immer zu Faul die Config anzupassen. :)

In welcher Reihenfolge das nun wirklich besser und effektiver ist, kann ich im Moment nicht beurteilen. Ich muss allerdings dazu sagen, dass ich einen lokalen DNS Cache auf der Kiste drauf hab, so dass die DNSBLs etwas Performanter arbeiten.
 
Hmm.
Ich kann mich dunkel erinnern gelesen zu haben dass einige Spammer bei einer Hardbounce mit anderen Absender einen erneuten Versuch starten, du also (sofern der neue Sender noch nicht auf der Liste steht) doppelt so viele Verbindungen abkriegst.

Allerdings muss man sagen dass das Intepretieren des Spammer-Verhaltens aehnlich dem Interpretieren der Google-Spider reines Raten ist und beide ihr Verhalten staendig anpassen um nicht in Fallen zu treten.

Faellt einem von euch noch ein (erfolgversprechendes Verfahren) ein ausser den unten genannten? Ich will mich im Sommer nochmal naeher damit auseinandersetzen um raus zu finden welche Module,Reihenfolge und Konfiguration bei minimaler Last die meisten Spams abhalten kann.

- Fake primary MX (RFC-Compliant: Secondary MX wird genutzt)
- IP-Range Lookup (DSL-Uplinks, Modem und Co auf eine Blacklist)
- Whitelisting/Blacklisting
- Hostname lookup
- Valid MX Lookup
- SPF Lookup
- Stutter
- Postgrey
- DNSBL
- Razor, ...
- Bayes, ...
 
d4f said:
Ein (ebenfalls RFC-konformer Trick) ist ausserdem 2 MX-Server zu setzen wobei der erste (hoeher priorisierter Eintrag) auf einen nicht existenten Server zielt, und zweiterer auf den korrekten. Viele Spammer versuchen nur einen Zustellversuch...
Click to expand...
Komisch, ich hatte den Eindruck, dass mein Backup-MX mit niedrigerer Priorität mehr SPAM erhält als der primäre. Mir scheint, dass die SPAMmer hoffen, bei den Backup-MX auf weniger Hürden zu treffen (und auf Wildcard-Einträge)...
 
Das stimmt, da oft auf den backup kein Spamassassin war - mittlerweile haben die Anbieter aber idR nachgebessert.
"Dumme" Spam-Software setzt jedoch nach wie vor auf den primaeren was sie ins Leere laufen laesst.
Allerdings gilt dass, sobald eine neue Antispam-Technik erscheint, die Spammer ihre Server dahingehend verbessern. Man beachte Postgrey, Hostname validation und SPF. Zumals letzteres wurde fast ausschliesslich von Spammer korrekt umgesetzt...
 
You must log in or register to reply here.
Back
Top