gmane.mail.sendmail.milter.greylist

Re: nsupdate support

Jim Klimov — 2013-05-20T13:30:22

Hmm... I guess you're right. Still, it can be part of the expiration
mechanism - if the server has the blacklist entry removed by the time
of TTL re-request, the client would refresh its cache and see that
the target IP is no longer blacklisted.

I don't think there's a DNS notion of entry expiration. There's zone
expiration, which means that after some time that it has been cached
and couldn't be refreshed from source, it should no longer be trusted,
and queries via this cached data should begin to fail. This allows to
"put to rest" and discard unmaintained DNS zones which would otherwise
pollute the internet forever.

//Jim



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylis

Re: nsupdate support

2013-05-20T04:40:29


Another idea: for each A record stored, I can add a TXT record for the
current date. For instance, for today may 20th, I blacklist 192.0.2.1
and 192.0.2.2. I would have in my zone file:

1.2.0.192.bl.example.net IN A 127.0.0.1
2.2.0.192.bl.example.net IN A 127.0.0.1
20130520.bl.example.net IN TXT 1.2.0.192.bl.example.net 
20130520.bl.example.net IN TXT 2.2.0.192.bl.example.net 

That way I just need to perform a DNS lookup on current date to get all
the records I need to cleanup.

milter-greylist-4.5.1 is available

2013-05-20T04:37:02

Here is milter-greylist-4.5.1
http://ftp.espci.fr/pub/milter-greylist/milter-greylist-4.5.1.tgz
MD5 (milter-greylist-4.5.1.tgz) = e0149825bd2912e20a57f70539b00427

Changes sinces 4.4.3:
        DNS update support
        make clean clears milter-greylist.spec
        Use ZZ for unknown GeoIP country
        Add IPv6 support for MX sync (Hajimu UMEMOTO)

A note for DNS update: it is automatically enabled at configure time if
your resolver supports it. configure tries to link a test progrem with
res_nupdate() for that. Here is an example configuration and usage to
create your own DNSRBL:

  sig "dns-update" "hmac-md5" "1B2M2Y8AsgTpgAmY7PhCfg=="
  nsupdate "bl.example.net" { rname  "%j.bl.example.net"  rvalue 
       "127.0.0.2" tsig "dns-update" }

  racl blacklist rcpt spamtrap-hcDgGtZH8xPR7s880joybQ< at >public.gmane.org nsupdate "bl.example.net"

NB: %j is the reversed sender IP address. e.g.: 192.0.2.1 becomes
1.2.0.192

On the DNS server side, iff you run BIND, you are going to have
something like this:

key "

Re: nsupdate support

Peter Bonivart — 2013-05-19T14:38:53

Don't log the addition until you have actually done the nsupdate op,
after that it's BINDs responsibility and it uses journaling for the
transactions so it should be safe to restart.

If the log file is produced by syslog a contributed script can parse
it using a marker, extracting timestamp and addresses. Number of hours
for removal should be configurable. Even simpler would be to combine
it with logrotate and have a script remove all entries in the not
current log file. Up to the user to set logrotate intervals.

/peter


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >p

Re: nsupdate support

2013-05-19T14:24:22


That may be the easiest way. Using the greylisting database requires
heavy refactoring, as the stored object is quite different from the
current tuple.

One caveat for the log file: how do we resume operations? We lookup all
addresses in the log until we find one not registered? And we need to
clear older entries after some time, but how can it be done efficiently?
(that is without moving the data within the file toward start)

Re: nsupdate support

Peter Bonivart — 2013-05-19T11:10:14

Maybe the addition could be logged and the timestamp could be used by
an external script to remove old entries.

/peter


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: nsupdate support

2013-05-19T11:03:58


Yes, you are right. TTL is no expiration mechanism.

Re: nsupdate support

Peter Bonivart — 2013-05-19T09:37:37

But TTL is for the client to decide if it should refresh it's cache or
not (use cache or ask server again), it doesn't mean the record will
expire on the server which I believe is what manu means.

/peter


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Re: Feature request - include in greylist.conf

Jim Klimov — 2013-05-19T09:27:25

I do use site-specific configurations (likely anyone does somehow)
by creating a number of files named like "greylist-01-common.conf"
and so on for manual whitelists, balcklists and other exceptions,
some of these are distributed via CVS to maintain commonality of
config on several relays, some files can optionally be local.

There's a cron-script which tries to pull updates from CVS, and if
any exist - in just does "cat greylist-??-*.conf > greylist.conf"
and restarts/refreshes the milter service.

This achieves the same goal as include files in a somewhat more
clumsy way, but without changes to milter-greylist, and works
for years.

Also, user-modifiable include files might be a security-breach
source by fooling the daemon into reading (or doing) something
that it shouldn't. This might be avoidable by some policy in the
milter-greylist (i.e. like sendmail is picky about POSIX flags),
or just make a warning in the docs, but the potential problem
should not be ignored and be kept unaware of. :)

//Jim Klimov

Re: nsupdate support

Jim Klimov — 2013-05-19T09:17:34

Well, I used dynamic DNS in our LAN to point a service name to
recently-working instances of the service (i.e. "proxy" points
to several SQUID instances if they work), and the script which
does this just tests the service and calls the nsupdate binary:

# case ...  0) # OK
                 ( echo "server $DNSMASTER"
                   echo "zone $DNSZONE"
                   echo "update add $DNSZONE. $DNSTTL A $IP"
                   echo "" ) | nsupdate
                 ;;
             *) # FAIL
                 ( echo "server $DNSMASTER"
                   echo "zone $DNSZONE"
                   echo "update delete $DNSZONE. A $IP"
                   echo "" ) | nsupdate

This is on Solaris, but AFAIK the nsupdate part is a standard
BIND one (I did have to update BIND on some older DNS servers
to have it working as I needed). As you can see above, there
is a possibility to set the TTL for an added entry, which I
believe should override the one set in the zone's SOA record.

Your other solution choice is (

Re: Re: Feature request - include in greylist.conf

Peter Bonivart — 2013-05-19T08:41:41

A simple way would be not to change anything! If we change an included
file we touch the greylist.conf-file ourselves to trigger a reload. I
think those who want this feature would be good with that.

/peter


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

nsupdate support

2013-05-19T05:13:03

Hi 

I am working on nsupdate support in milter-greylist, so that an action
clause in an ACL can trigger a DNS update, which enables milter-greylist
to feed a DNSRBL based on ACL conditions.

That first part works fine, but I thought about handling expiration of
added DNS record. It seems there is no way to tell the DNS that an added
entry should expire. That would suggest milter-greylist sould manage it,
which leads to a lot of complexity. 

What people think about it? Is expiration actually useful, and how to
implement it?

Re: Re: Feature request - include in greylist.conf

2013-05-19T01:43:49


You need to monitor included file changes to detect configuration
changes. Feel free to send a patch to the list.

Re: Feature request - include in greylist.conf

elrond421 — 2013-05-18T18:49:00

[Reviving an old discussion...]

--- In milter-greylist-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, shuttlebox <shuttlebox< at >...> wrote:

This would also make distribution maintaining easier. Parts of the file maintained by the distributor (socket location for example) or parts maintained upstream (the list of broken MTAs) can be updated without affecting the main config, that the user surely edited.

So what exactly is the problem about this feature?

Code bloat? The syntax is already quite interesting. It wouldn't add really much more complexity, IMHO.

That said, one option is of course to use m4 or cpp outside of milter-greylist and let m4/cpp create the final config from some source files. Like what sendmail.mc is doing. Then we can use m4's include() and be done.

As one bug part of the shipped config is the list of broken MTAs, it would be good if milter-greylist has a default way of doing this and would do it for that list. That way I get a fresh list on upgrade without having to copy it by hand into my m

Re: Re: Determining how successful milter-greylist is?

Emmanuel Dreyfus — 2013-04-09T16:09:39

I address that by having user-configurable recipient-dependent
greylisting delays. They can choose no greylisting, 15mn greylisting,
15mn greylisting + 12h for hosts in SOBRS DUN (DSL and cable hosts).

People that want no delay have no delay. People that want filtering
get filtering. And they can change it whenver they want.

Re: Re: Determining how successful milter-greylist is?

Jim Klimov — 2013-04-09T13:08:09

 From our practice, I'd add that greylisting works to a large
extent thanks to coupling with DNS RBLs, including dial-up
RBL lists. While the message from an unknown untrusted source
host is being delayed from coming into our relay, other letters
from this host might hit an RBL honeypot system and by the time
that greylisting permits the message in based on just the fact
of retry after a given timeout, it would be denied based on DNS
RBL hit. Proper emails from extranet are accepted on the MSA
port (587/tcp) with authentication and STARTTLS, so we should
have no spam that seems to be sent from one of our users to
another - as well as no harmful filtering enforced onto proper
authenticated users from random internet hosts.

This does of course require considerable delays on newly
greylisted contacts, which does sometimes cause grief from
our users; we use about 25 minutes typically (because many
legitimate hosts retry their submissions after half an hour
and then less often) so that greylist's impact is smal

Re: Re: Determining how successful milter-greylist is?

Emmanuel Dreyfus — 2013-04-09T07:08:45

I do not think so.

Working around greylisting means maintaining a queue. Since spammers
use botnet, resources are free for them but they are not infinite. 
If the greylisting delay is long enough, we observe they do not afford it.

Beside this, greylisting does not scale for really huge domains, which 
means that the incensive for working it around remains low: gmail, hyahoo,
hotmail and other monsters will never use it.

Re: Re: Determining how successful milter-greylist is?

Peter Bonivart — 2013-04-09T07:01:50

Couldn't you make the exact same argument about greylisting? After all
they are very similar and all about if they resend or not. Nolisting
to me is just a poor mans implementation of greylisting. There should
be a huge overlap between the two.


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Re: Determining how successful milter-greylist is?

2013-04-09T03:27:37


It's odd that spammers did not yet adapt to nolisting, as it is really
easy to work around. I wonder how long it will work.

Re: Determining how successful milter-greylist is?

Enrico Scholz — 2013-04-08T08:50:30

Thomas Cameron <thomas.cameron-NGNQ62rjTJDc+919tysfdA-XMD5yJDbdMReXY1tMh2IBg< at >public.gmane.org>
writes:


greylisting does (still) a great job.  But nolisting outperforms
its. E.g. in

                   http://ensc.de/rate-year-2008.png

it is easy to see when we enabled nolisting.  For reference, current
statistics looks like

                   http://ensc.de/rate-year-2012.png


Enrico


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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    milter-greylist-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    milter-greylist-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gman

Re: Determining how successful milter-greylist is?

Jim Klimov — 2013-04-08T08:55:35

The greylisting database file (/var/milter-greylist/greylist.db or
somesuch in your system), should contain the current list of addresses
in both grey and auto-white stages. For the tool to be effective, you
should also pick and use a DNS RBL resource to verify that the source
addresses which did pass to auto-whiting are not yet well-known spam
sources.

Then you can see something like this:

# tail /var/milter-greylist/greylist.db
...
# Summary: 4488 records, 4336 greylisted, 152 whitelisted

Here, of 4.5k source hosts over the past few days (3 days or whatever
your limit is) only 150 were not known spam sources and did try twice
and were accepted to next stages in spam-filtering or mail delivery ;)

HTH,
//Jim Klimov



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milt