[Postfixbuch-users] Daten in /var/spool/amavis/tmp werden nicht gelöscht

[Frank Fiene]

On Saturday 23 December 2006 13:46, Patrick Ben Koetter wrote:
> * Frank Fiene <ffiene at veka.com>:
> > On Saturday 23 December 2006 12:27, Patrick Ben Koetter wrote:
> > > > @keep_decoded_original_maps = (new_RE(
> > > > # qr'^MAIL$',   # retain full original message for virus
> > > > checking (can be slow) qr'^MAIL-UNDECIPHERABLE$', # recheck
> > > > full mail if it contains undecipherables qr'^(ASCII(?!
> > > > cpio)|text|uuencoded|xxencoded|binhex)'i,
> > >
> > > Amavis würde die einzelnen "parts" einer Mail nur für
> > > "MAIL-UNDECIPHERABLE" und (ASCII(?!
> > > cpio)|text|uuencoded|xxencoded|binhex) aufbewahren.
> > >
> > > Schon mal die Daten in /var/spool/amavis/tmp angesehen?
> > > Entsprechen sie (ausschliesslich) diesen Kriterien?
> >
> > Hmm, ich habe mir mal ein paar Mails angeschaut, sind alles
> > Text-Mails, teilweise mit HTML-Mail hinterher oder mal mit einer
> > GIF-Datei.
>
> Dann sind hier IMO andere Mechanismen als keep_decoded_original_maps
> dafür verantwortlich, dass das Entfernen nicht greift.
>
> > Habe keine uuencoded-Dateien gefunden, die müsster er aber auch
> > bearbeiten können, uudecide ist installiert.
> >
> > > > Auf einem Server ist das Spool-Dir voll auf dem anderen nicht.
> > > > Auf dem, wo die Daten nicht gelöscht werden, ist SuSE-10.1
> > > > installiert. Postfix-2.2.9 (SuSE)
> > > > amavisd-new-2.3.3 (SuSE)
> > > > clamav-0.88.7 (SuSE)
> > > > spamassassin-3.1.7 (CPAN)
> > >
> > > Worin unterscheiden sich die Server?
> >
> > Der "funktionierende" Server hat SuSE-10.0 installiert.
> > Postfix-2.2.5 (SuSE)
> > amavisd-new-2.3.3 (SuSE)
> > clamav-0.88.7 (SuSE)
> > spamassassin-3.1.7 (CPAN)
> >
> > Also bis auf Postfix identisch.
> > Beide Server habe einen mx-Eintrag mit derselben Priorität.
>
> Also spontan fällt mir jetzt auch nichts mehr ein. Ich würde jetzt
> amavisd verbose im Debug Mode starten, eine Mail aus tmp nochmal
> durchjagen und versuchen herauszufinden, ob die Mail ein weiteres Mal
> nicht gelöscht wird und an welcher Stelle in der Verarbeitung das
> (nicht) geschieht. Was oder wer ist der letzt, der diese Mail
> anrührt? amavisd? SA? Clamav?

Ich glaube, ich habe etwas gefunden


Dec 23 13:56:37 proxy01 amavis[16223]: (16179-01-8) run_command: child 
process [16223]: Error closing main::stdin: Bad file descriptor 
at /usr/sbin/amavisd line 1872, <GEN33> line 316.\n
Dec 23 13:56:37 proxy01 amavis[16179]: (16179-01-8) TROUBLE in 
check_mail: parts_decode_ext FAILED: parsing file(1) results - missing 
last 3 results at (eval 58) line 154.
Dec 23 13:56:37 proxy01 amavis[16179]: (16179-01-8) PRESERVING EVIDENCE 
in /var/spool/amavis/tmp/amavis-20061223T135637-16179

Das macht ja dann wohl Sinn mit dem keep_decoded_original_maps.

Jetzt muss ich nur noch herausfinden wo der Fehler liegt.

Ich denke, es liegt an dem Net::Server oder so, welches ich für postgrey 
upgedatet habe. Mist.
-- 
VEKA AG - Dieselstraße 8 - 48324 Sendenhorst
ffiene at veka.com - Tel:02526-29-6200
--
Ein Unternehmen der Laumann-Gruppe