Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

milter-greylist rejecting all mail

milter-greylist rejecting all mail

2009-01-20 by Greg Troxel

I have been running milter-greylist from pkgsrc successfully on
NetBSD/i386 4-stable with postfix 2.5.x for a long time. I also use
spamass-milter. Recently I started getting the following (private data
redacted; it all looked fine).

Jan 19 11:47:38 hostname postfix/smtpd[16975]: warning: milter unix:/var/milter-greylist/milter-greylist.sock: can't read SMFIC_RCPT reply packet header: Connection timed out
Jan 19 11:47:38 hostname postfix/smtpd[16975]: NOQUEUE: milter-reject: RCPT from sending.host[ip.addr.c.d]: 451 4.7.1 Service unavailable - try again later; from=<fromuser@them> to=<user@hostname> proto=ESMTP helo=<fqdn.org>


The only thing that I think changed is that my box went from having a v6
address that didn't work to one that did, but that happened several days
before the problem.

It sort of looks like milter-greylist has gone out to lunch and doesn't
answer in time. Could this happen with bad RBL servers? - I do have a
lot of rules to delay longer for hosts on blocklists.


I will look further, but thought I'd mention this in case anyone else
has seen it.

Re: [milter-greylist] milter-greylist rejecting all mail

2009-01-21 by Petar Bogdanovic

On Tue, Jan 20, 2009 at 08:25:31AM -0500, Greg Troxel wrote:
> 
> I have been running milter-greylist from pkgsrc successfully on
> NetBSD/i386 4-stable with postfix 2.5.x for a long time.  I also use
> spamass-milter.  Recently I started getting the following (private data
> redacted; it all looked fine).
> 
> Jan 19 11:47:38 hostname postfix/smtpd[16975]: warning: milter unix:/var/milter-greylist/milter-greylist.sock: can't read SMFIC_RCPT reply packet header: Connection timed out
> Jan 19 11:47:38 hostname postfix/smtpd[16975]: NOQUEUE: milter-reject: RCPT from sending.host[ip.addr.c.d]: 451 4.7.1 Service unavailable - try again later; from=<fromuser@them> to=<user@hostname> proto=ESMTP helo=<fqdn.org>

Similar setup, same problem..


> It sort of looks like milter-greylist has gone out to lunch and doesn't
> answer in time.  Could this happen with bad RBL servers?

Take a look at this session:

   postfix/smtpd[pid]: connect from unknown[ip]
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 450 4.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: warning: milter unix:/var/milter/mgrey.sock: can't read SMFIC_RCPT reply packet header: Connection timed out
   postfix/smtpd[pid]: NOQUEUE: milter-reject: unknown[ip]: 451 4.7.1 Service unavailable - try again later; from=<ADDR>to=<ADDR> proto=SMTP helo=<ADDR>
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[ip]: 550 5.1.1 <ADDR>: Recipient address rejected: (...)
   postfix/smtpd[pid]: too many errors after RCPT from unknown[ip]
   postfix/smtpd[pid]: disconnect from unknown[ip]


It occurs in the middle of a conversation with one single client and
since we run local caching nameservers, it's unlikely that lame RBLs
are the reason.


   Petar Bogdanovic

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.