Topic: activating greylisting

[raem]

bjoyce

Search

http://forums.contribs.org/index.php?topic=34498.0

You could try white-listing the sending email host. This will selectively change the behavior of some of the subsequent qpsmtpd plugins, and might get your messages through...

To add a white-listed host:
config setprop qpsmtpd RequireResolvableFromHost yes
pico /var/service/qpsmtpd/config/whitelisthosts
(add the IP addresses you want to whitelist, one per line)
signal-event email-update

(Turning on "RequireResolvableFromHost enables the "whitelist_soft" plugin. Also, there's no default template for "whitelisthosts" so your changes shouldn't disappear by themselves. Ultimately, this should probably be templated and should use the configuration database...)

[raem]

bjoyce

Read this file

/usr/share/qpsmtpd/plugins/greylisting

[william_syd]

http://projects.puremagic.com/greylisting/

http://www.hjp.at/projekte/qpsmtpd/denysoft_greylist/

In particular this bit..

The version on this page contains two improvements over the version it is based on:

    * There is a whitelisting mechanism for IP addresses. Gavin has since added a similar, but not identical mechanism (his "whitelist_soft" module). Whitelist_soft is a generic whitelisting solution which affects all modules which check for the notes it adds. My mechanism is specific to this module (so you can exempt a server from greylist checking, but still subject it to other checks.
    * A new option per_recipient has been added. If it is used, greylisting is enabled only for recipients which want it. Again, whitelist_soft offers similar functionality, but on a global basis.

[bjoyce]

Thanks for all these comments, I am going to persist with greylisting despite the shortfalls becuase it does reduce the SPAM to all but 0 and email is still coming through in similar volume,  See this graph.


Staff at the school have been made aware of the possible denial of incoming mail and agree that the reduction is spam is worth it.

I will investigate the whitelisting further.

Regards brad

[mmccarn]

Blackout Time

Agreed, how about the intial delay, first post? Bringing it down fro soem 36 min as repported in this thread to say 5 minutes?

The initial time is specified in the very first post in this thread.  The "black_timeout 60" part of the custom template fragment tells your server to reject it for 60 seconds - if you're seeing a 36 minute delay it's due to the sending server and there's nothing you can do.

White List
The greylisting plugin *does* pay attention to "whitelisthosts" but does *not* pay attention to the spamassassin white lists, as far as I can tell from /usr/share/qpsmtpd/plugins/greylisting.  You may be able to seed your greylisting database by specifying "mode testonly" in the custom template fragment, like this:
echo greylisting black_timeout 60 mode testonly > /etc/e-smith/templates-custom/var/service/qpsmtpd/config/plugins/09greylisting

[hanscees]

I would certainly like to setup greylisting. But only when one can whitelist ip-adress-email tuples or ip-adresses.
Better yet, domains, because some providers have many different smtp servers active.

If you cannot whitelist, greylisting eats up some good email, and I dont want that.


Hans-Cees

[duncan]

It seems that the 7.1 update changes the way the plugins are handled. The above greylisting method needs to be modified to suit.

[jahlewis]

I see that in 7.1 things have changed somewhat.

in 7.1 /var/service/qpsmtpd/config/plugins is no longer being used, but

/var/service/qpsmtpd/config/peers/ has two files which load the plugins in /usr/share/qpsmtpd/plugins

what is the best way to enable the greylisting plugin in 7.1 for the /var/service/qpsmtpd/config/peers/0 file?

db configuration show qpsmtpd doesn't seem to be the right place, and I've now pushed my knowledge of db far enough.  I'd rather do it the right way than create a custom template of the above 0 file to add greylisting.

Thanks.

[gordonr]

I see that in 7.1 things have changed somewhat.

http://bugs.contribs.org/show_bug.cgi?id=1893

what is the best way to enable the greylisting plugin in 7.1 for the /var/service/qpsmtpd/config/peers/0 file?

As you may know, I'm not a fan of greylisting:

http://lists.contribs.org/mailman/public/devinfo/msg08292.html
http://lists.contribs.org/mailman/public/devinfo/msg06819.html

However, to make a change to the "non-local" connection definition (which is what the peers/0 file is), create the directory /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/ and put your fragment there.

db configuration show qpsmtpd doesn't seem to be the right place, and I've now pushed my knowledge of db far enough.  I'd rather do it the right way than create a custom template of the above 0 file to add greylisting.

You don't want a file custom-template, but you do want a directory custom template. Make sure you read the developer's guide section on directory templates and custom templates. I think it's clear It's over here:

http://wiki.contribs.org/development/

[jahlewis]

Thanks Gordon, so here's the modified instructions that I used to enable greylisting. (I agree with your concerns, but enabling it significantly reduces my spam, and for me it is worth it the risk of missing something)

Code: [Select]

# enable greylisting
mkdir -p /usr/bin/config
chmod 777 /usr/bin/config
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0
echo greylisting black_timeout 60 >  /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/09greylisting
/sbin/e-smith/expand-template /var/service/qpsmtpd/config/peers/0

Could someone explain the purpose of the necessity for full access to /usr/bin/config?  Surely it can be locked down somewhat?  To root? What user/group does qpsmtpd run as?

[gordonr]

Could someone explain the purpose of the necessity for full access to /usr/bin/config?

I didn't even look at that. It's certainly wrong. Nobody but root should be allowed to write to anything in /usr/bin. And any instruction which says "chmod 0777" is almost certainly wrong.

 Surely it can be locked down somewhat?  To root?

If a temporary directory is required it should be something like /var/state/qpsmtpd/greylist, which should be qpsmtpd:qpsmtpd

What user/group does qpsmtpd run as?

qpsmtpd:qpsmtpd

[jahlewis]

Here's what I see in /usr/bin/config (This date is just before I upgraded to 7.1):

Code: [Select]

[root@gluon var]# ll /usr/bin/config
total 1580
-rw-------  1 qpsmtpd qpsmtpd 2519040 Jan  2 22:13 denysoft_greylist.dbm
-rw-------  1 qpsmtpd qpsmtpd 0 Jan  2 22:13 denysoft_greylist.dbm.lock

So I changed ownership of the directory to qpsmtpd:qpsmtpd (and removed the lock file...)

I agree it is unusual, hence the question. I'm not geeky enough to interpret /usr/share/qpsmtpd/plugins/greylisting to determine where it stores its dbm files.

-JL

[william_syd]

Code: [Select]

# enable greylisting

mkdir -p /usr/bin/config
chown qpsmtpd:qpsmtpd /usr/bin/config
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/plugins/
echo greylisting black_timeout 60 > /etc/e-smith/templates-custom/var/service/qpsmtpd/config/plugins/09greylisting
/sbin/e-smith/expand-template /var/service/qpsmtpd/config/plugins
The above is what I had in 7.0

Below is what I added for 7.1 (in addition to the above)

Code: [Select]

mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0
ln -s /etc/e-smith/templates-custom/var/service/qpsmtpd/config/plugins/09greylisting /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/09greylisting
/sbin/e-smith/expand-template /var/service/qpsmtpd/config/peers/0
signal-event email-update

Appears to work.

[mark]

Hi

I live in New Zealand

99% of spam my clients recieve comes from non nz addresses and about 5% of legitimate email comes from non nz addresses. Can anyone think of how I could limit the calling to the greylisting module to only when an email has a non nz address. In other words: if not address contains *.nz then greylist?

thanks



Mark Signal

[mark]

I activated greylisting as the last activity in peers/0 and activated whitelist_soft immediately before it. I then added *.nz to /var/service/qpsmtpd/config/whitelistsenders.

greylisting is now working but not ignoring email addresses ending in .nz as I would have expected

do I need to tell greylisting to use the results of the whitelist_soft check or should the fact that it appears after whitelist_soft in the peers/0 file be enough?

cheers


Mark Signal