Adriel wrote:

> Hi Gary,

>> If you are running amavisd-new as a before queue filter, I believe
>> this tells you what you already know, amavisd-new is fubar'd at
>> this point in time.

> I actually was running this server using the before-queue filtering
> method. However, while trying to figure out this problem, I decided to
> switch to after-queue filtering to see if it helped. This problem
> started happening while I was using the before-queue filtering method.
> I don't know if this particular message was the cause when I was
> running the before-queue method, though.

>> # mailq | grep [EMAIL PROTECTED]
>> 
>> ID             size time                 sender
>> B588616D23      643 Thu Sep  8 11:51:20  [EMAIL PROTECTED]
>> 
>> # postsuper -d B588616D23
>> 
>> This ID should match the problem message in your logs (so I suppose you
>> could simply get the ID from your log).

> I was thinking about keeping the message in the queue to see if I
> could get any help on debugging it, however your previous comment
> about the before-queue filtering method being fubared changed my mind.
> I deleted the message from the queue and I will wait to see if another
> message like it appears and causes this problem. If it doesn't happen
> again, I will assume that it was something to do with before-queue
> filtering, otherwise, I will get another chance to debug.

> Adriel

I think you are better off using an after queue filter. What I meant
by my comment was I believe the particular message in question
had caused amavisd-new to stop responding. At that point Postfix could
not talk to amavisd-new, so it returned this error.

"smtpd_proxy_timeout (default: 100s): Timeout for connecting to the
before-queue content filter and for sending and receiving commands
and data. All proxy errors are logged to the maillog file. For privacy
reasons, all the remote SMTP client sees is "451 Error: queue file
write error". It would not be right to disclose internal details
to strangers."

Also, I think when changing something of this nature, it might be a
good idea to run 'postsuper -r ALL' to requeue any messages.

After I thought about it for 20 seconds, if you were using a
before queue filter, I'm now guessing the message never actually would
have made it to the deferred queue. I'm not certain, but changing to
an after-queue filter may have given you the opportunity to delete it.

Gary V



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to