[Postfixbuch-users] Backup MX

Di Jul 1 18:17:16 CEST 2008

Am Dienstag, 1. Juli 2008 schrieb Dürring Frank J.:

> ich dachte es wäre alles so einfach, naja.

Wie immer ist es einfach, wenn man es richtig macht und weiß, wie es geht. 
Dann ist fast alles auf der Welt einfach...

> 1.	Frage warum finde ich im "mailq" folgende Meldungen?
> 	Wie postfix die Mail an sich selbst ausliefern?
>
> 	10AEDCF52	3634 Sat Jun 28 01:48:08  sdacodex at biz2bizsolutions.net
> 				(connect to mx3.example.com[11.22.33.44]:25: Connection timed out)
>                                  rha at example.com

Er versucht 11.22.33.44 auf Port 25 anzusprechen, kriegt aber keinen 
TCP/IP-Connect. Das ist ein Problema auf Ebene von TCP/IP, dem Routing 
und ggf. daran beteiligten Firewalls. Das hat nichts mit Postfix zu tun. 
Er erreicht diesen Server schlichtweg nicht.

> 2.	Der Eintrag "permit_mx_backup" macht was genau?
> 	Schaut er im DNS wirklich nach welche MX-Einträge da sind und ob "er"
> auch diese E-Mail annehmen soll/darf?

Ja, wobei Postfix prüft, ab es einen *höherwertigen* Mailserver gibt. 
Salopp ausgedrückt also, ob er MX20/MX30 ist und an einen MX10 
weiterleiten kann.

Steht er als MX10 drin, dann nützt ihm das nichts, weil er ja per 
Definition nur Backup hat aber kein Zeil, wohin er das schieben soll.

> 	Wenn, ja warum brauch ich dann noch eine "relay_hosts"-Datei?

Brauchst Du ja nicht. Ein einfaches "permit_mx_backup" ist alles, was Du 
dafür brauchst. Und das richtige DNS-Setup eben.

> 3.	Etwas anderes Thema: Der Eintrag "smtpd_recipient_restrictions"
> sieht im mx1 fast gleich aus (aus relay_host und permit_mx_backup).

Ein "relay_host" kann es in den Restrictions überhaupt gar nicht geben. 
Das gehört irgendwo in die main.cf, aber nicht in Restrictions. Der 
Backup-Server soll auch keinen Relay-Host haben -- wozu?

> 	Macht es so überhäuft einen Sinn? Die Reihenfolge ist ja wichtig,
> aber wie vermeide ich SPAM und sorg trotzdem für eine schnelle
> Verarbeitung?

Indem der MX-20 *EXAKT* die gleich Konfiguration aufweist, wie der MX10. 
Also insb. alle Spamschutzmaßnahmen identisch hat. Kurzum müßte das also 
ein 100%-Clon des MX-10 sein.

Und dann stellt sich die Frage, wozu Du einen MX-20 überhaupt haben 
willst, wenn er Mails eh nur dann ausliefern kann, wenn der MX-10 wieder 
da ist. Das ergibt nämlich gar keinen Sinn und Vorteil und darum kann man 
nur zu dem Schluß kommen, daß solche MX-20-Maschinen ersatzlos gestrichen 
werden sollen. Aber das wurde hier schon x-mal ausdiskutiert, eine kleine 
Suche liefert die Argumente dazu.

> Ich hab eine schöne lange Liste mit von Domainnamen in "relay_hosts"
> auf dem mx3 eingetragen:

Äh... also erstens definiert der main.cf-Parameter "relayhost" das EINE  
Default-Ziel, wo ein Server alle Mails hinrouten soll (Postfix ist der 
Relayhost für den dahinterstehenden Exchange). Das hätte hier nirgendwo 
was zu suchen und mehrer Domains stehen da schon gar nicht drin.

Zum anderen wird auf die hier von dir zitierte Datei in Deiner 
mitgeschickten main.cf gar nicht verwiesen, die scheint also sowieso gar 
nicht benutzt zu werden -- oder die von Dir geschickte Config ist 
unvollständig.

Die von dir zitierten Restrictions sind an sich funktionsfähig und 
eigentlich ist alles korrekt eingestellt. Wenn da was nicht geht, dann 
mußt Du genauer sagen, WAS da nicht geht.

Allerdings sind die von Dir zitierten Restrictions extrem suboptimal 
eingerichtet. Aber das schreibe ich nicht neu, dazu verweise ich mal auf 
die unten angehängte Mail von früher.

Peer

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [Postfixbuch-users] Sinvolle Reihenfolge der Checks
Datum: Montag, 12. März 2007
Von: Peer Heinlein <p.heinlein at heinlein-support.de>
An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein." 
<postfixbuch-users at listi.jpberlin.de>

Am Sonntag, 11. März 2007 20:02 schrieb Andre Keller:

> smtpd_recipient_restrictions =
> 	reject_unknown_sender_domain,
> 	reject_non_fqdn_sender,
> 	permit_mynetworks,
> 	permit_sasl_authenticated,
> 	permit_mx_backup,
> 	reject_unauth_destination,
> 	check_sender_access hash:/path/to/sender_access,
> 	check_recipient_access hash:/path/to/recipient_access,
> 	reject_rbl_client relays.ordb.org,
> 	reject_rbl_client sbl.spamhaus.org,
> 	check_policy_service inet:127.0.0.1:60000,
> 	permit

Soweit okay, es WÜRDE gehen. Aber es ist nicht optimal.

Ich halte nichts von Theorien, daß man die restrictions von billig nach 
teuer aufbauen kann. Ich behaupte: Wenn man für alle Möglichkeiten 
gewappnet sein will, dann gibt es eine zwangsläufige Reihenfolge, die 
durch die Logik vorgegeben wird. Wenn man alles berücksichtigt hat man 
leider keine Entscheidungsspielräume um das ernsthaft nach Performance 
zu optimieren.

1) postmaster und abuse durch check_recipient_maps freischalten
2) Jeweils eine access-Map für client, helo, sender,recipient um 
beliebig white- und blacklisten zu können (auch das eigene Netz!!!)
3) Syntax-Checks wie reject_unknwon_(sender|recipient)_domain und 
reject_non_fqdn_(sender|recipient)_domain
4) permit_mynetworks, _permit_sasl_authenticated und ggf.TLS-Zertifikate
5) RBL oder alternativ policyd_weight
6) Greylisting
7) Ggf. permit_max_backup
8) reject_unauth_destination

Für 4 bis 8 ist die Abfolge logisch zwingend, für 1) sowieso. Über die 
Reihenfolge von 2) und 3) kann man diskutieren, ist aber relativ egal 
und hier ausnahmsweise Geschmackssache.

Komplexere Setups wie restriction_classes erfordern ggf. weitere 
access-Abfragen die ergänzt werden müssen, an der Grundstruktur ändert 
sich aber nichts.

In deiner Lösung stört mich:

a) Du hast permit_mx_backup über RBL und Greylisting. Für den 
gebackuppten Server wird das nicht benutzt. Damit machst Du seinen 
Spamschutz kaputt und Du bist das Hintertürchen der Spammer. Nicht 
nett.

b) Du hast keien Chance, einen amoklaufenden Client oder Úser aus 
$mynetworks zu sperren, da Deine check_*_maps zu spät sind. Das ist 
schade, denn würdest Du sie höher packen, so hättest Du keine 
Nachteile, wohl aber die Möglichkeit im Krisenfall einzugreifen. So wie 
Du es jetzt hast kannst Du 6 Milliarden Leute weltweit sperren -- nur 
Deine eigenen 60 User nicht. Das kann doch wohl kaum sein. Für den bist 
Du Verantwortlich? Wo mußt Du aufpassen, daß nix passiert?

Wenn du hier a) und b) umsetzen willst, dann kommst Du mit allen 
Folgeentscheidungen, die daraus erwachsen, auf oben skizzierte 
Grundlösung.

Mit freundlichen Grüßen

Peer Heinlein

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

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

Besuchen Sie uns: CeBIT 2007: Stand G64/3 im LinuxPark!

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  --  Sitz: Berlin
-- 
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

Postfixbuch-users at listi.jpberlin.de
http://listi.jpberlin.de/mailman/listinfo/postfixbuch-users

-------------------------------------------------------

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

http://www.heinlein-support.de

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

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

http://www.heinlein-support.de

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