Yahoo Groups archive
Thread
2006-10-04 by manu@netbsd.org
Here is our release candidate 4 http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc4.tgz MD5 (milter-greylist-3.0rc4.tgz) = 12b45899250614387fb0aa8c8ab23471 I don't get many feedbacks. Does that means we get close release quality? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@...
2006-10-05 by Matthias Scheler
On Wed, Oct 04, 2006 at 09:29:16PM +0200, Emmanuel Dreyfus wrote:
> Here is our release candidate 4
>
> http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc4.tgz
> MD5 (milter-greylist-3.0rc4.tgz) = 12b45899250614387fb0aa8c8ab23471
>
> I don't get many feedbacks. Does that means we get close release
> quality?
1.) The "--sysconfdir" option to the "configure" script doesn't work.
Nothing in the source tree pays attention to it although
"configure --help" mentions it.
2.) It would be nice if the documentation would explain what "DRAC"
actually is by mentioning the full wording of the acronym and
providing the link of the project page.
3.) "milter-greylist" looks for a file called "/usr/local/etc/dracdb.db"
by default. The default filename in DRAC is however "/etc/mail/dracd.db"
(different path, no "b" before the ".db").
Kind regards
--
Matthias Scheler http://zhadum.org.uk/2006-10-05 by eclark
Dunno. Waiting for the 3.0 milter to go stable so I can push it into production though. :)
On Wednesday 04 October 2006 03:29 pm, manu@... wrote: > Here is our release candidate 4 > > http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc4.tgz > MD5 (milter-greylist-3.0rc4.tgz) = 12b45899250614387fb0aa8c8ab23471 > > I don't get many feedbacks. Does that means we get close release > quality?
2006-10-05 by Emmanuel Dreyfus
On Thu, Oct 05, 2006 at 09:42:02AM -0400, eclark wrote: > Dunno. Waiting for the 3.0 milter to go stable so I can push it into > production though. :) Is it unstable at yours? -- Emmanuel Dreyfus manu@...
2006-10-05 by eclark
Dunno, I cant test 3.0, as we have no functional test environment that we can load down with as much mail as we get short of forking our traffic at the edge. We are offering it as a supported service to our clients, and they have been through some serious mail issues in the past due to poorly configured mimedefang environments and whatnot. 2.02 has eliminated almost all their issues, and has been rock solid stable. We really dont want to try putting 3.0 into production if it doesnt have the "its stable" stamp from the milter crowd. :)
On Thursday 05 October 2006 10:40 am, Emmanuel Dreyfus wrote: > On Thu, Oct 05, 2006 at 09:42:02AM -0400, eclark wrote: > > Dunno. Waiting for the 3.0 milter to go stable so I can push it into > > production though. :) > > Is it unstable at yours?
2006-10-05 by Emmanuel Dreyfus
On Thu, Oct 05, 2006 at 10:54:40AM -0400, eclark wrote: > Dunno, I cant test 3.0, as we have no functional test environment that we can > load down with as much mail as we get short of forking our traffic at the > edge. We are offering it as a supported service to our clients, and they have > been through some serious mail issues in the past due to poorly configured > mimedefang environments and whatnot. 2.02 has eliminated almost all their > issues, and has been rock solid stable. We really dont want to try putting > 3.0 into production if it doesnt have the "its stable" stamp from the milter > crowd. :) But you are the milter crowd. If nobody test the software, it cannot get stable stamp. -- Emmanuel Dreyfus manu@...
2006-10-05 by attila.bruncsak@itu.int
> Here is our release candidate 4 > > http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc4.tgz > MD5 (milter-greylist-3.0rc4.tgz) = 12b45899250614387fb0aa8c8ab23471 > > I don't get many feedbacks. Does that means we get close release > quality? Hello, The PACKAGE_VERSION did not get updated from 3.0rc3 to 3.0rc4, never mind. Otherwise it is OK to me. Bests, Attila
2006-10-05 by manu@netbsd.org
Matthias Scheler <tron@...> wrote:
> 1.) The "--sysconfdir" option to the "configure" script doesn't work.
> Nothing in the source tree pays attention to it although
> "configure --help" mentions it.
Now I attempted to fix it, I wonder if it's not on purpose. If I fix it,
then running configure with no option will drop files in /usr/local/etc
and /usr/local/var, while everyone used to have them in /etc and /var.
This would violate POLA, so I'm tempted to not fix it.
And removing --sysconfdir and --localstatedir from configure --help will
not be easy.
The best way to go is probably to default them to
SYSCONFDIR= /etc
LOCALSTATEDIR= /var
instead of
SYSCONFDIR= ${prefix}/etc
LOCALSTATEDIR= ${prefix}/var
> 2.) It would be nice if the documentation would explain what "DRAC"
> actually is by mentioning the full wording of the acronym and
> providing the link of the project page.
Any DRAC user can contribute here?
> 3.) "milter-greylist" looks for a file called "/usr/local/etc/dracdb.db"
> by default. The default filename in DRAC is however "/etc/mail/dracd.db"
> (different path, no "b" before the ".db").
That one can be fixed easily.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...2006-10-06 by Matthias Scheler
On Thu, Oct 05, 2006 at 10:34:55PM +0200, Emmanuel Dreyfus wrote: > The best way to go is probably to default them to > SYSCONFDIR= /etc > LOCALSTATEDIR= /var That sounds reasonable. > > 2.) It would be nice if the documentation would explain what "DRAC" > > actually is by mentioning the full wording of the acronym and > > providing the link of the project page. > > Any DRAC user can contribute here? I'm not a DRAC user but I googled the information yesterday: 1.) Dynamic Relay Authorization Control 2.) http://mail.cc.umanitoba.ca/drac/ Kind regards -- Matthias Scheler http://zhadum.org.uk/
2006-10-06 by Emmanuel Dreyfus
On Fri, Oct 06, 2006 at 09:44:15AM +0100, Matthias Scheler wrote: > On Thu, Oct 05, 2006 at 10:34:55PM +0200, Emmanuel Dreyfus wrote: > > The best way to go is probably to default them to > > SYSCONFDIR= /etc > > LOCALSTATEDIR= /var > That sounds reasonable. Unfortunately there does not seems to be an easy way of doing that with autoconf: there is a PREFIX_DEFAULT macro, but not a SYSCONFDIR_DEFAULT. Any idea, anyone? -- Emmanuel Dreyfus manu@...
2006-10-08 by Mart Pirita
Tere. Is it possibe to make rules based receiver domain? I have a lot domains in mailserver, and only few of them are under heavy spam attack, while other domains are quite ok. Now I'd like to use strict rules based domains, for example something like this: acl greylist baddomain.com delay 3h code "451" ecode "4.7.1" msg "greylisted" acl timeout baddomain.com 1h acl autowhite baddomain.com 3h acl greylist gooddomain.com delay 15m code "451" ecode "4.7.1" msg "greylisted" acl timeout gooddomain.com 12h acl autowhite gooddomain.com 12h Is this possible? -- Mart
2006-10-08 by manu@netbsd.org
Mart Pirita <sysadmin@...> wrote: > Is it possibe to make rules based receiver domain? I have a lot domains > in mailserver, and only few of them are under heavy spam attack, while > other domains are quite ok. Now I'd like to use strict rules based > domains, for example something like this: Use regexps: acl greylist rcpt /@baddomain\.com$/ delay 3h autowhite 3h acl greylist rcpt /@gooddomain\.com$/ delay 15m autowhite 12h The timeout cannot be set on a per-ACL basis. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@...
2006-10-09 by Mart Pirita
Tere. > > Use regexps: > > acl greylist rcpt /@baddomain\.com$/ delay 3h autowhite 3h > acl greylist rcpt /@gooddomain\.com$/ delay 15m autowhite 12h > Great. But what about the custom error code and message? Now the default acl is after these two rules: acl greylist default delay 30m code "451" ecode "4.7.1" msg "greylisted" Does it mean, that also these regexps acl will use these codes or not? Or should I just use: acl greylist default code "451" ecode "4.7.1" msg "greylisted" acl greylist default delay 15m Or: acl greylist default code "451" ecode "4.7.1" msg "greylisted" greylist 15m > The timeout cannot be set on a per-ACL basis. > > Ok. -- Mart
2006-10-09 by Emmanuel Dreyfus
On Mon, Oct 09, 2006 at 11:24:48AM +0300, Mart Pirita wrote: > > acl greylist rcpt /@baddomain\.com$/ delay 3h autowhite 3h > > acl greylist rcpt /@gooddomain\.com$/ delay 15m autowhite 12h > Great. But what about the custom error code and message? Now the > default acl is after these two rules: Add them at the end of the lines. > Or should I just use: > acl greylist default code "451" ecode "4.7.1" msg "greylisted" > acl greylist default delay 15m If you do that, the irst default acl match anything and the second will never be tested. -- Emmanuel Dreyfus manu@...
2007-01-05 by Mart Pirita
Tere. In some old messages I asked: >>> acl greylist rcpt /@baddomain\.com$/ delay 3h autowhite 3h >>> acl greylist rcpt /@gooddomain\.com$/ delay 15m autowhite 12h >>> >> Great. But what about the custom error code and message? Now the >> default acl is after these two rules: >> > > And Emmanuel sugested: > Add them at the end of the lines. > > Well, just tested it, previously I had 1 rule: acl greylist default delay 30m code "451" ecode "4.7.1" msg "greylisted" and logs shows: sendmail[3081]: kBO23mVp003081: Milter: to=<user@domain>, reject=451 4.7.1 greylisted But disabled previous rule and aaded 3 new rules: greylist rcpt /@1domain\.ee$/ delay 60m autowhite 12h code "451" ecode "4.7.1" msg "greylisted" greylist rcpt /@2domain\.ee$/ delay 15m autowhite 48h code "451" ecode "4.7.1" msg "greylisted" greylist rcpt /@3domain\.ee$/ delay 15m autowhite 48h code "451" ecode "4.7.1" msg "greylisted" seems that msg "greylisted" is bypassed with the hard coded message, as logs shows: sendmail[12330]: l059W72T012330: Milter: to=<user@domain>, reject=451 4.7.1 Greylisting in action, please come back later What did I wrong? Or is it bug? -- Mart
2007-01-05 by Emmanuel Dreyfus
On Fri, Jan 05, 2007 at 11:43:25AM +0200, Mart Pirita wrote: > seems that msg "greylisted" is bypassed with the hard coded message, as > logs shows: > sendmail[12330]: l059W72T012330: Milter: to=<user@domain>, reject=451 > 4.7.1 Greylisting in action, please come back later > > What did I wrong? Or is it bug? It may be a bug, but are you sure of the matching ACL? Check the logs, it should tell you the ACL number that caused the match (feature introduced at 2.1.7) -- Emmanuel Dreyfus manu@...
2007-01-05 by Mart Pirita
Tere. > > It may be a bug, but are you sure of the matching ACL? Check the logs, it > should tell you the ACL number that caused the match (feature introduced > at 2.1.7) > > Hmm, more strange things, I'm using the 3.0 version and with previous rules, logs shows: Dec 31 04:07:52 tibu milter-greylist: kBV27qew024521: addr [24.151.43.113][24.151.43.113] from <ujah@...> to <user@...> delayed for 00:30:00 (ACL 102) Dec 31 04:07:52 tibu sendmail[24521]: kBV27qew024521: Milter: to=<user@...>, reject=451 4.7.1 greylisted Put with the new rules, there no acl specific info in the logs anymore: Jan 5 10:59:31 tibu milter-greylist: l058xL3m012053: addr [59.92.71.26][59.92.71.26] from <gybcye@...> to <user@...> delayed for 00:30:00 Jan 5 10:59:31 tibu sendmail[12053]: l058xL3m012053: Milter: to=<user@...>, reject=451 4.7.1 Greylisting in action, please come back later -- Mart
2007-01-06 by manu@netbsd.org
Mart Pirita <sysadmin@...> wrote: > Jan 5 10:59:31 tibu milter-greylist: l058xL3m012053: addr > [59.92.71.26][59.92.71.26] from <gybcye@...> > to <user@...> delayed for 00:30:00 Looks like a bug. Can you give a try to 3.1.3 (I hope you won't hit an even more critical bug :-) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@...
2007-01-08 by Mart Pirita
Tere. > > Looks like a bug. Can you give a try to 3.1.3 (I hope you won't hit an > even more critical bug :-) > > So, tested it, same problems, no ACL stuff in logs and hardcoded message code is used: Jan 8 10:10:15 tibu milter-greylist: l088AEX1029971: addr 167.Red-80-36-64.staticIP.rima-tde.net[80.36.64.167] from <kxvhw@...> to <user@...> delayed for 00:30:00 Jan 8 10:10:15 tibu sendmail[29971]: l088AEX1029971: Milter: to=<user@...>, reject=451 4.7.1 Greylisting in action, please come back later -- Mart
2007-01-08 by manu@netbsd.org
Mart Pirita <sysadmin@...> wrote:
> So, tested it, same problems, no ACL stuff in logs and hardcoded message
> code is used:
Please try adding two printfs in acl.c:acl_filter(). What do you get?
Index: acl.c
===================================================================
RCS file: /cvsroot/milter-greylist/acl.c,v
retrieving revision 1.44
diff -U2 -r1.44 acl.c
--- acl.c 4 Jan 2007 23:01:46 -0000 1.44
+++ acl.c 8 Jan 2007 14:39:40 -0000
@@ -1133,8 +1133,9 @@
+ printf("try ACL %d\n", acl->a_line);
LIST_FOREACH(ac, &acl->a_clause, ac_list) {
if ((found = (*ac->ac_acr->acr_filter)
(&ac->ac_data, stage, &ap,
priv)) == 0)
break;
+ printf(" found 0x%x\n", found);
retval |= found;
}
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...2007-01-09 by Mart Pirita
Tere.
>
>
> Please try adding two printfs in acl.c:acl_filter(). What do you get?
>
> Index: acl.c
> ===================================================================
> RCS file: /cvsroot/milter-greylist/acl.c,v
> retrieving revision 1.44
> diff -U2 -r1.44 acl.c
> --- acl.c 4 Jan 2007 23:01:46 -0000 1.44
> +++ acl.c 8 Jan 2007 14:39:40 -0000
> @@ -1133,8 +1133,9 @@
>
> + printf("try ACL %d\n", acl->a_line);
> LIST_FOREACH(ac, &acl->a_clause, ac_list) {
> if ((found = (*ac->ac_acr->acr_filter)
> (&ac->ac_data, stage, &ap,
> priv)) == 0)
> break;
>
> + printf(" found 0x%x\n", found);
> retval |= found;
> }
>
Did, same situation:
Jan 9 16:30:16 tibu milter-greylist: l09EUGdo002346: addr
bay0-omc2-s36.bay0.hotmail.com[65.54.246.172] from
<roosaporsas@...> to <user@...> delayed for 00:30:00
Jan 9 16:30:16 tibu sendmail[2346]: l09EUGdo002346: Milter:
to=<user@...>, reject=451 4.7.1 Greylisting in action, please come
back later
--
Mart2007-01-09 by Emmanuel Dreyfus
On Tue, Jan 09, 2007 at 04:29:42PM +0200, Mart Pirita wrote: > Did, same situation: Silly me, you run as a deamon, so printf does nothing. Turn printf( into mg_log(LOG_ERR, -- Emmanuel Dreyfus manu@...
2007-01-09 by Mart Pirita
Tere. > > Silly me, you run as a deamon, so printf does nothing. > > Turn printf( into mg_log(LOG_ERR, > Ee, where to turn it? -- Mart
2007-01-09 by Nerijus Baliunas
On Tue, 09 Jan 2007 22:37:30 +0200 Mart Pirita <sysadmin@...> wrote: > > Silly me, you run as a deamon, so printf does nothing. > > > > Turn printf( into mg_log(LOG_ERR, > > Ee, where to turn it? He meant to change printf(...) to mg_log(LOG_ERR, ...). Regards, Nerijus
2007-01-29 by Mart Pirita
Tere. > > > He meant to change printf(...) to mg_log(LOG_ERR, ...). > > Hmm, I didn't that, hoping that it is in the latest 3.1.4 fixed, but seems not :(. -- Mart
2007-01-29 by Emmanuel Dreyfus
On Mon, Jan 29, 2007 at 10:26:27AM +0200, Mart Pirita wrote: > > He meant to change printf(...) to mg_log(LOG_ERR, ...). > Hmm, I didn't that, hoping that it is in the latest 3.1.4 fixed, but > seems not :(. Well, if you don't help debugging the problems that happens at yours but not at mine, who will? :-) -- Emmanuel Dreyfus manu@...
2007-01-29 by Mart Pirita
Tere. > > Well, if you don't help debugging the problems that happens at yours > but not at mine, who will? :-) > > Heh, ok, I'll try to debug it asap. -- Mart
2007-01-30 by Mart Pirita
Tere.
>
> He meant to change printf(...) to mg_log(LOG_ERR, ...).
>
>
Hmm, sorry again, the first suggestion was:
Index: acl.c
===================================================================
RCS file: /cvsroot/milter-greylist/acl.c,v
retrieving revision 1.44
diff -U2 -r1.44 acl.c
--- acl.c 4 Jan 2007 23:01:46 -0000 1.44
+++ acl.c 8 Jan 2007 14:39:40 -0000
@@ -1133,8 +1133,9 @@
+ printf("try ACL %d\n", acl->a_line);
LIST_FOREACH(ac, &acl->a_clause, ac_list) {
if ((found = (*ac->ac_acr->acr_filter)
(&ac->ac_data, stage, &ap,
priv)) == 0)
break;
+ printf(" found 0x%x\n", found);
retval |= found;
}
Now, which printf(...) I should change? The first ot both? And what is
the exact syntax (I'm not coder:( )?
--
Mart2007-01-30 by Nerijus Baliunas
On Tue, 30 Jan 2007 10:49:02 +0200 Mart Pirita <sysadmin@...> wrote:
> > He meant to change printf(...) to mg_log(LOG_ERR, ...).
> >
> >
> Hmm, sorry again, the first suggestion was:
>
> Index: acl.c
> ===================================================================
> RCS file: /cvsroot/milter-greylist/acl.c,v
> retrieving revision 1.44
> diff -U2 -r1.44 acl.c
> --- acl.c 4 Jan 2007 23:01:46 -0000 1.44
> +++ acl.c 8 Jan 2007 14:39:40 -0000
> @@ -1133,8 +1133,9 @@
>
> + printf("try ACL %d\n", acl->a_line);
> LIST_FOREACH(ac, &acl->a_clause, ac_list) {
> if ((found = (*ac->ac_acr->acr_filter)
> (&ac->ac_data, stage, &ap,
> priv)) == 0)
> break;
>
> + printf(" found 0x%x\n", found);
> retval |= found;
> }
>
>
>
> Now, which printf(...) I should change? The first ot both? And what is
> the exact syntax (I'm not coder:( )?
Both, and as I said change printf(...) to mg_log(LOG_ERR, ...). I.e. instead of
+ printf("try ACL %d\n", acl->a_line);
+ printf(" found 0x%x\n", found);
add these lines as:
+ mg_log(LOG_ERR, "try ACL %d\n", acl->a_line);
+ mg_log(LOG_ERR, " found 0x%x\n", found);
Regards,
Nerijus2007-01-30 by Mart Pirita
Tere.
>
> Both, and as I said change printf(...) to mg_log(LOG_ERR, ...). I.e. instead of
> + printf("try ACL %d\n", acl->a_line);
> + printf(" found 0x%x\n", found);
> add these lines as:
> + mg_log(LOG_ERR, "try ACL %d\n", acl->a_line);
> + mg_log(LOG_ERR, " found 0x%x\n", found);
>
>
Thank You. The results are:
Jan 30 14:13:22 tibu milter-greylist: try ACL 35
Jan 30 14:13:22 tibu milter-greylist: try ACL 47
Jan 30 14:13:22 tibu milter-greylist: try ACL 48
Jan 30 14:13:22 tibu milter-greylist: try ACL 72
Jan 30 14:13:22 tibu milter-greylist: try ACL 73
Jan 30 14:13:22 tibu milter-greylist: try ACL 74
Jan 30 14:13:22 tibu milter-greylist: l0UCDLVd028521: addr
an-out-0708.google.com[209.85.132.240] from <user@...> to
<user@...> delayed for 00:30:00
Jan 30 14:13:22 tibu sendmail[28521]: l0UCDLVd028521: Milter:
to=<user@domain1>, reject=451 4.7.1 Greylisting in action, please come
back later
Jan 30 14:13:22 tibu sendmail[28521]: l0UCDLVd028521:
from=<user@...>, size=0, class=0, nrcpts=0, proto=ESMTP,
daemon=MTA, relay=an-out-0708.google.com [209.85.132.240]
And from conf:
line 72 - acl greylist rcpt /@domain1\.ee$/ delay 60m autowhite 12h
code "451" ecode "4.7.1" msg "greylisted"
line 73 - acl greylist rcpt /@domain2\.ee$/ delay 15m autowhite 48h code
"451" ecode "4.7.1" msg "greylisted"
line 74 - acl greylist rcpt /domain3\.ee$/ delay 15m autowhite 48h code
"451" ecode "4.7.1" msg "greylisted"
Any hint why these rules are bypassed?
--
Mart2007-01-30 by manu@netbsd.org
Mart Pirita <sysadmin@...> wrote: > line 72 - acl greylist rcpt /@domain1\.ee$/ delay 60m autowhite 12h > code "451" ecode "4.7.1" msg "greylisted" Um... Try /@domain1\.ee/ just to see if it changes anything. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@...
2007-02-01 by Mart Pirita
Tere. > > > Um... Try /@domain1\.ee/ just to see if it changes anything. > > Well, running nonpatched latest greylist, using rule 76: acl greylist rcpt /@domain1\.ee/ delay 60m autowhite 12h code "451" ecode "4.7.1" msg "greylisted" Gives in logs: Feb 1 12:42:07 tibu milter-greylist: l11Ag5h9007190: addr [59.94.208.220][59.94.208.220] from <theron226@...> to <user@...> delayed for 01:00:00 (ACL 76) Feb 1 12:42:07 tibu sendmail[7190]: l11Ag5h9007190: Milter: to=<user@...>, reject=451 4.7.1 greylisted So seems everything (can't test the autowhite part yet) works now? -- Mart