Milter-greylist

I want to set up milter-greylist as an  opt-in service. I've got it 
working, but I think I'm doing it by standing it on it's head.

milter-greylist is run with the -T option.

greylist conf contains the list of those who want greylisting:

acl greylist rcpt name@...


This results in LOTS of messages to maillog telling me that it's not 
greylisting most of the mail. Correct, but so what?

Can I run it without -T (i.e., in normal mode) with something like

acl whitelist rcpt *@...
acl greylist rcpt name@...


-- 

    Steve

Steven Stern <subscribed-lists@...> wrote:

> milter-greylist is run with the -T option.

-T is discouraged now, it's only there for backward compatibility.
 
> Can I run it without -T (i.e., in normal mode) with something like
> 
> acl whitelist rcpt *@...
> acl greylist rcpt name@...

milter-greylist ACL work on a first-match win basis. So you want to
write something like this:

acl greylist rcpt name@...
acl whitelist rcpt default


-- 
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

manu@... wrote:
> Steven Stern <subscribed-lists@...> wrote:
> 
> 
>>milter-greylist is run with the -T option.
> 
> 
> -T is discouraged now, it's only there for backward compatibility.
>  
> 
>>Can I run it without -T (i.e., in normal mode) with something like
>>
>>acl whitelist rcpt *@...
>>acl greylist rcpt name@...
> 
> 
> milter-greylist ACL work on a first-match win basis. So you want to
> write something like this:
> 
> acl greylist rcpt name@...
> acl whitelist rcpt default
> 
> 
When I tried that without the -T option, it started greylisting all
incoming mail.

-- 

    Steve

Steven Stern wrote:
> manu@... wrote:
> 
>>Steven Stern <subscribed-lists@...> wrote:
>>
>>
>>
>>>milter-greylist is run with the -T option.
>>
>>
>>-T is discouraged now, it's only there for backward compatibility.
>> 
>>
>>
>>>Can I run it without -T (i.e., in normal mode) with something like
>>>
>>>acl whitelist rcpt *@...
>>>acl greylist rcpt name@...
>>
>>
>>milter-greylist ACL work on a first-match win basis. So you want to
>>write something like this:
>>
>>acl greylist rcpt name@...
>>acl whitelist rcpt default
>>
>>
> 
> When I tried that without the -T option, it started greylisting all
> incoming mail.
> 

greylist.conf:

#
# Greylisting config file
#
# $Id: greylist.conf,v 1.24 2005/01/29 18:42:53 manu Exp $
#
# Some of your users do not get any spam because
# their addresses have never been collected by
# spammers. They will want to avoid the extra delivery
# delay caused by grey listing. You can filter on the
# recipient enveloppe address to achieve that.
#
#  below are the addresses
#  that are subject to greylisting.

acl greylist rcpt aba@...
acl greylist rcpt abc@...
acl greylist rcpt def@...
acl greylist rcpt ghi@...
acl whitelist rcpt default

running as

/usr/local/bin/milter-greylist -P /var/run/milter-greylist.pid -T -u 
smmsp -p /var/milter-greylist/milter-greylist.sock

-- 

    Steve

Steven Stern <subscribed-lists@...> wrote:

> When I tried that without the -T option, it started greylisting all
> incoming mail.

Yes, that's the default if you don't have an ACL entry for default. 
Having "acl whitelist rcpt default" at the end of the ACL is equivalent
to using -T

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

manu@... wrote:
> Steven Stern <subscribed-lists@...> wrote:
> 
> 
>>When I tried that without the -T option, it started greylisting all
>>incoming mail.
> 
> 
> Yes, that's the default if you don't have an ACL entry for default. 
> Having "acl whitelist rcpt default" at the end of the ACL is equivalent
> to using -T
> 

I wind up with everyone being greylisted when not using the -T, despite 
having "acl whitelist rcpt default" following the "acl greylist rcpt" 
entries.

-- 

    Steve

Steven Stern <subscribed-lists@...> wrote:

> I wind up with everyone being greylisted when not using the -T, despite
> having "acl whitelist rcpt default" following the "acl greylist rcpt"
> entries.

The -l option should enable ACL debugging. What does it procudes? 
-- 
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

manu@... wrote:
> Steven Stern <subscribed-lists@...> wrote:
> 
> 
>>I wind up with everyone being greylisted when not using the -T, despite
>>having "acl whitelist rcpt default" following the "acl greylist rcpt"
>>entries.
> 
> 
> The -l option should enable ACL debugging. What does it procudes? 

It's like the whitelist is ignored:

May 21 17:39:23 enoch milter-greylist: Access list dump:
May 21 17:39:23 enoch milter-greylist: acl greylist rcpt 
stern@...
May 21 17:39:23 enoch milter-greylist: acl greylist rcpt 
sstern@...
May 21 17:39:23 enoch milter-greylist: acl greylist rcpt 
rsears@...
May 21 17:39:23 enoch milter-greylist: acl greylist rcpt 
international@...
May 21 17:39:48 enoch milter-greylist: j4LMdmRm028599: addr 70.147.0.18 
from <hevsells@...> to <sescorpio@...> delayed for 
00:30:00
May 21 17:39:48 enoch sendmail[28599]: j4LMdmRm028599: Milter: 
to=<sescorpio@...>, reject=451 4.7.1 Greylisting in 
action, please come back in 00:30:00


My entire grelist.conf is below:

Last login: Sat May 21 17:38:15 2005 from sstern.cciminstitute.com
[root@enoch ~]# vi /etc/init.d/milter-greylist

[root@enoch ~]# cat /etc/mail/greylist.conf
#
# Greylisting config file
#
# $Id: greylist.conf,v 1.24 2005/01/29 18:42:53 manu Exp $
#
# Some of your users do not get any spam because
# their addresses have never been collected by
# spammers. They will want to avoid the extra delivery
# delay caused by grey listing. You can filter on the
# recipient enveloppe address to achieve that.
#
#  below are the addresses
#  that are subject to greylisting.

acl greylist rcpt stern@...
acl greylist rcpt sstern@...
acl greylist rcpt rsears@...
acl greylist rcpt international@...
acl whitelist rcpt default




# Uncomment this to enable verbose output.
# Note that options appearing before the "verbose" option in this
# file will not be treated verbosely.
# May be overridden by the "-v" command line argument.
# verbose

# If you work with multiple MX, list them with
# peer entries to enable greylist sync among the MX

#### abel
peer 10.0.2.193
#### enoch
peer 10.0.2.195


# You may wish to use a specific local address or port for
# syncing between MXes. Of course one of your interfaces
# must have the address assigned. An '*' for the address
# means any address.
#syncaddr *
#syncaddr * port 7689
#syncaddr 192.0.2.2
#syncaddr 192.0.2.2 port 9785
#syncaddr 2001:db8::1:c3b5:123
#syncaddr 2001:db8::1:c3b5:123 port 1234

# Greylisting your own MTA is a very bad idea: never
# comment this line, except for testing purposes.
acl whitelist addr 127.0.0.0/8

# If you use IPv6, uncomment this
#acl whitelist addr ::1/128

# You will want to avoid greylisting your own clients
# as well, by filtering out your IP address blocks.
# Here is an example if you use 192.0.2.0/16
# acl whitelist addr 192.168.123.0/16

# It is also possible de whitelist machines sender
# machines using their DNS names.
#acl whitelist domain example.net

# You can avoid greylisting by filtering on the sender
# enveloppe address but this is not a good idea: it
# can be trivially forged.
#acl whitelist from friendly@...


# It is possible to use regular expressions in from
# and rcpt lines. The expression must be enclosed by
# slashes (/). Note that no escaping is available to
# provide slashes inside the regular expression.
#acl whitelist rcpt /.*@example\.net/

# This option tells milter-greylist when it should
# add an X-Greylist header. Default is all, which
# causes a header to always be added. Other possible
# values are none, delays and nodelays
report delays

# This option attempts to make milter-greylist more
# friendly with sender callback systems. When the
# message is from <>, it will be temporarilly
# rejected at the DATA stage instead of the RCPT
# stage of the SMTP transaction. In the case of a
# multi recipient DSN, whitelisted recipient will
# not be honoured.
#delayedreject

#
# All of the following options have command-line equivalents.
# See greylist.conf(5) for the exact equivalences.
#

# How long a client has to wait before we accept
# the messages it retries to send. Here, 1 hour.
# May be overridden by the command line argument "-w xxx".
greylist 30s


# How long does auto-whitelisting lasts (set it to 0
# to disable auto-whitelisting). Here, 3 days
# May be overridden by the "-a" command line argument.
autowhite 14d

# Normally, clients that succeed SMTP AUTH are not
# greylisted. Uncomment this if you want to
# greylist them regardeless of SMTP AUTH
# May be overridden by the "-A" command line argument.
#noauth

# If milter-greylist was built with SPF support, then
# SPF-compliant senders are not greylisted. Uncomment
# this to greylist them regardless of SPF compliance
# May be overridden by the "-S" command line argument.
nospf

# Uncomment if you want milter-greylist to remain
# in the foreground (no daemon)
# May be overridden by the "-D" command line argument.
#nodetach

# Uncomment if you want auto-whitelist to work for
# the IP rather than for the (IP, sender, reciever)
# tuple.
#lazyaw

# Uncomment this if you do not want milter-greylist
# to tell its client how long they are greylisted.
# May be overridden by the "-q" command line argument.
#quiet

# You can specify a file where milter-greylist will
# store its PID
# May be overridden by the "-P" command line argument.
pidfile "/var/run/milter-greylist.pid"

# The socket used to communicate with Sendmail can
# be specified in this file:
# May be overridden by the "-p" command line argument.
socket "/var/milter-greylist/milter-greylist.sock"

# The dumpfile location
# May be overridden by the "-d" command line argument.
dumpfile "/var/milter-greylist/greylist.db"

# How often should we dump to the dumpfile (0: on each change, -1: never)
dumpfreq 10m

# How long will the greylist database retain tuples
timeout 21d

# The user the milter should run as
# May be overridden by the "-u" command line argument.
user "smmsp"

# This is a list of broken MTA that break with greylisting. Copied from
# 
http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?rev=1.11
acl whitelist addr 12.5.136.141/32    # Southwest Airlines (unique sender)
acl whitelist addr 12.5.136.142/32    # Southwest Airlines
acl whitelist addr 12.107.209.244/32  # kernel.org (unique sender)
acl whitelist addr 12.107.209.250/32  # sourceware.org (unique sender)
acl whitelist addr 63.82.37.110/32    # SLmail
acl whitelist addr 64.7.153.18/32     # sentex.ca (common pool)
acl whitelist addr 64.12.136.0/24     # AOL (common pool)
acl whitelist addr 64.12.137.0/24     # AOL
acl whitelist addr 64.12.138.0/24     # AOL
acl whitelist addr 64.124.204.39      # moveon.org (unique sender)
acl whitelist addr 64.125.132.254/32  # collab.net (unique sender)
acl whitelist addr 66.94.237.16/28    # Yahoo Groups servers (common pool)
acl whitelist addr 66.94.237.32/28    # Yahoo Groups servers (common pool)
acl whitelist addr 66.94.237.48/30    # Yahoo Groups servers (common pool)
acl whitelist addr 66.100.210.82/32   # Groupwise?
acl whitelist addr 66.135.209.0/24    # Ebay (for time critical alerts)
acl whitelist addr 66.135.197.0/24    # Ebay
acl whitelist addr 66.162.216.166/32  # Groupwise?
acl whitelist addr 66.206.22.82/32    # Plexor
acl whitelist addr 66.206.22.83/32    # Plexor
acl whitelist addr 66.206.22.84/32    # Plexor
acl whitelist addr 66.206.22.85/32    # Plexor
acl whitelist addr 66.218.66.0/23     # Yahoo Groups servers (common pool)
acl whitelist addr 66.218.67.0/23     # Yahoo Groups servers (common pool)
acl whitelist addr 66.218.68.0/23     # Yahoo Groups servers (common pool)
acl whitelist addr 66.27.51.218/32    # ljbtc.com (Groupwise)
acl whitelist addr 152.163.225.0/24   # AOL
acl whitelist addr 194.245.101.88/32  # Joker.com
acl whitelist addr 195.235.39.19/32   # Tid InfoMail Exchanger v2.20
acl whitelist addr 195.46.220.208/32  # mgn.net
acl whitelist addr 195.46.220.209/32  # mgn.net
acl whitelist addr 195.46.220.210/32  # mgn.net
acl whitelist addr 195.46.220.211/32  # mgn.net
acl whitelist addr 195.46.220.221/32  # mgn.net
acl whitelist addr 195.46.220.222/32  # mgn.net
acl whitelist addr 195.238.2.105/32   # skynet.be (wierd retry pattern)
acl whitelist addr 195.238.2.124/32   # skynet.be
acl whitelist addr 195.238.3.12/32    # skynet.be
acl whitelist addr 195.238.3.13/32    # skynet.be
acl whitelist addr 204.107.120.10/32  # Ameritrade (no retry)
acl whitelist addr 205.188.0.0/16     # AOL
acl whitelist addr 205.206.231.0/24   # SecurityFocus.com (unique sender)
acl whitelist addr 207.115.63.0/24    # Prodigy - retries continually
acl whitelist addr 207.171.168.0/24   # Amazon.com
acl whitelist addr 207.171.180.0/24   # Amazon.com
acl whitelist addr 207.171.187.0/24   # Amazon.com
acl whitelist addr 207.171.188.0/24   # Amazon.com
acl whitelist addr 207.171.190.0/24   # Amazon.com
acl whitelist addr 211.29.132.0/24    # optusnet.com.au (wierd retry 
pattern)
acl whitelist addr 213.136.52.31/32   # Mysql.com (unique sender)
acl whitelist addr 216.33.244.0/24    # Ebay
acl whitelist addr 218.158.50.178/32  # AXKit mailing list (unique sender)
#################
acl whitelist addr 207.69.200.0/24    # Earthlink
acl whitelist addr 209.86.89.0/24     # Earthlink
acl whitelist addr 66.94.237.0/24     # yahoo.com
acl whitelist addr 64.233.170.0/24    # gmail.com
acl whitelist addr 66.135.192.0/19    # ebay.com



-- 

    Steve

> acl greylist rcpt stern@c...
> acl greylist rcpt sstern@c...
> acl greylist rcpt rsears@c...
> acl greylist rcpt international@c...
> acl whitelist rcpt default

I haven't yet tested this at all, but a quick glance at
greylist.conf(5) shows this:

     Example 2:
           acl whitelist addr 193.54.0.0/16 domain friendly.com
           acl greylist rcpt user1@...
           acl greylist rcpt user2@...
           acl greylist rcpt user3@...
           acl whitelist default

Did anyone actually try the "acl whitelist default" without the rcpt
in there?

Elrond wrote:
>>acl greylist rcpt stern@c...
>>acl greylist rcpt sstern@c...
>>acl greylist rcpt rsears@c...
>>acl greylist rcpt international@c...
>>acl whitelist rcpt default
> 
> 
> I haven't yet tested this at all, but a quick glance at
> greylist.conf(5) shows this:
> 
>      Example 2:
>            acl whitelist addr 193.54.0.0/16 domain friendly.com
>            acl greylist rcpt user1@...
>            acl greylist rcpt user2@...
>            acl greylist rcpt user3@...
>            acl whitelist default
> 
> Did anyone actually try the "acl whitelist default" without the rcpt
> in there?
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
I tried that and it seemed to whitelist everything.  At least, a whole 
stream of IP addresses were shown as whitelisted with the -l flag.

-- 

    Steve

Steven Stern <subscribed-lists@...> wrote:

> >>I wind up with everyone being greylisted when not using the -T, despite
> >>having "acl whitelist rcpt default" following the "acl greylist rcpt"
> >>entries.
> > The -l option should enable ACL debugging. What does it procudes?  
> It's like the whitelist is ignored:

Oh, yes, I see. "acl whitelist default" will work. "acl whitelist rcpt
default" is an undocumented and unspecified config, and I have no idea
of what ir produces.

To whitelist for any recipient, "acl whitelist rcpt /.*/" should work.
But you should have a "acl whitelist default" or "acl greylist default"
at the end of your ACL, it helps understanding what is going on.

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

manu@... wrote:
> Steven Stern <subscribed-lists@...> wrote:
> 
> 
>>>>I wind up with everyone being greylisted when not using the -T, despite
>>>>having "acl whitelist rcpt default" following the "acl greylist rcpt"
>>>>entries.
>>>
>>>The -l option should enable ACL debugging. What does it procudes?  
>>
>>It's like the whitelist is ignored:
> 
> 
> Oh, yes, I see. "acl whitelist default" will work. "acl whitelist rcpt
> default" is an undocumented and unspecified config, and I have no idea
> of what ir produces.
> 
> To whitelist for any recipient, "acl whitelist rcpt /.*/" should work.
> But you should have a "acl whitelist default" or "acl greylist default"
> at the end of your ACL, it helps understanding what is going on.
> 
I was misreading the log.  "acl whitelist default" does produce the 
desired result. THANKS to all who helped.

-- 

    Steve