OpenBSD Journal

Greylisting Suport in spamd

Contributed by jose on from the fun-with-spammers dept.

sevenn writes: 



CVSROOT:	/cvs
Module name:	src
Changes by:	beck@cvs.openbsd.org	2004/02/26 00:28:55

Modified files:
	libexec        : Makefile 
	libexec/spamd  : Makefile sdl.c spamd.8 spamd.c 
	usr.sbin       : Makefile 
Added files:
	libexec/spamd  : grey.c grey.h 
	libexec/spamlogd: Makefile spamlogd.8 spamlogd.c 
	usr.sbin/spamdb: Makefile spamdb.8 spamdb.c 

Log message:
Add -g option for greylisting support for spamd. The greylisting techinque
originates from a paper by Evan Harris which can be found at
http://projects.puremagic.com/greylisting/.
This implementation makes
spamd allow for non-blacklisted addresses to be treated as "greylisted".
where they are tracked in a db file, and whitelisted by addition to a
pf table when the same envelope from and to are retried from the same
source IP address. Testing by many, ok deraadt@

(Comments are closed)

Comments

  1. By Ray () on

    The man page shows this as an example in pf.conf:

    table <spamd> persist
    table <spamd-white> persist
    rdr pass inet proto tcp from <spamd> to any
        port smtp -> 127.0.0.1 port 8025
    rdr pass inet proto tcp from !<spamd-white> to any port smtp
        -> 127.0.0.1 port 8025

    This is redundant—the second rdr line emcompasses the first. Is there a reason for its existence that I don’t see?

    Comments

    1. By SH () on

      Just because an IP is not a member of does not imply that it is member of .

    2. By SH () on

      Urk, bad formatting, try again...

      Just because an IP is not a member of spamd-white does not imply that it is member of spamd.

      Comments

      1. By Anonymous Coward () on

        But every address not member of spamd-white is going to be rdr to the tarpit by the second rule.

        That means that spamd members and all the others are going to be rdr. I think that the second rule engulfs the first... can you please point out where I'm wrong?

        Comments

        1. By Anonymous Coward () on

          first match wins.

          Comments

          1. By Anonymous Coward () on

            Yes, first match wins, but that's not the point, unless searching for entries on spamd is cheaper than searching on spamd-white.
            If you'd live only the second rule, all trafic matching ! would be redirected to the tarpit, and that includes spamd (spamd-black, if you will)

          2. By Anonymous Coward () on

            Yes, first match wins, but that's not the point, unless searching for entries on spamd is
            cheaper than searching on spamd-white.

            If you'd leave only the second rule, all trafic matching !spamd-white would be redirected to the tarpit, and
            that includes spamd (spamd-black, if you will)

            Comments

            1. By Anonymous Coward () on

              I too was confused until I read the link--and I'm still not totally clear. Follow on to read about greylisting. Anyone we haven't yet seen is sent a temporary reject -- most spammers/viruses tend not to resend after a 4xx, according to the greylist author.

              If the triplet (see terms in said link) resends, then there is apparently a need to use relaydb to whitelist the sender. Thus, every mail is initially sent to the trap, and subsequently whitelisted if they resend after the 4xx. Not ideal, but good that it's supported!

    3. By Brian () on

      is a table of blacklisted addresses (spamhaus/china/korea/whatever).

      is a table of whitelisted addresses, addresses that were once greylisted.

    4. By Anonymous Coward () on

      Shouldn't the first rdr be redirecting to 8025 with spamd running normally on that port, and then the second redirect going to port 8125 or something? And have spamd running in greylist mode on that port?

      Comments

      1. By Petr R. () pruzicka@openbsd.cz on mailto:pruzicka@openbsd.cz

        Aparently spamd somehow recognize that IP address in is in blacklist (ie. spamd table) and everything else is greylist. So there is only one spamd running.
        (GREY) x.x.x.x: ->
        Got Grey IP x.x.x.x from to
        updated x.x.x.x


        x.x.x.x connected for 0 seconds

  2. By Petr R. () pruzicka@openbsd.cz on mailto:pruzicka@openbsd.cz

    I enabled it on one mail relay few minutes ago. I have very good results already (postfix+spamd+amavis-new+spamassasin), so we will see how this approach could help.

  3. By Daniel () on

    I'm not sure whether I have understood the mentioned paper fully, but spammer could configure his spamming engine to just retry with the same triplet in 1.5 h, and the spam will get through. Then greylisting admin would increase the time between retries to 2 h, so spammer would increase to 2.5 h. Greylisting user will increase to 4 h, and there it gets to the point, where mail users will consider the delay as not acceptable anymore, because, when I'm at work, and I phone someone at 14:00, and tell him, to send me this or that document via Email, I want it to arrive before I go home at 17:00. Not sure, however, if I have fully understood spamming and greylisting, so if this is likely not to happen, someone please enlighten me.

    Comments

    1. By Petr R. () pruzicka@openbsd.cz on mailto:pruzicka@openbsd.cz

      Well, basicaly I think that it will help against automated tools that just try to deliver spam and they do not care if it will work. So they just 'fire and forget', for speed and efficiency.
      In case of legitimate mail server on the other site, it won't help as this server will try to deliver it again.

  4. By Anonymous Coward () on

    will it be possible for the spam engine to just try delivering two copies of every e-mail? If it did then the second would have the same source and destination pair as the first.

    Comments

    1. By Janne Johansson () on

      The second mail needs to wait for 30 minutes before it can be delivered.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]