[Postfixbuch-users] [OT] Greylists und MX Backup...

[Peer Heinlein]

Am Freitag 22 Januar 2010 19:51:04 schrieb tobi:


> >> Nun ist das Problem, dass sehr viele Clients, die bei der direkten
> >> Lieferung ein Greylist zu sehen bekommen, sofort auf den Backup MX
> >> ausweichen.
> >
> > Das einzige völlig richtige, korrekte und wünschenswerte Verhalten.
> 
> Da sieht man wiedermal, dass es immer was zu lernen gibt. Ich bin
>  voll davon ausgegangen, dass im diesen Fall nicht auf den MX
>  gewechselt werden sollte/dürfte

Wozu ist ein Backup-Mailserver da, wenn er nicht genau dann benutzt 
werden darf/soll, wenn der primäre Server nicht mehr kann/will?

Du willst eine Mail loswerden. Server 1 teilt mir mit: Jetzt nicht, ich 
kann nicht. Warum um Himmels Willen sollte man nicht Server 2 bis 5 
benutzen sollen -- und warum sollte man ihn nicht benutzen wollen? Wofür 
sind die da? Als stromfressende Elektroheizung im Rack?
 
> >> Dieser aktzeptiert die Email und versucht sie an meinen
> >> Server zuzustellen. Dabei landet er natürlich wieder im
> >> Greylisting.
> >
> > Nein, er wird über kurz oder lang ja sogar durch dasa Greylisting
> > durchkommen. Dein Backup-MX sorgt dafür, daß Dein greylisting
> > wirkungslos ist und Dein Spamschutz nicht funktioniert.
> 
> Also bei mir wurden alle Zustellversuche seitens des MX Backup
> ge-greylisted. Der Backup MX hat den originalen Recipient ja jeweils
> mitgeschickt.
> I*n:  RCPT TO:<tobster at brain-force.ch>
>  ORCPT=rfc822;tobster at brain-force.ch *Daher bin ich davon
>  ausgegangen, dass das Greylisting so auch greifen sollte

a) Gute Greylisting-Software wird und soll den Server nach mehreren 
überlebten Tripeln freischalten.

b) Ja, es gibt schlechte Greylisting-Implementierungen, die das nicht 
tun. Die will man nicht haben -- weil hirnrissig und schädlich. Wenn 
Deine Greylistingsoftware den Backup-Server nicht ruckizucki lernt, dann 
willst Du sie nicht haben. 

Aber: Das Greylisting ist doch im Eimer. Denn GL verfolgt folgende 
Ziele:

a) Botnetze zu ärgern in dem man ihnen Resourcen klaut
b) Zu testen, ob der Versender bereit ist Resourcen zu investieren (also 
ein Mailserver ist).

Wenn ich weiß, daß die IP 123 ein Mailserver ist, dann werde ich ihn 
zukünftig nicht mehr testen -- weil das ja sinnfrei ist. Ich weiß doch 
bescheid -- wozu sollte ich ihn greylisten?

Und wenn Dein Backup-MX den Spamschrott vom Botnetz angenommen hat, wenn 
WIRD der Backup-MX als Mailserver das Greylisting (natürlich) auch 
überleben.

Ergebnis: Der mistige backup-MX macht den Greylisting-Spamschutz auf dem 
eigentlichen Mailserver kaputt. Völlig kontraproduktiv und schädlich.

 > >> Die Frage ist jetzt: Wie kann man so was umgehen? Auf den Backup
> >> Mailserver habe ich keinerlei Einfluss und auch keine Möglichkeit
> >> ein Greylisting drauf zu setzen.
> >
> > Abschalten. Aus dem DNS rausnehmen.
> 
> Das habe ich jetzt auch so gemacht, nachdem mir der Support des MX
> Backup Anbieters bestätigt hat, dass Greylisting bei ihnen nicht
>  gehen würde

a) Man braucht keinen Backup-MX

b) Wenn Du einen haben willst: Wir bieten das an.

c) Backup_MX-Anbieter die hier nicht aktiv ihre Kunden beraten und/oder 
das eben richtig machen und anbieten, gehören verboten. Entweder haben 
sie keinen blassen Schimmer von dem, was sie da machen, oder sie 
verarschen und zocken ihre Kunden ab, weil sie Geld dafür verlangen, 
ihre Kunden zu schädigen.

Peer


-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin