I am new to CentOS. How do I set a rule to so that any email coming from @ linkedin.com (and other abused locations), going to an application RT (setup on the system), will get rejected or dropped silently.
On Thu, 2011-02-03 at 10:38 -0500, testwreq wreq wrote:
I am new to CentOS. How do I set a rule to so that any email coming from @ linkedin.com (and other abused locations), going to an application RT (setup on the system), will get rejected or dropped silently.
Procmail filters on the receiving account would be the easiest solution.
Make sure that procmail is installed and then man procmailrc for how to configure it.
IIRC for RT ticket submission/modification via email to work you have to be using a mail filter of some sort already and the docs give a basic promail filter for you to use. As such, you should just need to add a few rules ahead of that particular rule to catch the type of mail you don't want.
This of course is just scratching the surface of keeping unwanted mail out of your ticket tracking system ;)
-Andy-
For RT, we have used /etc/aliases and I have sendmail installed. How can I used the existing mail functionality to filter?
On Thu, Feb 3, 2011 at 10:56 AM, Andrew Grimberg tykeal@bardicgrove.orgwrote:
On Thu, 2011-02-03 at 10:38 -0500, testwreq wreq wrote:
I am new to CentOS. How do I set a rule to so that any email coming from
@
linkedin.com (and other abused locations), going to an application RT
(setup
on the system), will get rejected or dropped silently.
Procmail filters on the receiving account would be the easiest solution.
Make sure that procmail is installed and then man procmailrc for how to configure it.
IIRC for RT ticket submission/modification via email to work you have to be using a mail filter of some sort already and the docs give a basic promail filter for you to use. As such, you should just need to add a few rules ahead of that particular rule to catch the type of mail you don't want.
This of course is just scratching the surface of keeping unwanted mail out of your ticket tracking system ;)
-Andy- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
At Thu, 3 Feb 2011 10:38:31 -0500 CentOS mailing list centos@centos.org wrote:
I am new to CentOS. How do I set a rule to so that any email coming from @ linkedin.com (and other abused locations), going to an application RT (setup on the system), will get rejected or dropped silently.
Install spamassassin (yum install spamassassin).
Create a special user account called 'rtspam'. In this account's home directory create a directory .spamassassin, and copy /usr/share/spamassassin/user_prefs.template into this directroy, naming it user_prefs.
Create a file named .procmailrc, that looks something like this:
MAILDIR=/home/rtspam/Mail #you'd better make sure it exists DEFAULT=$ORGMAIL #completely optional LOGFILE=$MAILDIR/from #recommended METAMAIL_TMPDIR=$MAILDIR/Attachments MAILCAPS=$HOME/.mailcap.pr KEYIGNHEADS=Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Content-Disposition:Content-Id
:0fw | /usr/bin/spamassassin -p /home/rtspam/.spamassassin/user_prefs
# catch anything tagged by spamassassin as spam :0: *^X-Spam-Warning: This message may be SPAM.* spam/.
# catch anything with a spam score of 5 or more :0: *^X-Spam-Level: *****.* spam/.
:0 c backup/.
:0 ic | cd /home/rtspam/Mail/backup && rm -f dummy `ls -t * | sed -e 1,32d`
:0 ic | cd /home/rtspam/Mail/spam && rm -f dummy `ls -t * | sed -e 1,200d`
# Special aliases -- will go to RT once it is set up.
:0 * ^TOrt@ |/var/www/rt3/bin/rt-mailgate --queue general --action correspond --url http://rt.deepsoft.com:8080/
:0 * ^TOrt-comment@ |/var/www/rt3/bin/rt-mailgate --queue general --action comment --url http://rt.deepsoft.com:8080/
#Billing and sales
:0 * ^TObilling@ |/var/www/rt3/bin/rt-mailgate --queue sales --action correspond --url http://rt.deepsoft.com:8080/
:0 * ^TOwholesale@ |/var/www/rt3/bin/rt-mailgate --queue sales --action correspond --url http://rt.deepsoft.com:8080/
:0 * ^TOpromos@ |/var/www/rt3/bin/rt-mailgate --queue sales --action correspond --url http://rt.deepsoft.com:8080/
:0 * ^TOsales@ |/var/www/rt3/bin/rt-mailgate --queue sales --action correspond --url http://rt.deepsoft.com:8080/
etc...
End the file with:
:0 * ^FROM_MAILER ! heller@deepsoft.com
:0 * ^From:.*MAILER-DAEMON ! heller@deepsoft.com
:0 |/var/www/rt3/bin/rt-mailgate --queue general --action correspond --url http://rt.deepsoft.com:8080/
(change the ^TO patterns, the path to rt-mailgate, the --queue and --url options, etc. to suit your configuration.)
In your /etc/aliases set up your RT addresses like this:
rt: rtspam rt-comment: rtspam billing: rtspam wholesale: rtspam promos: rtspam sales: rtspam
etc.
(Again change the names to suit your configuration.)
You can then add whitelist_from and blacklist_from addresses to ~rtspam/.spamassassin/user_prefs, as well as any special SpamAssassin rules you need. This is what I use and it works quite well. You will want to check the spam and backup mail folders from time to time to check for false positives (in the spam mail folder) and spam leaks (in the backup mail folder) and adjust things as needed.
Am 03.02.2011 17:33, schrieb Robert Heller:
Create a file named .procmailrc, that looks something like this:
[ ... ]
:0fw | /usr/bin/spamassassin -p /home/rtspam/.spamassassin/user_prefs
It is the worst solution to spawn a new spamassassin process with each mail going through the filter. The consequences depend on the amount of mails transported and the powers of the host, but doing this with a resource hungry and slow process like spamassassin is not recommended in any way.
Alexander
on 21:20 Thu 03 Feb, Alexander Dalloz (ad+lists@uni-x.org) wrote:
Am 03.02.2011 17:33, schrieb Robert Heller:
Create a file named .procmailrc, that looks something like this:
[ ... ]
:0fw | /usr/bin/spamassassin -p /home/rtspam/.spamassassin/user_prefs
It is the worst solution to spawn a new spamassassin process with each mail going through the filter. The consequences depend on the amount of mails transported and the powers of the host, but doing this with a resource hungry and slow process like spamassassin is not recommended in any way.
It'd be helpful to mention the alternative:
1: Run spamassassin in daemon mode.
2: Invoke the spamc client (should be installed with spamassassin though I haven't confirmed for CentOS) in your procmail (or other mail filtering) systems.
If you're running your own MTA locally or remotely, most have hooks which allow for automated spam rejection based on rules or filters as well. Discussion of that is beyond the scope of this list, but texts/documentation for postfix, exim4, smail, and sendmail should all address this adequately.
MTA spam filtering, done at SMTP transaction time, can be _very_ efficient and effective. It also has the added benefit, if done correctly, of indicating to the sender what's happened (e.g.: mail was rejected as spam), which in the case of false-positive rejections may (assuming a clueful user, unfortunately not valid in many instances) be helpful in identifying and correcting such instances.
Please inform yourself about antispam measures. This list is not a forum to find out how you can fight spam. As for simply rejecting certain senders/hosts you use the access db. Google for "sendmail access.db".
Kai
Get a look at this site;
It's easy to install, just a line to change in sendmail.
--- Michel Donais
-
Alexander Dalloz -
Andrew Grimberg -
Dr. Ed Morbius -
Kai Schaetzl -
Michel Donais -
Robert Heller -
testwreq wreq