[Postfixbuch-users] Problem mit fehlerhaft generierten Warnungen

Matthias Haegele mhaegele at linuxrocks.dyndns.org
Do Jun 28 16:07:02 CEST 2007


Tobias Hiller schrieb:
> Matthias Haegele schrieb:
>> Tobias Hiller schrieb:
>>   
>>> Matthias Haegele schrieb:
>>>     
>>>> Tobias Hiller schrieb:
>>>>   
>>>>       
>>>>> Sandy Drobic schrieb:
>>>>>     
>>>>>         
>>>>>> Tobias Hiller wrote:
>>>>>>   
>>>>>>       
>>>>>>           
>>>>>>> nighthawk schrieb:
>>>>>>>     
>>>>>>>         
>>>>>>>             
>>>>>>>> On 6/27/07, Tobias Hiller <tobias.hiller at googlemail.com> wrote:
>>>>>>>>   
>>>>>>>>       
>>>>>>>>           
>>>>>>>>               
>>>>>>>>> Jun 27 09:30:11 SERVER postfix/qmgr[16976]: warning:
>>>>>>>>> qmgr_active_done_3_generic: remove 30394D40FC from active: No such file
>>>>>>>>> or directory
>>>>>>>>>     
>>>>>>>>>         
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>> Blind geraten... Könnte es daran liegen? Postfix erkennt, daß mit der
>>>>>>>> Mail was nicht stimmt und teilt Dir das mit?
>>>>>>>>   
>>>>>>>>       
>>>>>>>>           
>>>>>>>>               
>>>>>>> Moin, danke erstmal für die Antwort.
>>>>>>> Also ehrlich gesagt, wüßte ich nicht, was an den mails nicht stimmen 
>>>>>>> sollte...
>>>>>>>     
>>>>>>>         
>>>>>>>             
>>>>>> An den Mails ist vermutlich alles in Ordnung, aber nicht in der Weise, wie
>>>>>> sie aus der Queue entfernt werden. Ein Prozess greift da ein, der nicht
>>>>>> vorgesehen ist. Du kannst diese Warnung provozieren, indem du eine
>>>>>> verzögerte Mail mit "postsuper -d queue-id" aus der Mail löscht. Dann wird
>>>>>> auch eine entsprechende Meldung im Log generiert.
>>>>>>
>>>>>> Postfix betrachtet es jedoch nur als informative Meldung, nicht als "fatal
>>>>>>  error". Trotzden solltest du herausfinden, welcher Prozess Postfix da in
>>>>>> die Suppe spuckt.
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>           
>>>>> Also was mir nun aufgefallen ist, ist dass es meist ein paar minuten vor 
>>>>> der Meldung qmgr_active... eine Email gibt, die aufgrund eines Virusses 
>>>>> aussortiert wurde.
>>>>> Kann ich irgendwie genau schauen, welche mail das war? Ich habe jetzt 
>>>>> nur die clamav.log angeschaut.
>>>>> Außerdem habe ich vorhin noch die Meldung warning: qmgr_active_corrupt: 
>>>>> save corrupt file queue active id DBD0FD414C: No such file or directory 
>>>>> erhalten.
>>>>> Gesagt sei vielleicht noch, dass es aber nicht immer die 
>>>>> unzustellbarkeitsnachricht gibt, sobald im log warning: 
>>>>> qmgr_active_done_3_generic auftaucht....
>>>>>     
>>>>>         
>>>> Du verwendest also:  clamav u. spamassassin?
>>>>
>>>> evtl. noch mit amavisd-new? (dann lägen Sie in 
>>>> /var/lib/amavis/virusmails/* (spam*|virus*)., falls Quarantäne an)
>>>>
>>>> (bei debian könntest du die installierten Pakete mittels dpkg -l 
>>>> anzeigen lassen)
>>>>
>>>> Was passiert eigentlich wenn sich das Script mit einem Fehler beendet?
>>>> Ich sehe keinen Filter in der postconf -n Ausgabe, wie kommen die Mails 
>>>> überhaupt zum Virenscanner, wo ist das definiert?
>>>>
>>>>   
>>>>       
>>>>> Tobias
>>>>>     
>>>>>         
>>>>   
>>>>       
>>> Danke für deine Mühe, amavis wird nicht verwendet.
>>> Die mails müssten eigentlich folgendermaßen gescannt werden:
>>> In der master.cf steht:
>>>
>>> #SMPT an Clamsmtp
>>> smtp      inet  n       -       -       -       -       smtpd -o 
>>> content_filter=scan:127.0.0.1:10025
>>>
>>> #Clamsmtp zurück an Postfix Spamassassin
>>> 127.0.0.1:10026 inet  n -       n       -       -      smtpd
>>>         -o content_filter=filter

Da hast du deinen Filter (das Script) der da *irgendwas macht*,
(über das lokale sendmail die Mail wieder in Postfix reinhaut, dort ist 
vmtl. der "Hund begraben")? ...
Evtl. kriegt Postfix hier keine ordentliche Rückmeldung und kann deshalb 
die "queue-files" nicht removen ...

>>>         -o 
>>> receive_override_options=no_unknown_recipient_checks,no_header_body_checks
>>>         -o smtpd_helo_restrictions=
>>>         -o smtpd_client_restrictions=
>>>         -o smtpd_sender_restrictions=
>>>         -o smtpd_recipient_restrictions=permit_mynetworks,reject
>>>         -o mynetworks_style=host
>>>         -o smtpd_authorized_xforward_hosts=127.0.0.0/8
>>>
>>> und dann gibt es ja noch die clamsmtpd.conf:
>>> # 
>>> ------------------------------------------------------------------------------
>>> #                        SAMPLE CLAMSMTPD CONFIG FILE
>>> # 
>>> ------------------------------------------------------------------------------
>>> #
>>> # - Comments are a line that starts with a #
>>> # - All the options are found below with their defaults commented out
>>>
>>>
>>> # The address to send scanned mail to.
>>> # This option is required unless TransparentProxy is enabled
>>> OutAddress: 10026
>>>
>>> # The maximum number of connection allowed at once.
>>> # Be sure that clamd can also handle this many connections
>>> #MaxConnections: 64
>>>
>>> # Amount of time (in seconds) to wait on network IO
>>> #TimeOut: 180
>>>
>>> # Address to listen on (defaults to all local addresses on port 10025)
>>> Listen: 127.0.0.1:10025
>>>
>>> # The address clamd is listening on
>>> ClamAddress: /var/run/clamav/clamd.ctl
>>>
>>> # A header to add to all scanned email
>>> Header: X-AV-Checked: ClamAV using ClamSMTP
>>>
>>> # Directory for temporary files
>>> TempDirectory: /var/spool/clamsmtp
>>>
>>> # PidFile: location of PID file
>>> PidFile: /var/run/clamsmtp/clamsmtpd.pid
>>>
>>> # Whether or not to bounce email (default is to silently drop)
>>> #Bounce: off
>>>
>>> # Whether or not to keep virus files
>>> #Quarantine: off
>>>
>>> # Enable transparent proxy support
>>> #TransparentProxy: off
>>>
>>> # User to run as
>>> User: clamsmtp
>>>
>>> Ich habe mir auch mal einfach noch logs der Mails mit Fehlermeldung und 
>>> ohne Fehlermeldung angeschaut.
>>> Auffällig ist eben, dass normal eben nur 1 pickup gemacht wird und bei 
>>> den Mails wo der Fehler auftritt 2 pickups vorkommen.
>>>     
>> Bei amavis ist das bei mir so:
>>
>> (Sollte doch eigentlich gleiches Prozedere sein oder?)
>>
>> Auszug aus /etc/postfix/main.cf
>> content_filter = amavisd-new:[127.0.0.1]:10024
>>
>> master.cf:
>>
>>   
>>> #added by mh TRANSPORT for ESMTP AMAVISD-NEW see corresponding main.cf entry
>>> amavisd-new     unix    -       -       n       -       2       smtp
>>>  -o smtp_data_done_timeout=1200s
>>>  -o disable_dns_lookups=yes
>>> #added by mh REINJECTION PATH for AMAVISD-NEW see corresponding main.cf entry
>>> 127.0.0.1:10025 inet n  -       n       -       -       smtpd
>>>  -o content_filter=
>>>  -o local_recipient_maps=
>>>  -o relay_recipient_maps=
>>>  -o smtpd_restriction_classes=
>>>  -o smtpd_client_restrictions=
>>>  -o smtpd_helo_restrictions=
>>>  -o smtpd_sender_restrictions=
>>>  -o smtpd_recipient_restrictions=permit_mynetworks,reject
>>>  -o mynetworks=127.0.0.0/8
>>>  -o strict_rfc821_envelopes=yes
>>> #end added by mh
>>>     
>> Bei deiner Lösung fehlt der Teil in main.cf,
>> ob das zwingend erforderlich ist, k.A. woher hast du das, aus einem Howto?
>> Spamassassin läuft als Daemon?
>>
>> (Ist schon ein Weilchen her, bei mir ...)
>>
>>   
>>> Tobias
>>>     
>>
>>
>>   
> Danke für den Hinweis. Also bei dir hast du in der main.cf contentfilter 
> = amavisd-new:[127.0.0.1]:10024
> und das hast du dann auch in der master.cf stehen?
> Das würde ja heißen, dass ich nur noch in der main.cf
> content_filter=scan:127.0.0.1:10025 setzen muss...
> Ich habe den Server leider nicht konfiguriert, sondern quasi so übernommen.

Das würde in meinem Fall heissen dass alle Mails generell an den 
amavisd-new übergeben werden.
Und wieder an Postfix zurück, bei diesem 2. Durchlauf wird nicht! 
nochmals durch den Filter (amavisd-new) gegangen,
-o content_filter = , der Content Filter ist leer. Sonst würden die 
Mails immer da hin und her in der Endlosschleife ...

Ist aber auch ein bisschen ein anderer Ansatz da bei mir alles über smtp 
abläuft und du noch das "lokale sendmail" mit im Boot hast ...
Wenn ich das richtig verstanden habe ...

> Tobias


-- 
Grüsse/Greetings
MH


Dont send mail to: ubecatcher at linuxrocks.dyndns.org
--




Mehr Informationen über die Mailingliste Postfixbuch-users