The only difference between the 2 tests is the debug_peer_list parameter (postfix, content filter, filter, message are the same).
If the filter is buggy, the result should be the same but this is not the case here. So, I would like to understand why the behaviour is different once I enable debug on postfix ... Thanks! Le 14/09/15 19:07, Viktor Dukhovni <postfix-us...@dukhovni.org> a écrit : > > On Mon, Sep 14, 2015 at 11:21:51AM +0200, POSTFIX MAIL wrote: > > > But the mail was rejected by the content filter and I didn't find the mail > > in the deferred queue. In fact, I was surprised to see that Postfix > > considers the mail as sent: > > > > ... relay=127.0.0.1[127.0.0.1]:10025, conn_use=4, delay=0.15, > > delays=0.15/0/0/0, dsn=2.0.0, status=sent (221 bye) > > Your filter is buggy, and gets out of sync with the SMTP protocol > commands sent by the client. Perhaps it does not support PIPELINING > or is otherwise defective. Here its 221 response to the "QUIT" > part of a pipelined ".<CRLF><QUIT><CRLF>" is interpreted by Postfix > as success "DOT" response, i.e. that the message is accepted. > > Had the filter provided the required "DOT" response, there would > have been no problem. > > > So, I decided to enable the debug mode (debug_peer_list) and this time, > > I found the mail in deferred queue: > > > > relay=127.0.0.1[127.0.0.1]:10025, delay=0.38, delays=0.32/0.03/0/0.03, > > dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] > > while sending end of data -- message may be sent more than once) > > This time, the filter misbehaved by hanging up. > > > That is a strange behaviour. What do you think ? > > Here's a nickel kid, get yourself a better filter! [1] > > -- > Viktor. > > [1] http://2ndscale.com/rtomayko/2006/that-dilbert-cartoon >
