Yahoo Groups archive

Milter-greylist

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

Messages

Browse messages

Page 132 of 144 · 7199 messages matched

milter-greylist-1.5.11 released

2004-11-02 by manu@netbsd.org

I released milter-greylist-1.5.11 ftp://ftp.espci.fr/pub/milter-greylist/milter-greylist-1.5.11.tgz MD5 (milter-greylist-1.5.11.tgz) =

Thread view Attachments: 0

milter-rcptfilter-0.11 released

2004-11-02 by manu@netbsd.org

Hi milter-rcptfilter-0.11 fixes a build problem on platforms that didn t have strlcpy. ftp://ftp.espci.fr/pub/milter-rctpfilter/milter-rcptfilter-0.11.tgz SHA1

Thread view Attachments: 0

1.4 with subnetmatch and addr

2004-11-02 by Brent J. Nordquist

Just wondering if there are any known bugs with milter-greylist 1.4 using the subnetmatch and attr greylist.conf keywords? I have tried subnetmatch /24

Thread view Attachments: 0

Re: [milter-greylist] Volume 2

2004-11-01 by Matthias Scheler

... No, that won t work. After fork() you are only allowed to use Async-Signal-Safe function until you have used exec(). And fdopen() and many of the other

Thread view Attachments: 0

Re: [milter-greylist] Volume 2

2004-10-29 by Emmanuel Dreyfus

... On a system that doesn t fork using COW, that will cause a major memory copy. Otherwise it could be a good workaround. -- Emmanuel Dreyfus manu@netbsd.org

Thread view Attachments: 0

RE: [milter-greylist] Volume 2

2004-10-29 by Sutherland, James

Another option would be to spawn a child process to write the db dump. Since each pid is limited. ________________________________ From: Emmanuel Dreyfus

Thread view Attachments: 0

Re: [milter-greylist] Volume 2

2004-10-29 by Emmanuel Dreyfus

... Okay... I guess we could book a low file descriptor for dumping the database. Something stored in a static. The problem is that we ll need to do the same

Thread view Attachments: 0

RE: [milter-greylist] Volume 2

2004-10-28 by Sutherland, James

Looks pretty much the same on this latest failure. handles open spikes and milter can t write it s dump so it exits. Oct 28 12:59:07 hns1 milter-greylist: [ID

Thread view Attachments: 0

RE: [milter-greylist] Volume 2

2004-10-28 by Sutherland, James

This is an interesting article I found on sunhelp about somebody else having the same issue: http://www.sunhelp.org/pipermail/sunhelp/2002-January/015005.html

Thread view Attachments: 0

Re: [milter-greylist] Volume 2

2004-10-28 by Matthias Scheler

... I couldn t open that file because you a passed file number larger than 255. From Solaris s stdio(3C) manual page: The integer constant FOPEN_MAX specifies

Thread view Attachments: 0

RE: [milter-greylist] Volume 2

2004-10-28 by attila.bruncsak@itu.int

Hello, Tru64 UNIX man atexit writes among others: It is not recommended to call exit() from within an atexit handler. I wonder that exit() was called for

Thread view Attachments: 0

RE: [milter-greylist] Volume 2

2004-10-28 by Sutherland, James

Geez, I can t keep milter-greylist running for more then ten minutes this morning. It starts into the Milter read(greylist): timeout before data read almost

Thread view Attachments: 0

Re: [milter-greylist] Volume 2

2004-10-28 by manu@netbsd.org

... Here is the code that causes this failure: if ((dump = fdopen(dumpfd, w )) == NULL) { syslog(LOG_ERR, cannot write dumpfile %s : %s , newdumpfile,

Thread view Attachments: 0

Volume 2

2004-10-28 by Sutherland, James

Well I m back at it again with that HUGE mx. I had to drop this issue for a while to work on some other stuff but now I m back to it. Sorry for the delay.

Thread view Attachments: 0

Re: [milter-greylist] domain exceptions

2004-10-25 by manu@netbsd.org

... Well, it seems you have a plan. Do you want to implement it? It shouldn t be very difficult, and it s true it would help for domains that don t have SPF

Thread view Attachments: 0

domain exceptions

2004-10-25 by Gary Aitken

Hello all, I just noticed the 31 byte limit / truncation problem with domain names has been fixed, great! There is another problem, as I see it, with domain

Thread view Attachments: 0

Re: [milter-greylist] This is awesome

2004-10-23 by Scot L. Harris

... I setup a system using 2 minutes and it has worked very well. From what I have seen most legit systems retry at least once within 5 minutes. Most spam

Thread view Attachments: 0

Re: [milter-greylist] This is awesome

2004-10-22 by Garry Davies

... Thanks Graham I actually figured it out and they are all working fine! BTW what sort of delays are generally in use? I have been using 5m and most of the

Thread view Attachments: 0

Re: [milter-greylist] This is awesome

2004-10-22 by Graham Dunn

Garry Davies wrote: [snip] ... Today s your lucky day: from the greylist.conf file # peer entries to enable greylist sync among the MX #peer 192.0.2.17 #peer

Thread view Attachments: 0

This is awesome

2004-10-22 by Garry Davies

I just added milter-greylist to one of our servers that takes several thousand hits per day from Spammers. Overnight my personal mailbox which can generally

Thread view Attachments: 0

Whitelisting not working?

2004-10-20 by Thomas Cameron

Howdy - I am running milter-greylist-1.4-0 on a Fedora Core 2 box, Intel architecture. I have the following entries in /etc/mail/greylist.conf: from

Thread view Attachments: 0

Re: [milter-greylist] peer patch

2004-10-19 by Klas Heggemann

... Well actually no. I did not se the lines, since they were not adjacent. Perhaps I got the wrong patch when doing cutandpaste. Perhaps Emmanuel could make

Thread view Attachments: 0

pattern for regex and comment

2004-10-17 by Hajimu UMEMOTO

Hi, A friend of mine found a problem. The following line causes parser error: addr 192.168.0.0/24 # http://localhost/ It seems that `addr 192.168.0.0 is

Thread view Attachments: 0

Re: [milter-greylist] Digest Number 82

2004-10-16 by klas@nada.kth.se

About statistics ... This is now # Summary: 391142 records, 299124 greylisted, 92018 whitelisted ... Now 61M. ... This is Solaris 9 on sparc. greylist.db is

Thread view Attachments: 0

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.