[Postfixbuch-users] Postfix und Kaspersky

[Stefan Förster]

* Tim Macholl <macholl at scienlab.de>:
> Stefan Förster schrieb:
>> * Tim Macholl <macholl at scienlab.de>:
>>> 127.0.0.1:10025 inet    n       -       y       -       10       smtpd
>>>         -o content_filter=kav4lms_filter:127.0.0.1:10026
>>
>> Die fehlenden eckigen Klammern hier lösen jedesmal einen MX-Lookup
>> aus.

Hast Du das abgestellt?

> T(6) 127.0.0.1:10024 -> 127.0.0.1:47772 [AP]
>   220 [127.0.0.1] ESMTP amavisd-new service ready.. 

Wir beobachten hier den ersten Durchlauf durch einen Content-Filter.
Die Mail ist zu diesem Zeitpunkt bereit in der Queue, das Routing
wurde durch die CF-Anweisung des empfangenden smtpd verbogen.

> ##
> T(6) 127.0.0.1:47772 -> 127.0.0.1:10024 [AP]
>   Received: from [IPv6:::1] (localhost [IPv6:::1])...by server.office.bo 
> (Postfix) with ESMTP id 0003F1FA345...for <root at scienlab.de>; Thu, 18 F
>   eb 2010 11:16:57 +0100 (CET)..Message-ID:  
> <4B7D1399.600 at scienlab.de>..Date: Thu, 18 Feb 2010 11:16:57 +0100..From:  
> Tim Macholl <macholl at scienlab.de>..U
>   ser-Agent: Thunderbird 2.0.0.23 (X11/20090817)..MIME-Version: 1.0..To: 
> root at scienlab.de..Subject: test_kav2..Content-Type: text/plain;  
> charset=ISO-8859
>   -15..Content-Transfer-Encoding: 7bit....nochn test  
> quasi.......................................QUIT.. 

Die Übermittlung an amavisd-new ist abgeschlossen, wir erwarten in
diesem Fall nun den Austausch zwischen amavisd-new und dem zweiten,
auf Port 10025 lauschenden smtpd hören zu können.

"Hören" trifft es natürlich nicht so ganz...

> ############
> T(6) 127.0.0.1:10025 -> 127.0.0.1:34515 [AP]
>   220 server.office.bo ESMTP Postfix.. 

Tatsache, amavisd-new kommuniziert mit dem zweiten smtpd, welcher auf
Port 10025 lauscht.

> T(6) 127.0.0.1:10025 -> 127.0.0.1:34515 [AP]
>   250 2.0.0 Ok: queued as 298CC1FA347.. 

Der Empfangende smtpd hat die Nachricht angenommen und unter neuer ID
in die Queue gelegt. Wir erwarten, daß amavisd-new nun ebenfalls den
Empfang der Mail quittiert.

>
> ####
> T(6) 127.0.0.1:10024 -> 127.0.0.1:47772 [AP]
>   250 2.0.0 Ok, id=15029-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok:  
> queued as 298CC1FA347.. 

Und genau das tut amavisd-new auch: Es teilt dem einlifernden
Postfix-smtp-Client mit, daß alles gut ist. Als nächstes sollten wir
den Durchlauf durch den Content-Filter auf Port 10026 erleben.

>
> ##
> T(6) 127.0.0.1:10024 -> 127.0.0.1:47772 [AP]
>   221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel.. 

Hier sehen wir, daß amavisd-new von sich aus die Verbindung schließt.
Siehe dazu die nächste Anmerung.

>
> #######################################################
> T(6) 127.0.0.1:10025 -> 127.0.0.1:34515 [AP]
>   421 4.4.2 server.office.bo Error: timeout exceeded.. 
>
> ###############################################

Und das hier bedeutet, daß der smtpd auf Port 10025 dem amavisd-new
SMTP-Client mitteilt, daß er die Verbindung wegen Inaktivität
geschlossen hat. Da war mal was mit smtp-Connection-Caching, ich habe
das bei mir einfach mit 

$smtp_connection_cache_enable = 0;
$smtp_connection_cache_on_demand = 0;

abgeschaltet. Geht garantiert auch eleganter, in den Auswertungen bei
mir hat der Auf-/Abbau der TCP-Verbindung inklusive EHLO/LHLO nie
irgendwie relevante Prozentwerte erreicht, also war's mir wurscht.

> Jemand eine Idee?

Tja, das war jetzt einfach alles furchtbar unterhaltsam und so, hat
uns aber keinen Schritt weitergebracht. Mit wem auch immer Postfix
beim zweiten Durchlauf durch die Mail-Queue sprechen wollte, wir sehen
das hier nicht. Entweder hast Du die Filter-Parameter für ngrep
schlecht gewählt oder Du hast ein Konfigurationsproblem, welches mir
entgangen ist. Oder vielleicht DNS-Probleme.

Idee: Du kannst in der master.cf dem smtp-Transport, welcher an den
KAV weiterleitet, ein "-v" mit auf den Weg geben.


Stefan