From: Sean Reifschneider on 17 Mar 2010 20:27 I'm reporting this primarily because the other searching I've done has turned up this same error message, but with nothing that clearly points out what the root of the issue really is. I'm hoping someone can shed some light on it. We've been having little if any luck tracking down an issue where for a small sub-set of users their messages are causing the following to be logged: can't read SMFIC_HEADER reply packet header: Success The closest I've found in searching is this message: http://readlist.com/lists/postfix.org/postfix-users/13/67034.html Where Wietse says: The error code "Success" means that the connection was closed by the milter application itself, by the Sendmail libmilter library underneath the milter application, or that the milter application terminated. I'll have to read libmilter source code We've tried updating both the milter application portions of this. Our application uses pymilter, we updated to the latest version of that, built against Sendmail 8.14's libmilter. The previous version used a much older pymilter built against, probalby Sendmail 8.13's libmilter. This is all on CentOS 5.4 using Postfix 2.5.1 and 2.5.9. So we've tried 2 different versions of all the software without having any change. Here's exactly what gets logged: Mar 16 12:50:11 mailhost postfix/cleanup[9490]: warning: milter inet:127.0.0.1:2092: can't read SMFIC_HEADER reply packet header: Success Mar 16 12:50:11 mailhost postfix/cleanup[9490]: E3F4D1190080: milter-reject: END-OF-MESSAGE from dsl1-40.example.net[10.241.86.4]: 4.7.1 Service unavailable - try again later; from=<user(a)example.net> to=<otheruser(a)otherhost.example.net> proto=ESMTP helo=<semirandomstring> Nothing obvious is failing in the milter application. I have it logging tracebacks, so if it's a bug in the milter application causing it to fail we should have been seeing a message indicating that. The debugging I have enabled in the milter application doesn't show anything out of the ordinary there, I could add a bunch more debugging there to see if that pinpoints it. This is only impacting a couple of users, and seems to be only when they send mail. The milter in question checks the users quota and to see if they want to receive e-mail at that mailbox (it can be turned on and off by the user, without deleting their whole mailbox), if that helps. So we do want this milter running on the submission port -- it is a NOOP for recipients that are non-local. Any thoughts on this? Thanks, Sean -- Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
From: Sahil Tandon on 17 Mar 2010 21:25 On Wed, 17 Mar 2010, Sean Reifschneider wrote: > Mar 16 12:50:11 mailhost postfix/cleanup[9490]: warning: milter > inet:127.0.0.1:2092: can't read SMFIC_HEADER reply packet header: Success What is the output of 'postconf milter_protocol'? This might be totally unrelated, but I wonder if it has something to do with your problem: you're using pymilter built with Sendmail 8.14 libraries, which imply protocol 6, but Postfix < 2.6 defaults to milter_protocol = 2. -- Sahil Tandon <sahil(a)tandon.net>
From: Wietse Venema on 18 Mar 2010 07:57 Sean Reifschneider: > I'm reporting this primarily because the other searching I've done has > turned up this same error message, but with nothing that clearly points out > what the root of the issue really is. I'm hoping someone can shed some > light on it. > > We've been having little if any luck tracking down an issue where for a > small sub-set of users their messages are causing the following to be > logged: > > can't read SMFIC_HEADER reply packet header: Success > > The closest I've found in searching is this message: > > http://readlist.com/lists/postfix.org/postfix-users/13/67034.html What about the remedies suggested in the Postfix MILTER_README? If the Postfix milter_protocol setting specifies a too high version, the libmilter library simply hangs up without logging a warning, and you see a Postfix warning message like one of the following: warning: milter inet:host:port: can't read packet header: Unknown error : 0 warning: milter inet:host:port: can't read packet header: Success warning: milter inet:host:port: can't read SMFIC_DATA reply packet header: No such file or directory That's Sendmail libmilter hanging up. Wietse
From: Sean Reifschneider on 18 Mar 2010 19:34 On 03/18/2010 05:57 AM, Wietse Venema wrote: > If the Postfix milter_protocol setting specifies a too high > version, the libmilter library simply hangs up without logging We've tried protocol versions 2, 4, and 6 with the same error. We've also tried two different versions of the libmilter: 8.13 and 8.14. We're trying version 3 of the protocol right now, but it will take a while to know for sure what the result of that is. It only happens for a few specific users who only send mail a few times a day. My experience in the past has been that having the wrong protocol version causes problems on all the milter interactions. In this case the milter is working fine for almost all the requests, except for a couple of users (out of thousands). Thanks, Sean -- Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
From: Wietse Venema on 18 Mar 2010 21:08 Sean Reifschneider: > On 03/18/2010 05:57 AM, Wietse Venema wrote: > > If the Postfix milter_protocol setting specifies a too high > > version, the libmilter library simply hangs up without logging > > We've tried protocol versions 2, 4, and 6 with the same error. We've also > tried two different versions of the libmilter: 8.13 and 8.14. We're trying > version 3 of the protocol right now, but it will take a while to know for > sure what the result of that is. It only happens for a few specific users > who only send mail a few times a day. > > My experience in the past has been that having the wrong protocol version > causes problems on all the milter interactions. In this case the milter is > working fine for almost all the requests, except for a couple of users (out > of thousands). Unfortunately, it seems that my crystal ball isn't working today. Wietse
|
Next
|
Last
Pages: 1 2 Prev: reject_authenticated_sender_login_mismatch only for some logins Next: Relay Options |