[Postfixbuch-users] Einbindung Amavis in submission klappt nicht

Patrick Ben Koetter p at sys4.de
Mo Apr 14 10:37:03 CEST 2014


Die Aufgabe eines Submission-Hosts ist, E-Mail in den Transport-Verkehr
aufzunehmen. Zentraler Bestandteil dieser Aufgabe ist, die Nachricht auf
Transportfähigkeit zu prüfen und sie nur dann anzunehmen, wenn das gegeben
ist.

Transportfähig ist eine Nachricht dann, wenn

- Envelope-Sender und -Recipient RFC-konform sind (localpart at domainpart)
- der Submission-Host zum Zeitpunkt der Transportanfrage in der Lage ist,
  Quell- und Zieldomain aufzulösen, um Transport und Rücktransport (bounce)
  abzuwickeln

RFC-konform ist sie u.a. wenn From:-Header, Subject:-Header UND Date:-Header
gesetzt sind. Ist das nicht der Fall, sollte der Submission-Host (und nur DER)
nachbessern.

Insofern finde ich Deine Restrictions grundsätzlich richtig. Wenn Du darüber
hinaus noch anderen Tests durchführst, ist das Deine persönliche Entscheidung
bzw. Company Policy. Hauptsache, Du hast das Recht dazu. Ausgehend Spam prüfen
ist z.B. nicht per default gestattet.

p at rick


* Christian Garling <postfixbuch-users at listen.jpberlin.de>:
> Ich muss da nochmal einhaken. Warum sollte ich die
> smtpd_recipient_restrictions für meine Clients die per submission
> einliefern so lasch setzen?
> Aus meiner Sicht können und sollten die Clients die Checks
> durchlaufen, die in der main.cf definiert sind:
> 
>                         # role accounts (abuse and postmaster)
>                                 check_recipient_access
> hash:/etc/postfix/access_maps/role_accounts,
>                         # whitelists / blacklists
>                                 check_client_access
> hash:/etc/postfix/access_maps/hostname,
>                                 check_client_access
> cidr:/etc/postfix/access_maps/ip.cidr,
>                                 check_helo_access
> hash:/etc/postfix/access_maps/helo,
>                                 check_helo_access
> pcre:/etc/postfix/access_maps/helo.pcre,
>                                 check_sender_access
> hash:/etc/postfix/access_maps/sender,
>                                 check_recipient_access
> hash:/etc/postfix/access_maps/recipient,
>                         # reject non-compliant mails
>                                 reject_non_fqdn_sender,
>                                 reject_non_fqdn_recipient,
>                                 reject_unknown_sender_domain,
>                                 reject_unknown_recipient_domain,
>                                 reject_invalid_hostname,
>                         # permit authenticated and local users
>                                 permit_sasl_authenticated,
>                                 permit_mynetworks,
>                                 [...]
> 
> Was spricht dagegen? Was spricht stattdessen für:
> 
>         -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> 
> Als gravierenden Unterschied sehe ich das sofortige reject für alles
> außer meinen Clients. Macht es stattdessen Sinn die Option zu
> erweitern?
> 
>         -o smtpd_client_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unknown_sender_domain,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
> 
> Im Grunde könnte ich dann ja als letzte Konsequenz auch
> permit_sasl_authenticated aus den smtpd_recipient_restrictions in
> der main.cf gänzlich entfernen, da meine Clients ja nur noch per
> Port 587 einliefern (müssen) und Port 25 dem Empfang von "außen"
> vorbehalten bleibt.
> 
> Ich freue mich auf eure Kommentare.
> 
> Gruß, Christian
> 
> 
> Am 13.04.2014 20:50, schrieb Peer Heinlein:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Am 13.04.2014 20:01, schrieb Christian Garling:
> >
> >>submission inet n       -       n       -       -       smtpd -o
> >>smtpd_proxy_filter= -o content_filter=127.0.0.1:10024 #  -o
> >>smtpd_tls_security_level=encrypt #  -o smtpd_sasl_auth_enable=yes #
> >>-o smtpd_client_restrictions=permit_sasl_authenticated,reject #  -o
> >>milter_macro_daemon_name=ORIGINATING
> >Der Syntax vom content_filter ist ein "nexthop"-Syntax wie in der
> >transport_maps.
> >
> >Also:
> >
> >smtp:[127.0.0.1]:10024
> >
> >Außerdem hast Du submission kaputt gemacht. Die vier Zeilen dadrunter
> >müssen ebenfalls aktiv sein.
> >
> >Peer
> >
> >
> >
> >- -- Heinlein Support GmbH
> >Schwedter Str. 8/9b, 10119 Berlin
> >
> >http://www.heinlein-support.de
> >
> >Tel: 030 / 405051-42
> >Fax: 030 / 405051-19
> >
> >Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
> >Berlin-Charlottenburg,
> >Geschäftsführer: Peer Heinlein -- Sitz: Berlin
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v2.0.22 (GNU/Linux)
> >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >iQEcBAEBAgAGBQJTStyKAAoJEAOLLpq5E82H8+gH/3cRULQEPdErcwxTqqon/wXs
> >92CY6CIuEUPRjgKblcjmC41C0vuWYXnEGLGbySVBwSM8cDQNmR+vE+VIiLmdjz5g
> >uto8T1VIhnmSBM7RnU9yQm9QEvMnteChKAsWo612defcEK2yOnxDa0lLk32zLb4C
> >cjvOtPDLIjd+eh3Wpu1ZmCcQ45epIve02GopHLYsimAq6bKUn6l+HauU9oxExL5q
> >L/RUavouCmSC2Tg7SdAkNTev1vh6lseNVXA1LCb254Agv74SrKrXpnDMwiPslJgM
> >IRW57CYCsQ+u2fI4dRcNE3mR0oS4DxlpUVzQ+nilJWN8R4zkdbiGfLxLLkahx8k=
> >=XMbp
> >-----END PGP SIGNATURE-----
> 
> -- 
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
> 
> Postfixbuch-users at listen.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 



Mehr Informationen über die Mailingliste Postfixbuch-users