[Postfixbuch-users] UUCP, rmail, sendmail und amavis

[Sandy Drobic]

Christian Roessner wrote:
> Hallo Sandy,
> 
> Sandy Drobic schrieb:
>> Christian Roessner wrote:
>>> Nochmal Hallo,
>>>
>>> ich bin am Verzweifeln. Ich sitze jetzt ungelogen seit heute Morgen an
>>> diesem Problem und ich habe absolut keine Ahnung mehr, wie ich es noch
>>> lösen könnte.
>> Ich habe keine "postconf -n"-Ausgaben oder Logzeilen gesehen. Ohne dies
>> ist es schwierig zu sagen, was man machen kann.
>> Poste doch bitte mal "postconf -n" von MX1, die master.cf von MX1 und die
>> Logzeilen einer Beispiel-Mail, wenn sie von MX1 entgegengenommen wird.
>>
> 
> Hier postconf -n (MX1):
> 
> body_checks = regexp:/etc/postfix/map_body_checks_regexp
> content_filter = amavis:[127.0.0.1]:10024
> header_checks = regexp:/etc/postfix/map_header_checks_regexp
> mime_header_checks = regexp:/etc/postfix/map_mime_header_checks_regexp

> smtpd_helo_restrictions = 
	...check_helo_access btree:/etc/postfix/map_sender_access_fakelocal,
> mysql:/etc/postfix/mysql-check_helo_access.cf

> smtpd_restriction_classes = spamprotection_class
> smtpd_sender_restrictions =  btree:/etc/postfix/map_sender_access

> transport_maps = btree:/etc/postfix/map_transport
> virtual_transport = maildrop

Steckt in einer dieser Dateien als Rechte-Hand-Ergebnis eine FILTER
Aktion, die nach Amavisd-new weiterreicht?

Eine Methode, die sicher den Kreis der Verdächtigen einschränkt, ist, nur
in master.cf beim smtpd explizit den content_filter anzugeben auf den
erwünschten Transporten und ihn dafür aus main.cf herauszulöschen.

Wenn dann noch ein Filter zuschlägt, dann nur deshalb, weil eine
FILTER-Aktion in header/body_check dies sagt oder in einer der
check_*_access maps.

> master.cf (MX1):
> 
> #
> # Postfix master process configuration file.  For details on the format
> # of the file, see the Postfix master(5) manual page.
> #
> # ==========================================================================
> # service type  private unpriv  chroot  wakeup  maxproc command + args
> #               (yes)   (yes)   (yes)   (never) (100)
> # ==========================================================================
> smtp      inet  n       -       -       -       -       smtpd

Hier kommt der content_filter durch.

Ansonsten sehe ich aber nicht, weshalb der content_filter zuschlagen
sollte. Wie genau kommt die Mail von mx2 nach mx1? Welcher Transport ist
eingestellt für die Relay_domains?


> Und hier noch mal eine Beispiel-Mail:
> 
> Return-Path: <root at mx2.vls07.wavecon.de>
> Delivered-To: postmaster at roessner-net.com
> Received: from localhost (localhost.localdomain [127.0.0.1])
> 	by mx1.roessner.it-zahner.de (Postfix) with ESMTP id 0647A2835A
> 	for <postmaster at roessner-net.com>; Thu, 10 May 2007 08:25:10 +0200 (CEST)
> Received: from mx1.roessner.it-zahner.de ([127.0.0.1])
> 	by localhost (mx1.roessner.it-zahner.de [127.0.0.1]) (amavisd-new, port
> 10024)
> 	with ESMTP id 17684-03 for <postmaster at roessner-net.com>;
> 	Thu, 10 May 2007 08:25:08 +0200 (CEST)
> Received: by mx1.roessner.it-zahner.de (Postfix, from userid 10)
> 	id A28BB283B3; Thu, 10 May 2007 08:25:08 +0200 (CEST)
        ^^^^^^^^^^^^^

Diese Queue-ID, was steht dazu im Log von MX1? Über welchen Transport
genau kam die Mail dann herein und dann nach Amavisd-new?


-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com