# [solved] Postfix-Konfigurationsfrage

## Necoro

Hey,

ich bin gerade dabei mir einen eigenen Mailserver aufzusetzen mit Postfix. Leider wird man manchmal aus der Doku nicht ganz schlau und beim Googeln findet man auch nichts "autoritäres" -- jeder schreibt was anderes  :Smile: . Insofern stelle ich mal meine Frage hier, denn hier sind ja einige versierte Admins anwesend.

Und zwar geht es um den Spam-Schutz / bzw das frühzeitige abweisen von invaliden Mails.

Ich benutze virtuelle Mailuser (wobei das hier und dort noch ein wenig zwackt, weil ja die reelle Domain und die virtuelle Domain übereinstimmen ... naja) - und habe mich jetzt zu den folgenden Restrictions durchgerungen:

```
smtpd_recipient_restrictions = 

    permit_mynetworks,

    permit_sasl_authenticated,

    reject_unknown_reverse_client_hostname,

    reject_unlisted_recipient,

    reject_unauth_destination,

    check_policy_service unix:private/postgrey

smtpd_helo_required = yes

smtpd_helo_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unknown_helo_hostname
```

Ich bin mir unschlüssig über die Reihenfolge/Sinnhaftigkeit von reject_unlisted_recipient und reject_unauth_destination. Irgendwie habe ich es so verstanden, dass das erstere eine strengere Form des letzteren ist. Aber wenn man im Internet sucht, ist in der Regel immer beides angegeben. Vielleicht kann mir da ja jemand mit mehr Kentnissen weiterhelfen.

Ferner: Ist es schlimm, wenn der MX-Eintrag auf mail.zakarum.de lautet, der Server sich aber mit zakarum.zakarum.de zu Wort meldet? (Letzteres ist über DNS nicht erreichbar)

----------

## slick

Also so wie ichs verstanden habe (ohne Gewähr auf Richtigkeit!) würde ichs so beschreiben:

reject_unlisted_recipient weißt alle Mails zurück deren Empfänger nicht bekannt ist und mit reject_unauth_destination weißt er alle Mails zurück für deren Domains Postfix nicht konfiguriert wurde. Das ist bei einem kleinen Mailserver für eien Domain vom Verständnis "fast" das gleiche, erst bei großen Installationen (z.B. ein Postfix am Gateway für diverse Domains und diverse Postfix im LAN) sollte der Unterscheid deutlich werden.

----------

## nanos

Hallo!

Mit "reject_unlisted_recipient" kannst Du die Empfänger Email-Adressen prüfen.

Bei einem Mailrelays weiß man die Adressen nicht aber man kann mit "reject_unauth_destination" die Empfänger Domänen prüfen.

Die Reihengolge der Blocks ist sehr wichtig daher würde ich Dir auch diese Schreibweise ans Herz legen.

```

smtpd_helo_required = yes

smtpd_client_restrictions =

smtpd_helo_restrictions =

smtpd_sender_restrictions =

smtpd_recipient_restrictions =

  permit_mynetworks,

  permit_sasl_authenticated,

  reject_unknown_helo_hostname

  reject_unknown_reverse_client_hostname,

  reject_unlisted_recipient,

  reject_unauth_destination,

  check_policy_service unix:private/postgrey 

```

----------

## py-ro

 *Necoro wrote:*   

> 
> 
> Ferner: Ist es schlimm, wenn der MX-Eintrag auf mail.zakarum.de lautet, der Server sich aber mit zakarum.zakarum.de zu Wort meldet? (Letzteres ist über DNS nicht erreichbar)

 

Schon, der Name mit dem sich dein Server meldet sollte per A-Record wieder auf den Server verweisen. Das ist eine übliche Prüfung. Der Name muss aber nicht zwangsweise in den MX-Records stehen.

[EDIT]Was wichtiges vergessen, der Reverse-Eintrag der IP-Adresse sollte ebenfalls übereinstimmen.[/EDIT]

Py

----------

## Necoro

 *nanos wrote:*   

> Mit "reject_unlisted_recipient" kannst Du die Empfänger Email-Adressen prüfen.
> 
> Bei einem Mailrelays weiß man die Adressen nicht aber man kann mit "reject_unauth_destination" die Empfänger Domänen prüfen.

 

Ergo: Wenn man auf einem lokalen Server die Adressen weiß, kann man sich eigentlich "reject_unauth_destination" sparen?

Und gibt es einen Grund, dass du "reject_unknown_helo_hostname" von den helo in die recipient restrictions geschoben hast (außer die doppelten permit_* zu vermeiden)? Weil Postfix selber sagt: Pack die Regeln dahin wo sie hingehören, weil ansonsten kann es unschöne Nebenwirkungen haben: http://www.postfix.org/SMTPD_ACCESS_README.html#danger

Was das mit dem Serverhostnamen angeht: Das hab ich nun korrigiert.

/edit: Einfach mal mein momentaner postconf -n -- vielleicht sieht ja noch jmd ne Dummheit  :Smile: 

```
command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = //usr/lib/postfix

data_directory = /var/lib/postfix

debug_peer_level = 2

html_directory = /usr/share/doc/postfix-2.6.5/html

inet_interfaces = all

local_recipient_maps = $alias_maps

mail_owner = postfix

mailq_path = /usr/bin/mailq

manpage_directory = /usr/share/man

mydestination = $myhostname, localhost, localhost.$mydomain, zakarum, zakarum.$mydomain

myhostname = mail.zakarum.de

mynetworks_style = host

newaliases_path = /usr/bin/newaliases

queue_directory = /var/spool/postfix

readme_directory = /usr/share/doc/postfix-2.6.5/readme

sample_directory = /etc/postfix

sendmail_path = /usr/sbin/sendmail

setgid_group = postdrop

smtp_tls_security_level = may

smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache

smtpd_helo_required = yes

smtpd_helo_restrictions = permit_mynetworks,

    permit_sasl_authenticated,

    reject_non_fqdn_helo_hostname,

    reject_unknown_helo_hostname

smtpd_recipient_restrictions = permit_mynetworks,

    permit_sasl_authenticated,

    reject_unauth_pipelining,

    reject_unknown_reverse_client_hostname,

    reject_unlisted_recipient,

    reject_unauth_destination,

    reject_rbl_client zen.spamhaus.org

smtpd_sasl_auth_enable = yes

smtpd_sasl_path = private/auth

smtpd_sasl_type = dovecot

smtpd_sender_restrictions = reject_unknown_sender_domain

smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/dovecot/mail.cert

smtpd_tls_key_file = /etc/dovecot/mail.key

smtpd_tls_received_header = yes

smtpd_tls_security_level = may

smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache

unknown_local_recipient_reject_code = 550

virtual_alias_maps = mysql:/etc/postfix/mysql/alias-maps.cf

virtual_mailbox_base = /

virtual_mailbox_domains = mysql:/etc/postfix/mysql/mailbox-domains.cf

virtual_mailbox_maps = mysql:/etc/postfix/mysql/mailbox-maps.cf

virtual_transport = dovecot
```

----------

## nanos

 *Necoro wrote:*   

>  *nanos wrote:*   Mit "reject_unlisted_recipient" kannst Du die Empfänger Email-Adressen prüfen.
> 
> Bei einem Mailrelays weiß man die Adressen nicht aber man kann mit "reject_unauth_destination" die Empfänger Domänen prüfen. 
> 
> Ergo: Wenn man auf einem lokalen Server die Adressen weiß, kann man sich eigentlich "reject_unauth_destination" sparen?

 

Genau, bei mir gehen einige Emails durch die zwar eine gültige Domäne aber keine gültige Email-Adresse haben.

Diese werden dann aber vom zuständigen Mailserver gebounced.

 *Necoro wrote:*   

> 
> 
> Und gibt es einen Grund, dass du "reject_unknown_helo_hostname" von den helo in die recipient restrictions geschoben hast (außer die doppelten permit_* zu vermeiden)? Weil Postfix selber sagt: Pack die Regeln dahin wo sie hingehören, weil ansonsten kann es unschöne Nebenwirkungen haben: http://www.postfix.org/SMTPD_ACCESS_README.html#danger

 

Ja, das hat den Grund das gewisse Mailserver es absolut nicht leiden können wenn man sie schon vor dem RCPT TO: blockt.

Sie trennen dann die Verbindung nicht und halten diese unnötig lange offen.

Die Postfix Doku sagt auch eher Du sollst aufpassen was Du tust, denn wenn Du etwas erlaubst dann überspringt er die ganzen restlichen Regeln und das könnte Deinen Mailserver zu einem offenem Relay machen.

Die meisten Spammer faken das HELO oder den Hostnamen oder die Absende Email-Adresse also sollte man von den Sachen schon aus Prinzip keine Ausnahmen zulassen.

----------

## Necoro

 *nanos wrote:*   

> Ja, das hat den Grund das gewisse Mailserver es absolut nicht leiden können wenn man sie schon vor dem RCPT TO: blockt.
> 
> Sie trennen dann die Verbindung nicht und halten diese unnötig lange offen.

 

Naja - Postfix wertet die Regeln eh alle erst nach dem RCPT TO: aus:

 *man 5 postconf wrote:*   

> smtpd_delay_reject (default: yes)
> 
>        Wait until the RCPT TO command before evaluating $smtpd_client_restric‐
> 
>        tions, $smtpd_helo_restrictions and $smtpd_sender_restrictions, or wait
> ...

 

Wie auch immer  :Smile:  - Mailserver funktioniert wie geschmiert. Ich setz das mal auf solved ... Hindert ja niemanden am weiterdiskutieren

----------

