Milter-greylist

Hi

I branched the new stable branch and released version 1.4, it's just
1.3.9 with the version number changed. 

Now I'll integrate various pending patches in a 1.5.1 version. 
 
-- 
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@...

On Sat, 12 Jun 2004 manu@... wrote:
> Now I'll integrate various pending patches in a 1.5.1 version. 

My sender+recipient patch maybe?

-Dan

Dan Hollis <goemon@...> wrote:

> > Now I'll integrate various pending patches in a 1.5.1 version.  
> My sender+recipient patch maybe?

Yes, this one is in the queue. What does it fix? Is it just to get a
per-recipient whitelist?

-- 
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@...

On Sat, 12 Jun 2004 manu@... wrote:
> Dan Hollis <goemon@...> wrote:
> > > Now I'll integrate various pending patches in a 1.5.1 version.  
> > My sender+recipient patch maybe?
> Yes, this one is in the queue. What does it fix? Is it just to get a
> per-recipient whitelist?

Yes, basically. Individual users can have their own whitelists independent 
of everyone else.

-Dan

Dan Hollis <goemon@...> wrote:

> Yes, basically. Individual users can have their own whitelists independent
> of everyone else.

Are you sure it's a good idea to promote whitelist based on the sender
address? Those can be easily forged, and they are actually forged a lot
nowadays.

Anyway, I was thinking about a more general feature: a per-recipient
exception list, where we could add any configuration option we currently
use.

Example:
rcpt john.doe@... {
        addr 192.0.2.0/24
        from friend@...
        report none
}

The only problem I have with that is that it only makes sense in test
mode. 
-- 
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@...

On Sat, 12 Jun 2004 manu@... wrote:
> Dan Hollis <goemon@...> wrote:
> > Yes, basically. Individual users can have their own whitelists independent
> > of everyone else.
> Are you sure it's a good idea to promote whitelist based on the sender
> address? Those can be easily forged, and they are actually forged a lot
> nowadays.

For an ISP with 10's of thousands of users, it's impossible to train even 
a significant portion of them to read headers and make whitelisting based 
on IP address. They barely know how to operate outlook express. They do 
understand at least email addresses, and how to use a webpage we provide 
them to configure their spamfilter settings.

Also, spammers don't generally know an individual user's white list.

Viruses get eaten by our virus filters.

This functionality is for ISP use, not individual experienced unix users.

-Dan

Dan Hollis <goemon@...> wrote:

> This functionality is for ISP use, not individual experienced unix users.

Sure, but we can try to make milter-greylist satisfying to both kind of
users.

-- 
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@...

On Sat, 12 Jun 2004 manu@... wrote:
> Example:
> rcpt john.doe@... {
>         addr 192.0.2.0/24
>         from friend@...
>         report none
> }

What about specific addr+from combinations? Eg only a specific addr block 
for a specific from.

I guess you'd need multiple rcpt {} blocks for that. Unless you allowed 
nesting:

rcpt john.doe@... {
	addr 192.0.2.0/24 {
		from friend@...
	}
	addr 10.0.0.1/8 {
		from otherfriend@...
	}
	report none
}

But this could get ugly.

-Dan

Dan Hollis <goemon@...> wrote:

> I guess you'd need multiple rcpt {} blocks for that. Unless you allowed
> nesting:
> 
> rcpt john.doe@... {
>       addr 192.0.2.0/24 {
>               from friend@...
>       }
>       addr 10.0.0.1/8 {
>               from otherfriend@...
>       }
>       report none
> }
> 
> But this could get ugly.

could? Is there something that makes you feel you have wrote something
that is not ugly? ;)

Seriously speaking, the nested stuff will be complicated to implement
and complicated to understand, I'm not sure it's a good idea.

-- 
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@...

On Sat, 12 Jun 2004 manu@... wrote:
> Dan Hollis <goemon@...> wrote:
> > I guess you'd need multiple rcpt {} blocks for that. Unless you allowed
> > nesting:
> > 
> > rcpt john.doe@... {
> >       addr 192.0.2.0/24 {
> >               from friend@...
> >       }
> >       addr 10.0.0.1/8 {
> >               from otherfriend@...
> >       }
> >       report none
> > }
> > 
> > But this could get ugly.
> could? Is there something that makes you feel you have wrote something
> that is not ugly? ;)
> Seriously speaking, the nested stuff will be complicated to implement
> and complicated to understand, I'm not sure it's a good idea.

The alternative is this, which I think is ugly too:

rcpt john.doe@... {
      addr 192.0.2.0/24
      from friend@...
      report none
}

rcpt john.doe@... {
      addr 10.0.0.1/8 {
      from otherfriend@...
      report none
}

-Dan

Dan Hollis <goemon@...> wrote:

> The alternative is this, which I think is ugly too:
> 
> rcpt john.doe@... {
>       addr 192.0.2.0/24
>       from friend@...
>       report none
> }
> 
> rcpt john.doe@... {
>       addr 10.0.0.1/8 {
>       from otherfriend@...
>       report none
> }

Sure, but here you reproduce the "recipient (AND condition)*" feature
without the nested feature. I was thinking about providing only
"recipient AND (true (OR condition)*)"  

-- 
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@...

On Sun, 13 Jun 2004 manu@... wrote:
> Dan Hollis <goemon@...> wrote:
> > The alternative is this, which I think is ugly too:
> > rcpt john.doe@... {
> >       addr 192.0.2.0/24
> >       from friend@...
> >       report none
> > }
> Sure, but here you reproduce the "recipient (AND condition)*" feature
> without the nested feature. I was thinking about providing only
> "recipient AND (true (OR condition)*)"  

Somehow I don't want to receive _ALL_ mails from 192.0.2.0/24. 
friend@... should only be mailing me from 192.0.2.0/24 and nobody 
else from 192.0.2.0/24 has any reason to be whitelisted. and 
friend@... should _never_ email me from 10.0.0.0/8 and if anyone 
does, it's certainly a virus or spam.

That's why I think OR for every clause inside the rcpt{} block is a bad 
idea.

-Dan