PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Fragen zu Exim's ACLs



Der Pate
04.09.07, 15:35
Tach!

Hab da ein paar Fragen, was Exim's ACL-Ablauf angeht und ich werde nicht schlau aus der Dokumentation.

Also, soweit ich das verstanden habe, läuft ja der gesamte Verkehr über Port 25 ab, d.h. alle Mails, die für meine lokalen Domains bestimmt sind, als auch die Mails, die von den lokalen Domains ausgehen, laufen alle im selben Rohr.

Verschicken können sollen nur die lokalen Mailboxen über TLS-verschlüsselte Verbindungen. Stelle ich dann einfach


tls_verify_hosts = * zusammen mit

tls_verify_certificates = <PFAD>

ein? Was passiert denn dann mit den einkommenden Mails? Denn z.B. Web.de kennt ja meine Zertifikate nicht.

Desweitern habe ich folgendes Problem: irgendwelches SPAM kommt rein an lokale Domains, aber mit nicht-existierendem Lokal-Teil. Das wird angenommen und kurz danach wird die Mail zur Benachrichtigung, dass es den Empfänger nicht gibt, "FROZEN", weil es natürlich den ursprünglichen Absender so auch nicht gibt. Ich dachte, ich brauch da bloß


require
verify = recipient

aber das tut es irgendwie nicht? Kann mir jemand helfen

himbeere
05.09.07, 11:19
Desweitern habe ich folgendes Problem: irgendwelches SPAM kommt rein an lokale Domains, aber mit nicht-existierendem Lokal-Teil. Das wird angenommen und kurz danach wird die Mail zur Benachrichtigung, dass es den Empfänger nicht gibt, "FROZEN", weil es natürlich den ursprünglichen Absender so auch nicht gibt.

Da kannst Du mit den Parametern

ignore_bounce_errors_afterund

timeout_frozen_after
dran drehen.

cheers

Der Pate
05.09.07, 14:25
Okay, danke, das ist schonmal sehr hilfreich, aber wär es nicht besser, gleich dafür zu sorgen, dass solche SPAM-Mails erst gar nicht angenommen werden?

Fällt mir z.B gerade ein? Ginge es, Mails nur dann anzunehmen, wenn sie:
entweder
- verschlüsselt
oder
- nicht verschlüsselt, aber
- für eine lokale Mailbox bestimmt sind
?

Oder übersehe ich da etwas?

himbeere
05.09.07, 14:52
Naja, machen kann man alles.

maikthiel
06.09.07, 19:17
Fällt mir z.B gerade ein? Ginge es, Mails nur dann anzunehmen, wenn sie:
entweder
- verschlüsselt
oder
- nicht verschlüsselt, aber
- für eine lokale Mailbox bestimmt sind
?

Ja, so ähnlich sollte man einen Mailserver auch konfigurieren, dass er kein offenes Relay ist (wobei ich statt Verschlüsselung eine verschlüsselte Benutzeranmeldung im Beispiel habe).

Mal als Beispiel für eine solche ACL stell ich mal eine von unserem Testserver vor:


# Mails von jedem für lokale Domain annehmen, sofern Empfänger existiert
accept domains = example.invalid
message = Unknown local recipient
endpass
verify = recipient
# Wer sich verschlüsselt angemeldet hat, darf alles überall hin versenden
accept authenticated = *
encrypted = *
# Alle anderen erhalten diese Fehlermeldung
deny message = Relaying not permitted

Kurze Erklärung: Wenn alle Bedingungen zwischen den Schlüsselwörtern (accept und dem nächsten accept oder dem deny) erfüllt sind, wird die Mail angenommen.

Im ersten Teil wird die Einlieferung erlaubt, wenn die Zieldomäne die Domäne "example.invalid" ist (sollte natürlich im Echtsystem die eigene Domäne sein) und darüber hinaus der Empfänger existiert (wegen verify = recipient).
Das "endpass" sorgt dafür, dass beim Fehlschlagen des "verify" die weiteren Regeln nicht mehr geprüft werden.

Der zweite Teil erlaubt die Einlieferung beliebiger Mails, wenn sich der Absender authentifiziert hat...

Der "deny"-Zweig kommt immer zum Einsatz, wenn keine der vorherigen Regeln greift, d.h. also jemand ohne Anmeldung Mails an andere Domänen einliefern will.

Ciao sagt Maik

EDIT: Ich sehe gerade, dass du mit Verschlüsselung auch nur die verschlüsselte SMTP-Verbindung meinst, und keinen verschlüsselten Content...

Der Pate
11.09.07, 23:48
Den Teil der Konfiguration habe ich umgesetzt, aber irgendwie behebt das mein Problem trotzdem nicht so ganz. Auch


ignore_bounce_errors_after
und

timeout_frozen_after

helfen nicht arg weiter. Ich will ja nicht prinzipiell die Mail-Queue schnell wieder leer haben, sondern verhindern, dass Bounce-Messages, die von vornherein keinen Sinn machen, erst gar nicht da landen und die einfachste Möglichkeit dafür ist doch, die eingehenden Mails, die diese verursachen erst gar nicht zuzulassen, oder?

Wäre es z.B nicht viel sinnvoller



accept domains = example.invalid
message = Unknown local recipient
endpass
verify = sender


also, statt den Empfänger den Sender zu überprüfen? Wenn es den gibt, ist es doch wahrscheinlicher, dass die Mail auch wirklich zugestellt werden sollte, oder nicht?

himbeere
12.09.07, 10:00
also, statt den Empfänger den Sender zu überprüfen? Wenn es den gibt, ist es doch wahrscheinlicher, dass die Mail auch wirklich zugestellt werden sollte, oder nicht?
Dafür ist die Option:

require verify = sender
zuständig.