Procmail bzw. Postfix Prob

[mario77]

Hallo liebes Forum

nach einem längeren Urlaub im Norden Deutschlands
bin ich wieder da, und hab folgendes Prob:
OS CentOs5.2 aktuelle ISPConfigVersion
Auf einer Kundendomain ist eine Alias-Emailadresse eingerichtet, mit ca.
90 Empfängern. Offensichtlich hat da kürzlich jemand eine recht grosse
Email über dieses Alias versendet welche folgende Fehlermeldung gleich
für mehrere (seltsamer Weise nicht für alle) Empfänger hervor brachte.

< myaddress[EMAIL="myalias@vabw.de"]@[/EMAIL]sample.com> (expanded from myalias[EMAIL="myalias@vabw.de"]@sample.com[/EMAIL]): Command time
limit
exceeded: "/usr/bin/procmail -f-". Command output: procmail: Couldn't
create "/var/mail/myadress"

Die aufgeführte command time, steht in postfix auf dem Defaultwert
command_time_limit = 1000s
Viel interessanter bzw. beunruhigender find ich den Createpfad, dass hat da
so nix zu suchen.

Hat jemand ne Idee wodran es liegen könnte?

 

[Till]

Hast Du bei Dir eine manuell geänderte procmailrc.master im Einsatz, oder die Standard datei von ISPConfig?

 

[mario77]

Sieht nach der normalen aus würd ich sagen, ist keine in customized_...
drinne (siehe weiter unten).

Ich muss mich korrigieren, laut ISPConfig-Interface ist es eine Weiterleitung.
Und die command_time wird wohl dadurch überschritten, dass externe
Emailadressen darüber angesprochen werden, die Fehlercodes zurückgeben.
(z.B. message size 13643119 exceeds size limit 10240000 of server EXTERN).

Die folgenden Weiterleitungsversuche haben dann, die im ersten Beitrag
aufgeführte Fehlermeldung.




procmailrc.master:
==============
{MAILDIR_COMMENT}MAILDIR=$HOME/Maildir/
{MAILDIR_COMMENT}DEFAULT=$MAILDIR
{MAILDIR_COMMENT}ORGMAIL=$MAILDIR
{QUOTA}
INCLUDERC={PMDIR}/.mailsize.rc
{QUOTA_COMMENT}INCLUDERC={PMDIR}/.quota.rc
{ANTIVIRUS_COMMENT}INCLUDERC={PMDIR}/.antivirus.rc
{MAILSCAN_COMMENT}INCLUDERC={PMDIR}/.local-rules.rc
{MAILSCAN_COMMENT}INCLUDERC={PMDIR}/.html-trap.rc
{SPAMASSASSIN_COMMENT}INCLUDERC={PMDIR}/.spamassassin.rc
{AUTORESPONDER_COMMENT}INCLUDERC={PMDIR}/.autoresponder.rc

 

[Till]

Ich denke nicht, dass es an den Rückmeldungen der anderen Server liegt, da procmail die meines Erachtens garnicht bekommt. Ich denke das Time Limit wird einfach nur wegen der Anzahl der Weiterleitungen erreicht. Versuch es bitte mal hoch zu setzen.

 

[mario77]

Deiner Meinung würde ich mich so grundstäzlich anschliessen

Ich habe gestern command_time_limit = 10000s gesetzt, und auf weiter Fehlermeldungen gewartet.... Wie das so ist, werden auch welche gefunden.

Ein User mit Outlook 2000 kriegt die Meldung:
"Zur Übermittlung an diesen Empfänger steht kein Dienst zur Verfügung"
Beim Versand an eine Outlook eigenen Empfängergruppe, sehr lange Liste
aufgrund der Fehlermeldung die er mir geschickt hat.

Sieht so aus, als würden da noch andere limits fehlen

 

[Till]

Aber eine Outlook Empfängergruppe sollte mit procmail nichts zu tun haben. Outlook verschickt die vermutlich alle als eine Mail mit riesigem BCC Feld. Dann würde ich es mal mit Folgenden Variablen versuchen:

smtpd_recipient_limit
default_recipient_limit
default_extra_recipient_limit
smtpd_recipient_overshoot_limit

am Besten mal mit postconf -d bzw. -n checken, wie hoch die gesetzt sind.

 

[mario77]

Danke für deine Antwort!

u es stimmt, die neuen Fehlermeldungen hatten natürlich nichts mit procmail
zu tun. Präzise wie immer Till

Das einzige was ich geändert habe ist command_time_limit, alle anderen
Werte waren wie gewünscht. Bislang gibt es keine neuen Probs in der Richtung.

Wobei mich die Ursache des ursprünglichen Fehlers schon interessieren würde??

Mittels ein paar cat/greps hab ich noch folgende procmail-Probs gefunden:
(Zur Erklärung spammail-almost ist eine Emailadresse in der alle Spams gesammelt werden, die > Level 5 von Spamassassin eingestuft werden.)

Aug 26 14:16:31 <myserver> sendmail[20701]: m7QCGUR4020701: from=<user1>, size=123, class=0, nrcpts=1, msgid=200808261216.m7QCGUR4020701@<sample.com>, relay=<user1>@localhost
Aug 26 14:16:31 <myserver> sendmail[20701]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 26 14:16:31 <myserver> < sendmail[20701]: m7QCGUR4020701: to=admispconfig@localhost.localdomain, ctladdr=<user1> (10010/10002), delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=30123, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (Ok: queued as 23CC4521259)
Aug 26 17:13:39 <myserver> sendmail[20701]: m7QFDdRf020701: from=spammail-almost, size=127, class=0, nrcpts=1, msgid=<200808261513.m7QFDdRf020701<sapmle.com>>, relay=spammail-almost@localhost
<--------- bis hierhin ist alles ok würd ich schätzen
dann kommt --------->
Aug 26 17:13:39 <myserver> sendmail[20701]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 26 17:13:39 <myserver> sendmail[20701]: m7QFDdRf020701: to=admispconfig@localhost.localdomain, ctladdr=spammail-almost (10066/10002), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30127, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (Ok: queued as AC16D520E37)
Aug 27 13:33:22 <myserver> procmail[20701]: Couldn't rename bogus "/var/mail/admispconfig" into "/var/mail/BOGUS.admispconfig.LkgU"

Auch wenn die Logauszüge schon etwas älter sind, ist das Problem
nach wie vor vorhanden...

Any ideas?

 

[Till]

Ruf einfach mal auf:

rm -f /var/mail/admispconfig

Da diese Mailbox nicht in Verwendung ist, der User admispconfig verwendet nämlich ein script zur Verarbeitung der Mails im Verzeichnis /home/admispconfig/