From: Sean Reifschneider on
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
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
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
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
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