Yahoo Groups archive

Milter-greylist

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

Thread

whitelist/timed whitelist

whitelist/timed whitelist

2004-12-13 by Ivan F. Martinez

I started to test an extra feature for greylist.
Timed whitelist, to be used when testing with new users/domains, or with
that don't like the delay introduced by greylist.

During the day the messages enter without passing greylist, and at night
it passes on greylist.

I have made an .m4 file which I use in my rpm file to configure
milter-greylist, this m4 file now also has the rules to check for
whitelisted entries on access.d, and permit also to specify whitelist
with time.

The format are like :

greylist:1.2.3.4 WHITE
greylist:1.2.3.5 WHITE:0700:1800
greylist:domain.com WHITE:0700:1800

To use this feature a patch must be applied to check for variable
{greylist} defined in sendmail rules.
The files need to test this feature are :


http://www.saisp.br/ifm/patches/milter-greylist.c.patch
http://www.saisp.br/ifm/patches/milter-greylist.m4

I appreciate any feedback about this feature.

Re: [milter-greylist] whitelist/timed whitelist

2004-12-13 by manu@netbsd.org

Ivan F. Martinez <ml@...> wrote:

> greylist:1.2.3.4 WHITE
> greylist:1.2.3.5 WHITE:0700:1800
> greylist:domain.com WHITE:0700:1800
> 
> To use this feature a patch must be applied to check for variable
> {greylist} defined in sendmail rules.
> The files need to test this feature are :
> 
> 
> http://www.saisp.br/ifm/patches/milter-greylist.c.patch
> http://www.saisp.br/ifm/patches/milter-greylist.m4

All this sendmail.cf stuff is so scaring :)
 
> I appreciate any feedback about this feature.

Argh, nobody sent feedback about the previous one!

Some questions to be answered by users and contributors, so that we get
an idea of what we are about to integrate and how:

1) Do we want to use sendmail access DB as a greylist/whitelist source?
2) If we do, do we need the config file to support all the features the
sendmail access DB has?
3) Do we want to merge all whitelisting methods into the new ACL
mecanism? Example: being able to tell that SPF whitelisting will work
for user foo but not for user bar, or that sendmail DB whitelisting will
not apply to /.*@sub\.domain\.net/
 
-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Re: [milter-greylist] whitelist/timed whitelist

2004-12-13 by manu@netbsd.org

Emmanuel Dreyfus <manu@...> wrote:

> Some questions to be answered by users and contributors, so that we get
> an idea of what we are about to integrate and how:

And here are my own anwsers:
 
> 1) Do we want to use sendmail access DB as a greylist/whitelist source?

Why not, a new feature that cannot harm. But I think there should be a
noaccessdb configuration option to switch it off, like we have for SPF
and SMTP auth.

> 2) If we do, do we need the config file to support all the features the
> sendmail access DB has?

It seems that the sendmail DB will allow very flexible things, and it
will be hard to support all of them in milter-greylist config file, so
that should probably not be a goal. 

> 3) Do we want to merge all whitelisting methods into the new ACL
> mecanism? Example: being able to tell that SPF whitelisting will work
> for user foo but not for user bar, or that sendmail DB whitelisting will
> not apply to /.*@sub\.domain\.net/

That seems highly desirable, but it seems to me that we can do that
later: no need to delay the access DB support for that. 

Comments? 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Re: [milter-greylist] whitelist/timed whitelist

2004-12-13 by Ivan F. Martinez

On Mon, 13 Dec 2004 21:34:24 +0100
manu@... wrote:

MO> 
MO> Emmanuel Dreyfus <manu@...> wrote:
MO> 
MO> > Some questions to be answered by users and contributors, so that
MO> > we get an idea of what we are about to integrate and how:
MO> 
MO> And here are my own anwsers:
MO>  
MO> > 1) Do we want to use sendmail access DB as a greylist/whitelist
MO> > source?
MO> 
MO> Why not, a new feature that cannot harm. But I think there should be
MO> a noaccessdb configuration option to switch it off, like we have for
MO> SPF and SMTP auth.

The option for receiving flags from sendmail, permit many types of
integration, an small system can use it, and large system with custom
things too.
We have here a lot of custom permissions in sendmail rules :
  Blocks by HELO String
  Blocks by failed reverse DNS
  Per user Blocks.
  
And easily we can extend to pass information to the milter. The m4 file
that I made has rules, that probably will be used only during tests, for
production the rules will be inside our current rules.

MO> 
MO> > 2) If we do, do we need the config file to support all the
MO> > features the sendmail access DB has?
MO> 
MO> It seems that the sendmail DB will allow very flexible things, and
MO> it will be hard to support all of them in milter-greylist config
MO> file, so that should probably not be a goal. 

My current patch is small and permit each person to integration with
local systems, and then we have more time to think about things that we
can implement inside milter.

MO> 
MO> > 3) Do we want to merge all whitelisting methods into the new ACL
MO> > mecanism? Example: being able to tell that SPF whitelisting will
MO> > work for user foo but not for user bar, or that sendmail DB
MO> > whitelisting will not apply to /.*@sub\.domain\.net/
MO> 
MO> That seems highly desirable, but it seems to me that we can do that
MO> later: no need to delay the access DB support for that. 

I have not tested the ACL system, 
I'm trying to put the milter in production (without problems for the
users) before checking this.
And in our system the option to use the {greylist} variable to define
the white systems/users can make the migration easy.

In near to 5 days running I have a big reduction of viruses detected by
our AntiVirus system, because the virus don't retry to send the
messages. This is a big prove of advantages of milter-greylist.
And using the access I can also use a 100000 IPs whitelist that I got
from a friend ISP.




--

Re: [milter-greylist] whitelist/timed whitelist

2004-12-14 by Dan Hollis

On Mon, 13 Dec 2004 manu@... wrote:
> 1) Do we want to use sendmail access DB as a greylist/whitelist source?

Yes, because large ISP has potential ENORMOUS list of ip+address+datetime 
pairs. Imagine ISP with 50k+ users and tens of millions of hosts sending 
it mail. (eg typical large university)

Already we are seeing greylist daemon size of 300mb+ on our mailserver. 
And we're a relatively small isp.

DB needs to be moved outside of the daemon. Keeping everything resident 
is unusable for huge mailservers.

-DAn

Re: [milter-greylist] whitelist/timed whitelist

2004-12-14 by Joseph Burford

Dan,

> Yes, because large ISP has potential ENORMOUS list of ip+address+datetime 
> pairs. Imagine ISP with 50k+ users and tens of millions of hosts sending 
> it mail. (eg typical large university)

I have found it easy enough to keep the size of the database down by 
using a local whitelist of companies and mailservers that I trust. That 
way the entries never get listed in the database.

Personally I have found greylisting to be the most effective against 
dynamic hosts, it stops spam and virus spew.

However greylisting is not effective against ISPs or organisations with 
large mail server clusters.

You also might like to try the LAZYAW option, and -L 24 to keep the DB 
size down.

Anyone wishing to share a local whitelist please let me know, mine is 
mainly AU organisations and ISPs :-)

Regards,

Joseph

Re: [milter-greylist] whitelist/timed whitelist

2004-12-16 by manu@netbsd.org

Ivan F. Martinez <ml@...> wrote:

> I have made an .m4 file which I use in my rpm file to configure
> milter-greylist, this m4 file now also has the rules to check for
> whitelisted entries on access.d, and permit also to specify whitelist
> with time.
> 
> The format are like :
> 
> greylist:1.2.3.4 WHITE
> greylist:1.2.3.5 WHITE:0700:1800
> greylist:domain.com WHITE:0700:1800
> 
> http://www.saisp.br/ifm/patches/milter-greylist.c.patch
> http://www.saisp.br/ifm/patches/milter-greylist.m4
> 
> I appreciate any feedback about this feature.

I integrated the patch to milter-greylist.c (and added a config file
option to disable it, and added documentation in README and
greylist.conf.5). But I'm not sure the m4 file is something that really
has to go in the distribution.

Could you write an HTML page documenting your feature and including the
m4 file? Just like Helmut did for the poprelay stuff at
http://hcpnet.free.fr/milter-greylist/poprelay ? I'll add your page to
the website.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Re: [milter-greylist] whitelist/timed whitelist

2004-12-16 by Ivan F. Martinez

On Fri, 17 Dec 2004 00:20:08 +0100
manu@... wrote:

MO> 
MO> Ivan F. Martinez <ml@...> wrote:
MO> 
MO> > I have made an .m4 file which I use in my rpm file to configure
MO> > milter-greylist, this m4 file now also has the rules to check for
MO> > whitelisted entries on access.d, and permit also to specify
whitelist
MO> > with time.
MO> > 
MO> > The format are like :
MO> > 
MO> > greylist:1.2.3.4 WHITE
MO> > greylist:1.2.3.5 WHITE:0700:1800
MO> > greylist:domain.com WHITE:0700:1800
MO> > 
MO> > http://www.saisp.br/ifm/patches/milter-greylist.c.patch
MO> > http://www.saisp.br/ifm/patches/milter-greylist.m4
MO> > 
MO> > I appreciate any feedback about this feature.
MO> 
MO> I integrated the patch to milter-greylist.c (and added a config file
MO> option to disable it, and added documentation in README and
MO> greylist.conf.5). But I'm not sure the m4 file is something that
really
MO> has to go in the distribution.
MO> 
MO> Could you write an HTML page documenting your feature and including
the
MO> m4 file? Just like Helmut did for the poprelay stuff at
MO> http://hcpnet.free.fr/milter-greylist/poprelay ? I'll add your page
to
MO> the website.

I split the .m4 in 2 files the milter-greylist.m4 and
milter-greylist-rules.m4
anyone can use the milter-greylist.m4, because it can enable the milter
and add needed variables without changing other varables used in the
system.
And I can write some kind of html doc for the milter-greylist-rules.m4.



--

Re: [milter-greylist] whitelist/timed whitelist

2004-12-17 by manu@netbsd.org

Ivan F. Martinez <ml@...> wrote:

> I split the .m4 in 2 files the milter-greylist.m4 and
> milter-greylist-rules.m4
> anyone can use the milter-greylist.m4, because it can enable the milter
> and add needed variables without changing other varables used in the
> system.
>
> And I can write some kind of html doc for the milter-greylist-rules.m4.

Fine. I'll include milter-greylist.m4 and milter-greylist.spec in the
distribution, and we'll have the "advanced sendmail.cf hacks" available
on the web.


-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Re: [milter-greylist] whitelist/timed whitelist

2004-12-17 by Ivan F. Martinez

On Fri, 17 Dec 2004 12:52:06 +0100
manu@... wrote:

MO> 
MO> Ivan F. Martinez <ml@...> wrote:
MO> 
MO> > I split the .m4 in 2 files the milter-greylist.m4 and
MO> > milter-greylist-rules.m4
MO> > anyone can use the milter-greylist.m4, because it can enable the milter
MO> > and add needed variables without changing other varables used in the
MO> > system.
MO> >
MO> > And I can write some kind of html doc for the milter-greylist-rules.m4.
MO> 
MO> Fine. I'll include milter-greylist.m4 and milter-greylist.spec in the
MO> distribution, and we'll have the "advanced sendmail.cf hacks" available
MO> on the web.
MO> 

Nice, but I have to remove my patches before including spec in distribution.
Can you send to me the tar before releasing a new version, then I can adjust the spec to be incorporated in the distribution using only the files included in the tar.gz.



-- 
Ivan F. Martinez

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.