HI Joda,
Nachdem Du mich bei Deinem Besuch angefixt hast, hab ich mich mal an postscreen vergriffen. Herausgekommen ist erst einmal folgende Konfiguration.
-------------------------------------------------------------------------------- master.cf
smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd -o smtpd_milters=${spf_milter},${opendkim_milter},${opendmarc_milter},${amavisd_milter}
dnsblog unix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------- main.cf ################################################################################ ## Postscreen # # Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST # default: postscreen_access_list = permit_mynetworks postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_whitelist # # default: postscreen_blacklist_action = ignore postscreen_blacklist_action = drop
# Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS # default: postscreen_whitelist_interfaces = static:all postscreen_whitelist_interfaces = !88.217.171.167 static:all
# Django : 2014-10-29 - BEFORE 220 GREETING TESTS # default: postscreen_dnsbl_threshold = 1 postscreen_dnsbl_threshold = 2 # # default: postscreen_dnsbl_sites = postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 swl.spamhaus.org*2 # # default: postscreen_dnsbl_action = ignore postscreen_dnsbl_action = enforce # # default: postscreen_greet_banner = $smtpd_banner # # default: postscreen_greet_action = ignore postscreen_greet_action = enforce
# Django : 2014-10-29 - AFTER 220 GREETING TESTS # default: postscreen_bare_newline_action = ignore postscreen_bare_newline_action = drop # # default: postscreen_bare_newline_enable = no postscreen_bare_newline_enable = yes # # default: postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_enable = yes # default: postscreen_non_smtp_command_action = drop # # default: postscreen_pipelining_enable = no postscreen_pipelining_enable = yes # # default: postscreen_pipelining_action = enforce
--------------------------------------------------------------------------------
Das Ganze scheint auf den ersten Blick recht gut zu funktionieren - ganz 100%ig bin ich mir da aber nicht sicher. Warum? na ab und ann sehe ich folgende Meldungen im maillog: Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: NOQUEUE: reject: RCPT from [193.169.180.107]:54690: 450 4.3.2 Service currently unavailable; from=return@news.mytoys.de, to=redacted@nausch.org, proto=ESMTP, helo=<mail17-107.srv2.de> Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: warning: unknown macro name "client" in expansion request
Der 450er stört mich nun erst mal nicht so recht, viel mehr diese WARNING: nknown macro name "client" in expansion request Was'n datt?
Wenn ich es richtig aus dem maillog gegrep't hab dann dürft das da der komplette zugehörige Sermon des ersten Zustellversuchs sein: Oct 30 09:43:38 vml000080 postfix/postscreen[14951]: CONNECT from [193.169.180.107]:54690 to [10.0.0.80]:25 Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: [193.169.180.107]54690: discarding EHLO keywords: DSN Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: NOQUEUE: reject: RCPT from [193.169.180.107]:54690: 450 4.3.2 Service currently unavailable; from=return@news.mytoys.de, to=redacted@nausch.org, proto=ESMTP, helo=<mail17-107.srv2.de> Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: warning: unknown macro name "client" in expansion request Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: PASS NEW [193.169.180.107]:54690 Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: DISCONNECT [193.169.180.107]:54690
Dann kommt er wieder: Oct 30 09:53:54 vml000080 postfix/postscreen[14951]: CONNECT from [193.169.180.107]:55755 to [10.0.0.80]:25 Oct 30 09:53:54 vml000080 postfix/postscreen[14951]: PASS OLD [193.169.180.107]:55755 Oct 30 09:53:54 vml000080 postfix/smtpd[15632]: connect from mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:54 vml000080 postfix/smtpd[15632]: discarding EHLO keywords: DSN Oct 30 09:53:54 vml000080 smf-spf[12097]: SPF pass: ip=193.169.180.107, fqdn=mail17-107.srv2.de, helo=mail17-107.srv2.de, from=return@news.mytoys.de Oct 30 09:53:55 vml000080 postfix/smtpd[15632]: 3BD0175: client=mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:55 vml000080 postfix/cleanup[14362]: 3BD0175: message-id=re-pTf3SwushbLdwAjqbbGt4j-13RR982X-13ME1R6S-62QD4X@news.mytoys.de Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: mail17-107.srv2.de [193.169.180.107] not internal Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: not authenticated Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: DKIM verification successful Oct 30 09:53:55 vml000080 opendmarc[1446]: 3BD0175: news.mytoys.de none Oct 30 09:53:58 vml000080 postfix/qmgr[10267]: 3BD0175: from=return@news.mytoys.de, size=96158, nrcpt=1 (queue active) Oct 30 09:53:58 vml000080 postfix/smtpd[15632]: disconnect from mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:58 vml000080 postfix/lmtp[15548]: 3BD0175: to=redacted@nausch.org, relay=10.0.0.77[10.0.0.77]:24, delay=4.1, delays=4/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 redacted@nausch.org 0XDGBev7UVS+QAAArK2B9Q Saved) Oct 30 09:53:58 vml000080 postfix/qmgr[10267]: 3BD0175: removed
"PASS NEW" bedeutet doch, dass der Client alle Test bestanden hat und er einen temporären Whitelisting-Eintrag bekommen hat. Richtig?
Da ich in meiner Konfig "deep protocol tests" aktiviert habe, kann postscreen die Verbindung nicht mehr an den eigentlichen SMTP-Daemon weiterreichen. Richtig? Daher kommt auch der "450 4.3.2 Service currently unavailable" zustande. Richtig?
Aber was ist nun mit dieser Meldung >>unknown macro name "client" in expansion request<<? Die verstehe ich nicht ganz? Was will/soll mir das sagen? \o/
Ich fürchte, ich brauch da noch ein wenig Hilfe bevor ich datt janze auf meiner ersten Produktions-Maschine einsetze.
Servus Django
Hi,
* django@nausch.org django@nausch.org:
Nachdem Du mich bei Deinem Besuch angefixt hast, hab ich mich mal an postscreen vergriffen. Herausgekommen ist erst einmal folgende Konfiguration.
# default: postscreen_dnsbl_sites = postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 swl.spamhaus.org*2
Die swl hat öfters mal falsch Positive. Die würde ich eher mit -2 aus der Kalkulation rausnehmen:
swl.spamhaus.org*-2
Das Ganze scheint auf den ersten Blick recht gut zu funktionieren - ganz 100%ig bin ich mir da aber nicht sicher. Warum? na ab und ann sehe ich folgende Meldungen im maillog: Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: NOQUEUE: reject: RCPT from [193.169.180.107]:54690: 450 4.3.2 Service currently unavailable; from=return@news.mytoys.de, to=redacted@nausch.org, proto=ESMTP, helo=<mail17-107.srv2.de> Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: warning: unknown macro name "client" in expansion request
Der 450er stört mich nun erst mal nicht so recht, viel mehr diese WARNING: nknown macro name "client" in expansion request Was'n datt?
Diese Fehlermeldung habe ich auch nicht auf dem Radar.
"PASS NEW" bedeutet doch, dass der Client alle Test bestanden hat und er einen temporären Whitelisting-Eintrag bekommen hat. Richtig?
ACK
Da ich in meiner Konfig "deep protocol tests" aktiviert habe, kann postscreen die Verbindung nicht mehr an den eigentlichen SMTP-Daemon weiterreichen. Richtig? Daher kommt auch der "450 4.3.2 Service currently unavailable" zustande. Richtig?
ACK
(Hier kannst Du als secondary MX noch einmal den primary angeben. Dann wird der Client-MTA mit grosser Wahrscheinlichkeit nach der ersten Abweisung gleich den Secondary probieren. Die Zeit zwischen Abweisung und Zustellerfolg wird so signifikant kürzer)
Aber was ist nun mit dieser Meldung >>unknown macro name "client" in expansion request<<? Die verstehe ich nicht ganz? Was will/soll mir das sagen? \o/
Das weiß ich auch noch nicht. Mal nachdenken und ggf. auf der EN-Liste nachhaken.
p@rick
Am 30.10.2014 um 11:31 schrieb Patrick Ben Koetter:
Die swl hat öfters mal falsch Positive. Die würde ich eher mit -2 aus der Kalkulation rausnehmen:
swl.spamhaus.org*-2
Sind dort jetzt Einträge vorhanden? Vor 2 Monaten wurde mir noch bestätigt, dass diese Liste leer ist. Siehe: http://marc.info/?l=postfix-users&m=140994818017696&w=2
Howdie p@rick!
Quoting Patrick Ben Koetter p@sys4.de:
Die swl hat öfters mal falsch Positive. Die würde ich eher mit -2 aus der Kalkulation rausnehmen:
swl.spamhaus.org*-2
O.K., hab die rausgeworfen.
"PASS NEW" bedeutet doch, dass der Client alle Test bestanden hat und er einen temporären Whitelisting-Eintrag bekommen hat. Richtig?
ACK
Daher kommt auch der "450 4.3.2 Service currently unavailable" zustande. Richtig?
ACK
Gut, dann hab ich das mit postscreen scheinbar auch kapiert. :) Ich werd' dann das mal die Tage in Produktion schalten.
(Hier kannst Du als secondary MX noch einmal den primary angeben. Dann wird der Client-MTA mit grosser Wahrscheinlichkeit nach der ersten Abweisung gleich den Secondary probieren. Die Zeit zwischen Abweisung und Zustellerfolg wird so signifikant kürzer)
Ähhhh, wie meinen? Ich komm da nun nicht ganz mit. Was soll ich wo machen?
Servus Django
Am 30.10.2014 um 11:06 schrieb django@nausch.org:
HI Joda,
Nachdem Du mich bei Deinem Besuch angefixt hast, hab ich mich mal an postscreen vergriffen. Herausgekommen ist erst einmal folgende Konfiguration.
master.cf
smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd -o smtpd_milters=${spf_milter},${opendkim_milter},${opendmarc_milter},${amavisd_milter}
"ungewoehnlich" das hier reinzuschreiben... ausserdem moeglicherweise koennte die Verkettung von "diesen" Miltern zu Problemen fuehren wenn du nicht die letzte postfix version 2.11.3 nutzt aber moeglicherweise ist dir das ja schon klar bzw du hast es im Griff
https://sys4.de/de/blog/2014/09/20/fallstricke-mit-opendmarc-und-postfix/
bei einem Test wuerde ich opendmarc ( oder einfach alle milter ) erstmal weglassen, weil Thema fuer sich , und mich erst am Ende des Setups damit beschaeftigen wenn klar ist das alles "andere" funktioniert, meine persoenliche Meinung waere sogar ,opendmarc nur selektiv einzusetzen z.b mit milter-manager
dnsblog unix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy
main.cf ################################################################################
## Postscreen # # Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST # default: postscreen_access_list = permit_mynetworks postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_whitelist # # default: postscreen_blacklist_action = ignore postscreen_blacklist_action = drop
# Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS # default: postscreen_whitelist_interfaces = static:all postscreen_whitelist_interfaces = !88.217.171.167 static:all
# Django : 2014-10-29 - BEFORE 220 GREETING TESTS # default: postscreen_dnsbl_threshold = 1 postscreen_dnsbl_threshold = 2 # # default: postscreen_dnsbl_sites = postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 swl.spamhaus.org*2 # # default: postscreen_dnsbl_action = ignore postscreen_dnsbl_action = enforce # # default: postscreen_greet_banner = $smtpd_banner # # default: postscreen_greet_action = ignore postscreen_greet_action = enforce
# Django : 2014-10-29 - AFTER 220 GREETING TESTS # default: postscreen_bare_newline_action = ignore postscreen_bare_newline_action = drop # # default: postscreen_bare_newline_enable = no postscreen_bare_newline_enable = yes # # default: postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_enable = yes # default: postscreen_non_smtp_command_action = drop # # default: postscreen_pipelining_enable = no postscreen_pipelining_enable = yes # # default: postscreen_pipelining_action = enforce
Das Ganze scheint auf den ersten Blick recht gut zu funktionieren - ganz 100%ig bin ich mir da aber nicht sicher. Warum? na ab und ann sehe ich folgende Meldungen im maillog: Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: NOQUEUE: reject: RCPT from [193.169.180.107]:54690: 450 4.3.2 Service currently unavailable; from=return@news.mytoys.de, to=redacted@nausch.org, proto=ESMTP, helo=<mail17-107.srv2.de> Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: warning: unknown macro name "client" in expansion request
Der 450er stört mich nun erst mal nicht so recht, viel mehr diese WARNING: nknown macro name "client" in expansion request Was'n datt?
Wenn ich es richtig aus dem maillog gegrep't hab dann dürft das da der komplette zugehörige Sermon des ersten Zustellversuchs sein: Oct 30 09:43:38 vml000080 postfix/postscreen[14951]: CONNECT from [193.169.180.107]:54690 to [10.0.0.80]:25 Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: [193.169.180.107]54690: discarding EHLO keywords: DSN Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: NOQUEUE: reject: RCPT from [193.169.180.107]:54690: 450 4.3.2 Service currently unavailable; from=return@news.mytoys.de, to=redacted@nausch.org, proto=ESMTP, helo=<mail17-107.srv2.de> Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: warning: unknown macro name "client" in expansion request Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: PASS NEW [193.169.180.107]:54690 Oct 30 09:43:44 vml000080 postfix/postscreen[14951]: DISCONNECT [193.169.180.107]:54690
Dann kommt er wieder: Oct 30 09:53:54 vml000080 postfix/postscreen[14951]: CONNECT from [193.169.180.107]:55755 to [10.0.0.80]:25 Oct 30 09:53:54 vml000080 postfix/postscreen[14951]: PASS OLD [193.169.180.107]:55755 Oct 30 09:53:54 vml000080 postfix/smtpd[15632]: connect from mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:54 vml000080 postfix/smtpd[15632]: discarding EHLO keywords: DSN Oct 30 09:53:54 vml000080 smf-spf[12097]: SPF pass: ip=193.169.180.107, fqdn=mail17-107.srv2.de, helo=mail17-107.srv2.de, from=return@news.mytoys.de Oct 30 09:53:55 vml000080 postfix/smtpd[15632]: 3BD0175: client=mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:55 vml000080 postfix/cleanup[14362]: 3BD0175: message-id=re-pTf3SwushbLdwAjqbbGt4j-13RR982X-13ME1R6S-62QD4X@news.mytoys.de
Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: mail17-107.srv2.de [193.169.180.107] not internal Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: not authenticated Oct 30 09:53:55 vml000080 opendkim[1147]: 3BD0175: DKIM verification successful Oct 30 09:53:55 vml000080 opendmarc[1446]: 3BD0175: news.mytoys.de none Oct 30 09:53:58 vml000080 postfix/qmgr[10267]: 3BD0175: from=return@news.mytoys.de, size=96158, nrcpt=1 (queue active) Oct 30 09:53:58 vml000080 postfix/smtpd[15632]: disconnect from mail17-107.srv2.de[193.169.180.107] Oct 30 09:53:58 vml000080 postfix/lmtp[15548]: 3BD0175: to=redacted@nausch.org, relay=10.0.0.77[10.0.0.77]:24, delay=4.1, delays=4/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 redacted@nausch.org 0XDGBev7UVS+QAAArK2B9Q Saved) Oct 30 09:53:58 vml000080 postfix/qmgr[10267]: 3BD0175: removed
"PASS NEW" bedeutet doch, dass der Client alle Test bestanden hat und er einen temporären Whitelisting-Eintrag bekommen hat. Richtig?
Da ich in meiner Konfig "deep protocol tests" aktiviert habe, kann postscreen die Verbindung nicht mehr an den eigentlichen SMTP-Daemon weiterreichen. Richtig? Daher kommt auch der "450 4.3.2 Service currently unavailable" zustande. Richtig?
Aber was ist nun mit dieser Meldung >>unknown macro name "client" in expansion request<<? Die verstehe ich nicht ganz? Was will/soll mir das sagen? \o/
Ich fürchte, ich brauch da noch ein wenig Hilfe bevor ich datt janze auf meiner ersten Produktions-Maschine einsetze.
Servus Django
Best Regards MfG Robert Schetterer
HI Robert!
Quoting Robert Schetterer rs@sys4.de:
"ungewoehnlich" das hier reinzuschreiben...
Na ja, dafür bin ich bekannt für UNGEWÖHNLICHES! ;)
Ich binde jeweils nur die Milter ein, die ich benötige, abhängig, ob MTA <-> MTA oder MUA -> MSA
ausserdem moeglicherweise koennte die Verkettung von "diesen" Miltern zu Problemen fuehren wenn du nicht die letzte postfix version 2.11.3 nutzt aber moeglicherweise ist dir das ja schon klar bzw du hast es im Griff
Na ja, bis jetzt konnte ich nicht's Erschreckendes feststellen, was aber nicht heisst, dass ich ggf. was nicht mitbekommen habe. Und ja, ich benutze 2.11.13 Und ausserdem hat ein gewisser "p" von einer sys4 den "BASTSCHO-Stempel" auf ein gleichartiges System gedrückt - ergo: bastscho! ;)
bei einem Test wuerde ich opendmarc ( oder einfach alle milter ) erstmal weglassen,
Da die bist Dato immer ohne Murren ihren Dienst erledigt hatten, hatte ich die einfach weitermitlaufen lassen.
selektiv einzusetzen z.b mit milter-manager
Erzähl, was macht den milter-manager (noch) besser?
Servus Django
Am 30.10.2014 um 14:26 schrieb django@nausch.org:
HI Robert!
Quoting Robert Schetterer rs@sys4.de:
"ungewoehnlich" das hier reinzuschreiben...
Na ja, dafür bin ich bekannt für UNGEWÖHNLICHES! ;)
Ich binde jeweils nur die Milter ein, die ich benötige, abhängig, ob MTA <-> MTA oder MUA -> MSA
ausserdem moeglicherweise koennte die Verkettung von "diesen" Miltern zu Problemen fuehren wenn du nicht die letzte postfix version 2.11.3 nutzt aber moeglicherweise ist dir das ja schon klar bzw du hast es im Griff
Na ja, bis jetzt konnte ich nicht's Erschreckendes feststellen, was aber nicht heisst, dass ich ggf. was nicht mitbekommen habe. Und ja, ich benutze 2.11.13 Und ausserdem hat ein gewisser "p" von einer sys4 den "BASTSCHO-Stempel" auf ein gleichartiges System gedrückt - ergo: bastscho! ;)
bei einem Test wuerde ich opendmarc ( oder einfach alle milter ) erstmal weglassen,
Da die bist Dato immer ohne Murren ihren Dienst erledigt hatten, hatte ich die einfach weitermitlaufen lassen.
selektiv einzusetzen z.b mit milter-manager
Erzähl, was macht den milter-manager (noch) besser?
die Frage ist was man möchte, man möchte sicher jede Mail nach SPAM und Viren scannen, ob es sich "lohnt" jede Mail von einem eigenem Milter nach DMARC und SPF abzuklopfen ist eine andere Frage. Ausserdem muss man sich entscheiden wer DKIM machen soll AMAVIS kann das ja selbst.
Am Ende möchte man vieleicht möglichst wenig Pishing und SPAM ( Viren sowieso nicht ) , mit minimaler False Positive Rate bei max Performance und moeglichst wenig Support.
Klassifizierung wie Amavis es macht ist Fehler toleranter, als Milter die "hart" Ablehnen, bei DMARC und DKIM milter gibts schon mal "ungewollte" Ablehnungen was mehrere Grunde hat die im weitesten Sinne in der Komplexitaet des Standards zu suchen sind.
Der Milter Manager kann selektiv entscheiden z.b an Hand einer regex fuer welche Ipadresse er welchen Milter anwenden moechte, d.h z.b. nur fuer typische dyndns reverse dns , den Rest kann man dann z.b AMAVIS ueberlassen, ich hab es allerdings so noch nicht getestet, sondern bis jetzt nur nachgelesen.
Von Info Mails an Domain Owner wie es z.b bei DMARC vorgesehen ist, halte ich auch nicht viel, es ist zwar schoen dass das geht, aber die Welt hat im Zweifelsfalle schon genug Mail
Alles Genannte ist aber eine "persoenliche" Meinung und sicher nicht der Stein der Weisen, ausserdem muss man solche Massnahmen immer auf die entsprechenden Systeme "zuschneidern", gut wenn man schon logs hat und seine Pappenheimer kennt.
Servus Django
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
HI Robert,
Am 30.10.2014 um 16:59 schrieb Robert Schetterer:
die Frage ist was man möchte, man möchte sicher jede Mail nach SPAM und Viren scannen,
ja
ob es sich "lohnt" jede Mail von einem eigenem Milter nach DMARC und SPF abzuklopfen ist eine andere Frage.
auch ja, da MTA <-> MTA Traffic auf Port 25
Ausserdem muss man sich entscheiden wer DKIM machen soll AMAVIS kann das ja selbst.
Signing macht hier AMaViS, Verifying mach openDKIM (wegen openDMARC)
Am Ende möchte man vieleicht möglichst wenig Pishing und SPAM ( Viren sowieso nicht ) , mit minimaler False Positive Rate bei max Performance und moeglichst wenig Support.
ja, ja, ja, ja und ja. ;)
Klassifizierung wie Amavis es macht ist Fehler toleranter, als Milter die "hart" Ablehnen,
Amavis ist via Milter angebunden.
bei DMARC und DKIM milter gibts schon mal "ungewollte" Ablehnungen was mehrere Grunde hat die im weitesten Sinne in der Komplexitaet des Standards zu suchen sind.
Ja, da gebe ich Dir Recht, aber bis dato sind auf dem Testsystem noch keine Klagen an mich herangetragen worden.
... ich hab es allerdings so noch nicht getestet, sondern bis jetzt nur nachgelesen.
Danke für die Erklärungen!
ttyl Django
Räusper, räusper ähem ... ich schon wieder
Quoting django@nausch.org:
Aber was ist nun mit dieser Meldung >>unknown macro name "client" in expansion request<<? Die verstehe ich nicht ganz? Was will/soll mir das sagen? \o/
Das besagt, das der Depp - also ich - der den Mailserver konfiguriert hat, besser mal beim Abtippen aufpassen sollte: http://www.postfix.org/pipe.8.html
Da gibt es kein $client! Wo ich das "verbaut" hatte? Na, beim Parameter: smtpd_reject_footer Dort hatte ich statt $client_address "nur" $client drinnen. Hatte bis dato auch ohne Probleme funktioniert. Sonderbar ... :/
Als ich postscreen aktiviert hatte, nörgelte der PIPE-Daemon plötzlich rum, da: postscreen_reject_footer = $smtpd_reject_footer
Der postscren-Daemon kann anscheinen nicht mit dem Attribut $client arbeiten, der PIPE-Daemon schon.
Ich hab nun beim smtpd_reject_footer das Attribut $client_addres gesetzt und siehe da, weg sind die Meldungen. Das wäre also geklärt. Bleiben also "nur" noch die Verständnisfragen zu postscreen aus meinem Eingangs-Posting.
Servus Django
participants (5)
-
Alex JOST -
Django -
django＠nausch.org
-
Patrick Ben Koetter -
Robert Schetterer