Milter-greylist

Hi.

I have been using grelisting for a while, using
Jef Poskanzer's graymilter.

The only drawback with that one is it doesnt hold
the greylist db between restarts, yet milter-greylist does.

When I started using greylisting (a while back) I
had trouble with some of the mail server getting the
idea of temp failing, so I fiddled a bit with the
return code.

The best one I found for my environment was

  421 4.3.2 greylisted - please try again later

I tried to change the return code in greylist.conf
but I must be doing something wrong!

  acl greylist default code "421" ecode "4.3.2"

but for some reason, that doesnt work.

I tried to

  code "421"
  ecode "4.3.2"
  msg "some return message"

but that stops the filter from working completely.


What am I doing wrong?



Jobst



-- 
This message represents the official view of the voices in my head!

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

Tere.
>
>
> What am I doing wrong?
>
>   
Probably nothing, as far I know, the default message is hard coded, so
You have make changes in source, look twice in milter-greylist.c for the
word "action:

char *msg = "Greylisting in action, please come back later";

and

"Greylisting in action, please come "
                    "back in %02d:%02d:%02d", h, mn, s);



I always change the default error message to simple "overload." as the
some spammers also read them sometimes and greylistin pisses them off
but overload, well, it happens sometimes...



-- 
Mart

On Mon, Sep 04, 2006 at 10:40:13AM +0300, Mart Pirita wrote:
> Probably nothing, as far I know, the default message is hard coded, so
> You have make changes in source, look twice in milter-greylist.c for the
> word "action:

That changed in 2.1.12. You can now return a per-ACL custom message.

-- 
Emmanuel Dreyfus
manu@...

Tere.
>
> That changed in 2.1.12. You can now return a per-ACL custom message.
>
>   
Hmm, any suggestion how? I have no ACL -s in conf file, only the global:

greylist 15m

Or should I uncomment it and add something like:

acl greylist default delay 15m "overload."


-- 
Mart

--- In milter-greylist@yahoogroups.com, Emmanuel Dreyfus <manu@...> wrote:
>
> On Mon, Sep 04, 2006 at 10:40:13AM +0300, Mart Pirita wrote:
> > Probably nothing, as far I know, the default message is hard coded, so
> > You have make changes in source, look twice in milter-greylist.c
for the
> > word "action:
> 
> That changed in 2.1.12. You can now return a per-ACL custom message.
> 

I figured that ... still, it doesnt work. I tried

  acl greylist default code "421" ecode "4.3.2" msg "example mesg"

but the filter started to go all funny, but then the filter started
rejecting everything ... inluding the whitelisted stuff....

This is explained in the man page so I followed that.

All I want is to have the milter return

   421 4.3.2 example msg

How do I do that?

--- In milter-greylist@yahoogroups.com, Mart Pirita <sysadmin@...> wrote:
>
> Tere.
> >
> >
> > What am I doing wrong?
> >
> >   
> Probably nothing, as far I know, the default message is hard coded, so
> You have make changes in source, look twice in milter-greylist.c for the
> word "action:
> 
> char *msg = "Greylisting in action, please come back later";
> 

I do not think you need to do that, according to the man page.
There are three (optional) parameters that seem to allow
to do this in the config file:

code
ecode
msg


I just cant figure out how ...

On Mon, Sep 04, 2006 at 12:52:16PM -0000, Jobst Schmalenbach wrote:
> 
>   acl greylist default code "421" ecode "4.3.2" msg "example mesg"
> 
> but the filter started to go all funny, but then the filter started
> rejecting everything ... inluding the whitelisted stuff....

If you start the milter with debug turned on, do you see anything
particular? Is the ACL correctly parsed?

> This is explained in the man page so I followed that.
> 
> All I want is to have the milter return
> 
>    421 4.3.2 example msg
> 
> How do I do that?

The line above should do it.

-- 
Emmanuel Dreyfus
manu@...

Tere.
>
> I do not think you need to do that, according to the man page.
> There are three (optional) parameters that seem to allow
> to do this in the config file:
>
> code
> ecode
> msg
>
>
> I just cant figure out how ...
>
>
>   
Well, that make two of us. One for sure - my method works:).
>
>
>
>   


-- 
Mart

On Mon, Sep 04, 2006 at 01:08:07PM +0000, Emmanuel Dreyfus (manu@...) wrote:
> On Mon, Sep 04, 2006 at 12:52:16PM -0000, Jobst Schmalenbach wrote:
> > 
> >   acl greylist default code "421" ecode "4.3.2" msg "example mesg"
> > 
> > but the filter started to go all funny, but then the filter started
> > rejecting everything ... inluding the whitelisted stuff....
> 
> If you start the milter with debug turned on, do you see anything
> particular? Is the ACL correctly parsed?

Mmmmhh.
I can only do that on the weekend ... I reply to this somewhere
around Saturday ...


> 
> The line above should do it.

I know, I can rtfm ;-) AND code.


jobst







-- 
"She said she loved my mind, though by most accounts I had already lost it."

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

On Mon, Sep 04, 2006 at 04:26:07PM +0300, Mart Pirita (sysadmin@...) wrote:
> Tere.
> >
> > I do not think you need to do that, according to the man page.
> > There are three (optional) parameters that seem to allow
> > to do this in the config file:
> >
> > code
> > ecode
> > msg
> >
> >
> > I just cant figure out how ...
> >
> >
> >   
> Well, that make two of us. One for sure - my method works:).

hehehehe ... but ONLY for the message ;-)

I want to change the code/ecode, see my input on "http://www.acme.com/software/graymilter/"






-- 
There are 10 kinds of people in the world, those who understand binary and those who don't.

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

Tere.
>
> hehehehe ... but ONLY for the message ;-)
>   
:).
> I want to change the code/ecode, see my input on "http://www.acme.com/software/graymilter/"
>   
Hmm can't help You with that, but why smtp responce code 4.3.2 is better
than 4.7.1? To confuse the spammer? Actually, this is good idea. Maybe I
should give a try and change the hardcoded code for myself.


Btw, I used also graymilter before and with some patches from -
http://www.dbnet.ece.ntua.gr/~adamo/hacks/graymilter.html to whitelist
whole countries.

>
>
>
>
>
>   


-- 
Mart

On Tue, Sep 05, 2006 at 09:43:33AM +1000, Jobst Schmalenbach wrote:
> > >   acl greylist default code "421" ecode "4.3.2" msg "example mesg"

I just gave it a try with 3.0 alpha6, it worked fine...

-- 
Emmanuel Dreyfus
manu@...

Tere.
>
> I just gave it a try with 3.0 alpha6, it worked fine...
>
>   
Should it work for me also globally, adding something like this in one line:

acl greylist default delay 15m code "421" ecode "4.3.2" msg "example mesg"

or every rule in separate line:


acl greylist default delay 15m
acl greylist default code "421" ecode "4.3.2"
acl greylist default ecode "4.3.2" msg "example mesg"


-- 
Mart

Tere.


So, I tested with the latest version and seems the "all in one line" works:


acl greylist default delay 15m code "421" ecode "4.3.2" msg "example mesg"


Every rule in seperate line:


acl greylist default delay 15m
acl greylist default code "421" ecode "4.3.2"
acl greylist default ecode "4.3.2" msg "example mesg"


Doesn't work, as the hardcoded values will be used.

-- 
Mart

On Tue, Sep 05, 2006 at 03:23:31PM +0300, Mart Pirita wrote:
> So, I tested with the latest version and seems the "all in one line" works:
> acl greylist default delay 15m code "421" ecode "4.3.2" msg "example mesg"
 
Cool, your problem is fixed.
 
> Every rule in seperate line:
> acl greylist default delay 15m
> acl greylist default code "421" ecode "4.3.2"
> acl greylist default ecode "4.3.2" msg "example mesg"
> 
> 
> Doesn't work, as the hardcoded values will be used.

Of course it won't. ACL walking stops on first match. So here we end up
matching "acl greylist default delay 15m", which uses the default
hardcoded value.

-- 
Emmanuel Dreyfus
manu@...

On Tue, Sep 05, 2006 at 12:50:41PM +0000, Emmanuel Dreyfus (manu@...) wrote:
> On Tue, Sep 05, 2006 at 03:23:31PM +0300, Mart Pirita wrote:
> > So, I tested with the latest version and seems the "all in one line" works:
> > acl greylist default delay 15m code "421" ecode "4.3.2" msg "example mesg"
>  
> Cool, your problem is fixed.

Not quite!

That person "hi-jacked" the thread I started, I still do not know 
whether it works for me ..

I run two full blown mailservers (one company and one medium school), so 
I can test only on the weekend or I will make a "few" people rather angry ...


When I initially tried it (during the week) I tried that suggested
line but ended up greylisting even the internal and whitelisted
addresses, so in the moment I do not take my chances!



jobst




-- 
Avon: I'm not expendable, I'm not stupid, and I'm not going.

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

On Wed, Sep 06, 2006 at 06:55:30PM +1000, Jobst Schmalenbach wrote:
> When I initially tried it (during the week) I tried that suggested
> line but ended up greylisting even the internal and whitelisted
> addresses, so in the moment I do not take my chances!

I guess you supplied milter-greylist with a config file containing
syntax errors. Since the config is reloaded automatically when it is
changed, it's sometime easy to screw things up.

Since 3.0. alpha 3, you can check the syntax without actually using it:

$ cp /etc/mail/greylist.conf /tmp/
$ vi /tmp/greylist.conf			<-- here I introduce an error
$ milter-greylist -cf /tmp/greylist.conf 
config error at line 1: syntax error
$ vi /tmp/greylist.conf			<-- here I fix the error
$ milter-greylist -cf /tmp/greylist.conf
config file "/tmp/greylist.conf" is okay
$ su -m root -c "cp /tmp/greylist.conf /etc/mail"

-- 
Emmanuel Dreyfus
manu@...

On Wed, Sep 06, 2006 at 09:14:00AM +0000, Emmanuel Dreyfus (manu@...) wrote:
> On Wed, Sep 06, 2006 at 06:55:30PM +1000, Jobst Schmalenbach wrote:
> > When I initially tried it (during the week) I tried that suggested
> > line but ended up greylisting even the internal and whitelisted
> > addresses, so in the moment I do not take my chances!
> 
> I guess you supplied milter-greylist with a config file containing
> syntax errors. Since the config is reloaded automatically when it is
> changed, it's sometime easy to screw things up.

I said to you that I will try on the weekend to "play" with it again,
you suggested to turn debug on, so I will do that ...

I will keep you posted once the weekend comes, at least I cant
greylist users from the inside than ;-)


jobst




-- 
The reason you cannot think about eternity is because the intellect which is doing the thinking is an instrument of time and nothing else.

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

Tere.
>
> Not quite!
>
> That person "hi-jacked" the thread I started, I still do not know 
> whether it works for me ..
>
>   
Heh, it was me. It works for me and now I'm using the a4 version, as a5
eat 99% cpu and a6 was missing some log entry's.


-- 
Mart

Mart Pirita <sysadmin@...> wrote:

> Heh, it was me. It works for me and now I'm using the a4 version, as a5
> eat 99% cpu and a6 was missing some log entry's.

What's missing from alpha 6? If I'm not aware of problems, I can't fix
them...

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Tere.
> Mart Pirita <sysadmin@...> wrote:
>
>   
>> Heh, it was me. It works for me and now I'm using the a4 version, as a5
>> eat 99% cpu and a6 was missing some log entry's.
>>     
>
> What's missing from alpha 6? If I'm not aware of problems, I can't fix
> them...
>
>   
Hmm, I was posted it before (Re: [milter-greylist] milter-greylist 3.0
alpha 6 is out), but here it is again:

So here is the alpha 6. It's quite likely that I got confused when
> juggling with branches and patch, so give it a try, but keep in mind
> that it may be horribly broken :-)
> 

Works so far, but I noticed some changes in logs, can't see anymore this
line - "skipping greylist because sender DNS name xxx.xxx.xx is whitelisted"

The only thing I changed in conf file:

added - acl greylist default delay 15m code "421" ecode "4.3.2" msg
"example mesg"

commented out - greylist 15m





-- 
Mart

On Wed, Sep 06, 2006 at 03:48:26PM +0300, Mart Pirita wrote:
> Works so far, but I noticed some changes in logs, can't see anymore this
> line - "skipping greylist because sender DNS name xxx.xxx.xx is whitelisted"
> 
> The only thing I changed in conf file:
> 
> added - acl greylist default delay 15m code "421" ecode "4.3.2" msg
> "example mesg"
> 
> commented out - greylist 15m

Can you send me the config file?

-- 
Emmanuel Dreyfus
manu@...

Tere.
>
>
> Can you send me the config file?
>
>   
Sure, active lines are:
                                                                                   

acl whitelist addr 
127.0.0.0/8                                                                                     

acl whitelist domain 
.ee                                                                                 

acl greylist default delay 15m code "421" ecode "4.3.2" msg 
"overload"                                            
report 
none                                                                                                        

dumpfreq 
10m                                                                                                       

logexpired                                                                                                         

timeout 
12h                                                                                                        

noaccessdb                                                                                                         

autowhite 12h  


and commandline (somehow these aren't read from config file) keys are:

milter-greylist -P /var/run/greylist/greylist.pid -p 
/var/run/greylist/greylist.sock -q

-- 
Mart

Tere.


I have used few days custom code, ecode and message:

acl greylist default delay 15m code "421" ecode "4.3.2" msg "overload" 

And noticed, that I did get more spam than before. The message isn't 
reason, that's for sure (I had this hard coded before also) but what 
about the code and ecode. Default hard coded code is 451 and ecode 
4.7.1. Just changed back, but I', still wondering, have anyone noticed 
same situation or these codes isn't related to received spam amount and 
spammers are more and more using legal smtp servers?


-- 
Mart

We are working on compiling a list of known spam servers. Suprisingly, there 
are three known servers sending spam from legitimate MTAs in Australia, 
dumping out about 1/3rd of our australia-targeted spam. So yeah, theres a 
bunch of legit mail servers out there spamming. We are working on our 
blacklist contents, and will share it all with you guys as we proceed.

On Thursday 07 September 2006 01:59 am, Mart Pirita wrote:
> Tere.
>
>
> I have used few days custom code, ecode and message:
>
> acl greylist default delay 15m code "421" ecode "4.3.2" msg "overload"
>
> And noticed, that I did get more spam than before. The message isn't
> reason, that's for sure (I had this hard coded before also) but what
> about the code and ecode. Default hard coded code is 451 and ecode
> 4.7.1. Just changed back, but I', still wondering, have anyone noticed
> same situation or these codes isn't related to received spam amount and
> spammers are more and more using legal smtp servers?

Mart Pirita wrote:
> Tere.
>
>
> I have used few days custom code, ecode and message:
>
> acl greylist default delay 15m code "421" ecode "4.3.2" msg "overload" 
>
> And noticed, that I did get more spam than before. The message isn't 
> reason, that's for sure (I had this hard coded before also) but what 
> about the code and ecode. Default hard coded code is 451 and ecode 
> 4.7.1. Just changed back, but I', still wondering, have anyone noticed 
> same situation or these codes isn't related to received spam amount and 
> spammers are more and more using legal smtp servers?

I've been getting more stock spam lately. Every time I check full
headers, I see the greylist header indicating that the message was
delayed. So they are resending. What I'm seeing getting through is
almost entirely stock spam (stock alerts, investment, etc.).

(I haven't changed anything recently.)


---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk@...>

--------------- 

Erd\ufffds 4

On Thu, Sep 07, 2006 at 09:30:25AM -0400, Chris Hoogendyk wrote:
> I've been getting more stock spam lately. Every time I check full
> headers, I see the greylist header indicating that the message was
> delayed. So they are resending. What I'm seeing getting through is
> almost entirely stock spam (stock alerts, investment, etc.).

If you increase the delay, they will give up. 
Handling resends needs resources. The spammer midly care, since he
is not paying for the CPU, memory, and disk space of hijacked machines.
On the other hand, this free resource is not infinite. If the machine 
sends 100 message per second to servers with a delay of 12 hours, the 
resend queue will grow up exhausting available resources.

But it is not possible to have a delay of 12 hours for everyone. This is
why I indtroduced DNSRBL and per-ACL delays in milter-greylist. You can
now have different delays depending on the sender reputation. Machines on
dynamic IP pools are not likely to be real SMTP servers, so we can 
affore a much higher delay for them. And that seems to do the trick.

-- 
Emmanuel Dreyfus
manu@...

On Thu, Sep 07, 2006 at 03:49:48PM +0000, Emmanuel Dreyfus (manu@...) wrote:
> On Thu, Sep 07, 2006 at 09:30:25AM -0400, Chris Hoogendyk wrote:
> > I've been getting more stock spam lately. Every time I check full
> > headers, I see the greylist header indicating that the message was
> > delayed. So they are resending. What I'm seeing getting through is
> > almost entirely stock spam (stock alerts, investment, etc.).
> 
> If you increase the delay, they will give up. 
> Handling resends needs resources. The spammer midly care, since he
> is not paying for the CPU, memory, and disk space of hijacked machines.
> On the other hand, this free resource is not infinite. If the machine 
> sends 100 message per second to servers with a delay of 12 hours, the 
> resend queue will grow up exhausting available resources.


You are  correct!

However, I have found that one way of beating ANY GREYMILTER is
sending an email ONE day and send ANOTHER ONE the next day. Because
the IP address has been moved on to the whitelist it is now
free to take a message.

The spammer this way saves a lot of energy to resend a number of times.

What would be good to have is another check running in the greymilter
that takes an IP address OFF the whitelist if it has not received another 
email with a certain time range.

This might explain it:

  * spammer sends the first trime on day one

  * greylist rejects email

  * time passes

  * greylist whitelists the spammer.

  * time passes and spammer still whitelisted

  * spammer sends the SECOND time on day TWO
    and eamil gets through

    YES, I am aware that the next filters will
    catch it if the address is on DNSRBL



Another way will decrease the chance of spammer getting through

  * spammer sends the first trime on day one

  * greylist rejects email

  * time passes

  * greylist whitelists the spammer.

  * time passes

  * after 12 hours spammer is taken of the
    whiltelist as no OTHER email was received

  * spammer sends the SECOND time (after 24hours) 
    on day TWO and email is TEMP FAILED again

    ;-)


jobst



-- 
Tommorow or the next life, whichever comes first, we never know. - Saying from Tibet.

             __, Jobst Schmalenbach, Technical Director
   _ _.--'-n_/   Barrett Consulting Group P/L & The Meditation Room P/L      
 -(_)------(_)=  +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

Tere.
> If you increase the delay, they will give up.
I don't think so. That's by the way why I tried to change this error
code, as seems some of them will specially attack these servers which
give the 4.7.1 (greylisted) error.

> Handling resends needs resources. The spammer midly care, since he
> is not paying for the CPU, memory, and disk space of hijacked machines.
> On the other hand, this free resource is not infinite. If the machine 
> sends 100 message per second to servers with a delay of 12 hours, the 
> resend queue will grow up exhausting available resources.
>
> But it is not possible to have a delay of 12 hours for everyone. This is
> why I indtroduced DNSRBL and per-ACL delays in milter-greylist. You can
> now have different delays depending on the sender reputation. Machines on
> dynamic IP pools are not likely to be real SMTP servers, so we can 
> affore a much higher delay for them. And that seems to do the trick.
>
>   
Yes, and no. I personally can't use this dnsbl.sorbs.net as it
blacklists usually by subnets, even by county, not by address. And at
least in Baltic States and Scandinavian countries, at least 90% home
users uses dynamic ip and they will be infinitely greylisted even if
send emails true their ISP -s smtp server as the senders (dynamic) ip is
still in message  header.

-- 
Mart

Tere.
>
> Another way will decrease the chance of spammer getting through
>
>   * spammer sends the first trime on day one
>
>   * greylist rejects email
>
>   * time passes
>
>   * greylist whitelists the spammer.
>
>   * time passes
>
>   * after 12 hours spammer is taken of the
>     whiltelist as no OTHER email was received
>
>   * spammer sends the SECOND time (after 24hours) 
>     on day TWO and email is TEMP FAILED again
>
>   
Set the autwhite as less as You can, for example 1-3 hour or just
disable the autowhitelist completely?


-- 
Mart

On Fri, Sep 08, 2006 at 10:00:36AM +0300, Mart Pirita wrote:
> Yes, and no. I personally can't use this dnsbl.sorbs.net as it
> blacklists usually by subnets, even by county, not by address. 

I only use the dynamic pool DNSRBL, which returns 127.0.0.10. 

> And at least in Baltic States and Scandinavian countries, at least 90% home
> users uses dynamic ip and they will be infinitely greylisted even if
> send emails true their ISP -s smtp server as the senders (dynamic) ip is
> still in message  header.

milter-greylist does not look at the headers, just at the incoming IP
address. If an user is in SORBS dynamic pool DNSRBL and sends an e-mail
through its ISP SMTP server, I won't use the high delay.

-- 
Emmanuel Dreyfus
manu@...

Tere.


I have some questions, as the spam keeps coming true lately more than before. So I
did set:

acl greylist default delay 15m code "451" ecode "4.7.1" msg "greylisted"
timeout 3h
autowhite 0

Still some passes true. Now maybe I should set the delay 30m and timeout 30m?

And if is set autowhite 0 then why is this "autowhitelisted for 00:00:00" shown in
logs at all:

Sep 11 00:30:45 tibu milter-greylist: k8ALUjNm003277: addr 212.47.13.211 from
<2006sachsen_winningnotification@...> rcpt <xx@xxx>: autowhitelisted for 00:00:00
Sep 11 00:30:45 tibu sendmail[3277]: k8ALUjNm003277:
from=<2006sachsen_winningnotification@...>, size=6399, class=0, nrcpts=1,
msgid=<918b7b127efb46b0aeeecd44435bc881@...>, proto=ESMTP, daemon=MTA,
relay=paegas3.mail-atlas.net [212.47.13.211]
Sep 11 00:31:54 tibu milter-greylist: (local): addr 212.47.13.211 from
<2006sachsen_winningnotification@...> rcpt <xx@xxx>: autowhitelisted entry
expired

And why one minute later autowhitelisted entry expired, not in the same moment
when autowhitelisted for 00:00:00?

-- 
Mart

On Mon, Sep 11, 2006 at 10:00:00AM +0300, Mart Pirita wrote:
> acl greylist default delay 15m code "451" ecode "4.7.1" msg "greylisted"
> timeout 3h
> autowhite 0
> 
> Still some passes true. Now maybe I should set the delay 30m and timeout 30m?

Some spamware handle resending now. They seems to give up against a delay
of several hours. 

Of course several hours is not something you want for any sender, this is
where using dynamic pool DNSRBL helps: I use several hours for cable and
DSL pools, qnd 15 mn for other hosts.

> And if is set autowhite 0 then why is this "autowhitelisted for 00:00:00" shown in
> logs at all:

The 0 minutes dalay for autowhitelisting implementation is subotptimal for 
now, as an entry is still created in the database. The semantics is right, 
through: there is no autowhitelisting, as the autowhitelisting entry is
already expired when it is inserted in the database.

In a future release I'll take care of not creating an entry at all.

> And why one minute later autowhitelisted entry expired, not in the same moment
> when autowhitelisted for 00:00:00?

Because we never specifically hunt for timeouts in the database. The 
functions that have to walk the database for some reason take care of
removing expired entries. If you have no incoming mail, the expired entries
are not flushed, but that does not really matter, since they are not used.

-- 
Emmanuel Dreyfus
manu@...

Tere.
>
> Some spamware handle resending now. They seems to give up against a delay
> of several hours. 
>   
I hope so, but I can't set 4h delay as legal senders and receivers are
going mad.
> Of course several hours is not something you want for any sender, this is
> where using dynamic pool DNSRBL helps: I use several hours for cable and
> DSL pools, qnd 15 mn for other hosts.
>   
Idea is good but I almost cant use it, as like I said, also at least 70%
legal senders are using dynamic ip -s and this blocks them also and it's
no good. Maybe I should use some other (which?) DNSRBL server to let
pass the good ones (near countries) and block the bad (asia etc)?
>
> The 0 minutes dalay for autowhitelisting implementation is subotptimal for 
> now, as an entry is still created in the database. The semantics is right, 
> through: there is no autowhitelisting, as the autowhitelisting entry is
> already expired when it is inserted in the database.
>
> In a future release I'll take care of not creating an entry at all.
>   
Ok.
> Because we never specifically hunt for timeouts in the database. The
> functions that have to walk the database for some reason take care
> ofremoving expired entries. If you have no incoming mail, the expired
> entriesare not flushed, but that does not really matter, since they
> are not used.
>
Ok.

-- 
Mart

On Mon, Sep 11, 2006 at 11:55:38AM +0300, Mart Pirita wrote:
> > Of course several hours is not something you want for any sender, this is
> > where using dynamic pool DNSRBL helps: I use several hours for cable and
> > DSL pools, qnd 15 mn for other hosts.
> >   
> Idea is good but I almost cant use it, as like I said, also at least 70%
> legal senders are using dynamic ip -s and this blocks them also and it's
> no good.

You have 70% legitimate senders from dynamic IP pools? What kind of e-mail
do you receive? People running on dymanic IP pools tend to use their ISP
SMTP server, which is not on a dynamic IP pool...

-- 
Emmanuel Dreyfus
manu@...

Emmanuel Dreyfus wrote:
 > Of course several hours is not something you want for any sender, this is
 > where using dynamic pool DNSRBL helps: I use several hours for cable and
 > DSL pools, qnd 15 mn for other hosts.

That's something I don't understand.

People sending mail to you from dynamic IP dial-in pools
usually don't let their PC running 24 hours per day.
That means that delaying them for several hours isn't
good, because their PC will probably be switcehd off
by then.

I think there are only two possibilities that make sense.
The first is to blacklist dynamic IP pools completely,
i.e. _never_ accept mail from them.  That's what I do,
because expecience shows that it's 100% spam anyway, so
there's no reason to clutter my greylist with such IPs.
Users who have dynamic IP addresses should use their
ISP's mail server for sending mails in the first place
anyway.

The second possibility:  If you absolutely must receive
mails from users of dynamic addresses, and you cannot
teach them to properly use their ISP's mail server, then
use a short greylisting delay (a few minutes).  Otherwise
there's the risk that you won't get their mails at all,
or get them only the next day, or on Monday after the
weekend.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"File names are infinite in length, where infinity is set to 255 characters."
        -- Peter Collinson, "The Unix File System"

On Mon, Sep 11, 2006 at 11:31:31AM +0200, Oliver Fromme wrote:
> People sending mail to you from dynamic IP dial-in pools
> usually don't let their PC running 24 hours per day.

They also don't send you e-mail directly. If the machine is a SMTP 
server, it is not powered off randomly, and if it is not a SMTP server,
then it does not send you e-mail directly.

-- 
Emmanuel Dreyfus
manu@...

Emmanuel Dreyfus wrote:
 > Oliver Fromme wrote:
 > > People sending mail to you from dynamic IP dial-in pools
 > > usually don't let their PC running 24 hours per day.
 > 
 > They also don't send you e-mail directly. If the machine is a SMTP 
 > server, it is not powered off randomly, and if it is not a SMTP server,
 > then it does not send you e-mail directly.

Excatly.  That's exactly what I am thinking.

And that's why it makes sense not to delay dynamic IP pools
for a long time, or to greylist them at all.  Blacklist them.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"FreeBSD is Yoda, Linux is Luke Skywalker"
        -- Daniel C. Sobral

Tere.
>
> You have 70% legitimate senders from dynamic IP pools? What kind of e-mail
> do you receive? 
All kind of normal emails.

> People running on dymanic IP pools tend to use their ISP
> SMTP server, which is not on a dynamic IP pool...
>
>   
Well, I can't tell to the clients to use legal smtp server. And by the
way, almost every big ISP smpt (hotmail, google, yahoo etc) server is
also atleast every day some time blacklisted. So ISP -s smtp server
isn't the best solution also. But now the problems seems, that, some RBL
servers blacklistes whole countries and subnets, note the actual ip
addresses.

-- 
Mart

I would love to do this. How are you determining if they arecoming from a 
dynamic pool?

On Monday 11 September 2006 06:22 am, Oliver Fromme wrote:
> Emmanuel Dreyfus wrote:
>  > Oliver Fromme wrote:
>  > > People sending mail to you from dynamic IP dial-in pools
>  > > usually don't let their PC running 24 hours per day.
>  >
>  > They also don't send you e-mail directly. If the machine is a SMTP
>  > server, it is not powered off randomly, and if it is not a SMTP server,
>  > then it does not send you e-mail directly.
>
> Excatly.  That's exactly what I am thinking.
>
> And that's why it makes sense not to delay dynamic IP pools
> for a long time, or to greylist them at all.  Blacklist them.
>
> Best regards
>    Oliver

Mart Pirita wrote:
 > > 
 > > You have 70% legitimate senders from dynamic IP pools? What kind of e-mail
 > > do you receive? 
 > All kind of normal emails.

Sending mails from dynamic IP addresses without using the
ISP's mail server is not "normal".

 > > People running on dymanic IP pools tend to use their ISP
 > > SMTP server, which is not on a dynamic IP pool...
 > 
 > Well, I can't tell to the clients to use legal smtp server. And by the
 > way, almost every big ISP smpt (hotmail, google, yahoo etc) server is
 > also atleast every day some time blacklisted. So ISP -s smtp server
 > isn't the best solution also. But now the problems seems, that, some RBL
 > servers blacklistes whole countries and subnets, note the actual ip
 > addresses.

That's not true in general.  It depends which blacklist
you use.  There are indeed very "aggressive" blacklists.
I don't recommend to use one of those.

Personally I've the following two lines in my sendmail.mc
which work very well.  And yes, I can still receive mails
from google, yahoo etc.  :-)

FEATURE(dnsbl,`combined.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/')
FEATURE(dnsbl, `list.dsbl.org', `Rejected mail from $&{client_addr} - see http://dsbl.org/')dnl

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
        -- Doug Gwyn

Mart;
  My guess is that you arent in the United States. Here, a large number of  
cable companies that provide broadband do not allow outbound smtp traffic at 
all, for any reason. While your clients may be offended that they can not 
send from their own personal mailservers with dynamic ips, it honestly is a 
good idea to either blacklist or severely delay mail coming from dynamic 
address space. The rationale is simple. If you are a real mail server, then 
obviously you would want to get mail back, and you would never want to make 
it more difficult for people to send you mail than you would want for them to 
receive your mail. Given that dyndns takes some time to propogate across the 
internet, relying on dynamic addressing obviously makes failure rates on send 
to your mail server much much higher. I bet if you do careful forensics on 
your mail queue, you will find that legitimate mail from purported dynamic 
ips is actually just mail relaying directly off the server, ie sending mail 
directly to the destination, with the destination as the relay. There are 
multiple ways to handle this, from whitelisting tuples that have been 
smtp-authed, or in our backwards world way, using pop/imap to directly append 
to the greylist for a period of time. 

On Monday 11 September 2006 08:39 am, Mart Pirita wrote:
> Tere.
>
> > You have 70% legitimate senders from dynamic IP pools? What kind of
> > e-mail do you receive?
>
> All kind of normal emails.
>
> > People running on dymanic IP pools tend to use their ISP
> > SMTP server, which is not on a dynamic IP pool...
>
> Well, I can't tell to the clients to use legal smtp server. And by the
> way, almost every big ISP smpt (hotmail, google, yahoo etc) server is
> also atleast every day some time blacklisted. So ISP -s smtp server
> isn't the best solution also. But now the problems seems, that, some RBL
> servers blacklistes whole countries and subnets, note the actual ip
> addresses.

On Mon, Sep 11, 2006 at 08:47:04AM -0400, eclark wrote:
> I would love to do this. How are you determining if they arecoming from a 
> dynamic pool?

I use SORBS DUHL DNSRBL.
There is an example in 3.0a6's README (section 9)

-- 
Emmanuel Dreyfus
manu@...

We are still running I 2.0.2 (the version linked to on the homepage), and 
havent upgraded yet to a blacklist enabled version of the milter (later 
versions of the 2 series arent to be found). Which takes priority in a case 
of conflict, a blacklist rule or a whitelist rule? I ask, because as 
mentioned elsewhere, we explicitly whitelist dynamic ips that have 
authenticated with our mailservers, and I wouldnt want those people to be 
blacklisted. 

On Monday 11 September 2006 09:05 am, Emmanuel Dreyfus wrote:
> On Mon, Sep 11, 2006 at 08:47:04AM -0400, eclark wrote:
> > I would love to do this. How are you determining if they arecoming from a
> > dynamic pool?
>
> I use SORBS DUHL DNSRBL.
> There is an example in 3.0a6's README (section 9)

Tere.
> Sending mails from dynamic IP addresses without using the
> ISP's mail server is not "normal".
>   
Why not? A lot of people are using their own smtp server for sending emails.
> That's not true in general.  It depends which blacklist
> you use.  There are indeed very "aggressive" blacklists.
> I don't recommend to use one of those.
>
> Personally I've the following two lines in my sendmail.mc
> which work very well.  And yes, I can still receive mails
> from google, yahoo etc.  :-)
>   
Heh.
> FEATURE(dnsbl,`combined.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/')
> FEATURE(dnsbl, `list.dsbl.org', `Rejected mail from $&{client_addr} - see http://dsbl.org/')dnl
> r
>
>   
Right now I'm using - sbl-xbl.spamhaus.org, bl.spamcop.net,
no-more-funn.moensted.dk, dnsbl.njabl.org, list.dsbl.org was too
agressive for me. But I'll give try to use combined.njabl.org, as it's
includes dnsbl.njabl.org and dynablock.njabl.org.

-- 
Mart

eclark <eclark@...> wrote:

> We are still running I 2.0.2 (the version linked to on the homepage), and
> havent upgraded yet to a blacklist enabled version of the milter (later
> versions of the 2 series arent to be found). Which takes priority in a case
> of conflict, a blacklist rule or a whitelist rule? 

It depends of the order of your access list: first match wins.

The big new feature in 3.0 is that you can use the information "sender
is in a given DNSRBL" as a trigger for doing greylisting with a higher
delay than for other hosts. You can now make setups where the worst the
reputation of an IP is, the higher the greylisting delay will be.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...