View Full Version : Reject Spam?
herbie
8th November 2006, 20:26
I'm running the Perfect Setup Postfix, Courier, etc Sarge verson. A bunch of users are snivelling that its just too hard to set their e-mail program to toss out messages marked ***SPAM*** and insisting I look into configuring the server to toss out messages marked as spam for them.
Is there a way to do this, and can it be done without quarantining it so it eats up the server's hard drive over time? As the bulk of spams are from fake senders, bouncing it also seems like a waste.
sjau
9th November 2006, 00:03
You could create a .procmailrc file for each user that wants all emails marked as spam to forward to /dev/null (deleting...)
The content of the .procmailrc file should be like:
:0:
* ^X-Spam-Flag: Yes
/dev/null
Put this into a .procmailrc file in the homedire of the user e.g. /home/Maildir/USER/.procmailrc
herbie
9th November 2006, 00:23
I'm using virtual domains so the structure is /home/vmail/domain/user and no Maildir, would a .procmailrc work?
I was more interested in a server-wide setting that would just maybe send all spam-marked mail for all users away.
EDIT: so I tried adding the .procmailrc file into the user directory, chown'd to vmail:vmail and it doesn't work. Shoot!
till
9th November 2006, 11:02
The perfect setups use system users and not virtual users, thats why sjau recommended a .procmailrc solution. I guess you used the virtual postfix setup howto? Then you may e.g. use the amavisd configuration file to forward the spam mails to /dev/null.
herbie
9th November 2006, 20:24
I think so. I'm trying to decode the amavis.conf to figure out how it works.
$final_virus_destiny = D_REJECT; # (defaults to D_BOUNCE)
$final_banned_destiny = D_REJECT; # (defaults to D_BOUNCE)
$final_spam_destiny = D_PASS; # (defaults to D_REJECT)
$final_bad_header_destiny = D_PASS; # (defaults to D_PASS), D_BOUNCE suggested
I will try changing $final_spam_destiny = D_PASS; # (defaults to D_REJECT) to $final_spam_destiny = D_REJECT; # (defaults to D_REJECT) and see what happens.
The per user solution or direction to a spam folder would have been a nice option.
falko
10th November 2006, 17:41
This tutorial might be interesting for you: http://www.howtoforge.com/postfix_mailfilter
herbie
10th November 2006, 20:36
The test I did above was very effective on a server-wide basis, the two working e-mail I had on it normally get about 200 spams per day (domain and users in use over 10 years now). One had 4 spams, one had 3 overnight that made it past spamassassin.
I'm going to try the tutorial over the weekend and I'm presuming that the user's filter is saved as user@domain.com in /home/vmail/.mailfilter and that the
{
log "------------------------------------------------------------- Spam general. "
to "/home/vmail/example.com/user/.spam" # Make this "cc" for copy or "to" to not send it to Inbox.
}
else
{
to "/home/vmail/example.com/user/."
}
to
f ( /^Subject: SPAM/)
{
log "------------------------------------------------------------- Spam general. "
to "/dev/null" # Make this "cc" for copy or "to" to not send it to Inbox.
}
else
{
to "/home/vmail/example.com/user/."
}
It will offer a user choice of a spam box to check or discarding it altogether, and if the mailfilter-log.txt is an empty file, the spam will simply be marked as spam and delivered with the rest?
herbie
10th November 2006, 22:59
in the process of undoing/redoing it killed the mailserver. Only thing I can find was a mail.err entry:
Nov 10 12:10:54 picard postfix/master[4233]: fatal: /etc/postfix/master.cf: line 112: bad transport type: user=vmail
I presumed as it is in /vmail I needed to chown vmail:vmail -R .maildir?
falko
11th November 2006, 18:25
What's in /etc/postfix/master.cf?
herbie
11th November 2006, 21:01
relevant lines 110-143, 112 is #'d out at the moment
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
# flags=DRhu user=vmail argv=/usr/local/maildrop/bin/maildrop -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${nexthop} ${sender}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
I'm also curious as to this log entry. I set the maildrop up on a domain with a single user, then set a forwarding from an account that gets a lot of spam to it:
Nov 11 11:38:19 picard postfix/pipe[30554]: 0F83BBF4015: to=<test@beyondhope.ca>, orig_to=<rickm@qlynx.com>, relay=maildrop, delay=1, status=bounced (Command died with status 1: "/usr/local/bin/maildrop")
Where does the forwarding feature call maildrop? The only maildrop related line in postfix/master.cf is #'d out.
falko
12th November 2006, 17:08
relevant lines 110-143, 112 is #'d out at the moment
Can you post that part again and put it between and mark it as CODE instead of QUOTE here? Because I need to see the whitespace in your configuration...
herbie
12th November 2006, 21:46
here you go:
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
# flags=DRhu user=vmail argv=/usr/local/maildrop/bin/maildrop -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${nexthop} ${sender}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
falko
13th November 2006, 17:19
What's the output of grep vmail /etc/passwd?
herbie
13th November 2006, 19:59
vmail:x:5000:5000::/home/vmail:
also:
all references in maildroprcare to /u0/vmail/.mailfilters/$LOGNAME
but /u0/vmail/.mailfilter/user@domain.com (without the 's') is listed as location of mailfilter. mv'd .mailfilter to .mailfilters, chmod -R 700 and trying again
herbie
16th November 2006, 07:30
Has anyone got this setup working? All my logs say maildrop is working (once I entered the /home/vmail/domain/user into the SQL field, but the two accounts with a script in the /home/vmail/.mailfilters are sending the spam to an account that one of them forwarded to even after the forward was removed.
Server's been rebooted, so all services restarted.
Nov 15 18:29:28 picard amavis[7492]: (07492-04) Passed, <deboraprodec@c4systems.com> -> <rickm@xxxxx.com>, quarantine spam-448e8179675dcb32e821feb323937496-20061115-182928-07492-04, Message-ID: <01c70927$09d70710$6c822ecf@deboraprodec>, Hits: 9.646
Nov 15 18:29:28 picard postfix/smtp[8104]: 7E4E2BF4009: to=<rickm@xxxx.com>, relay=127.0.0.1[127.0.0.1], delay=1, status=sent (250 2.6.0 Ok, id=07492-04, from MTA: 250 Ok: queued as 56150BF400A)
Nov 15 18:29:28 picard postfix/pipe[8110]: 56150BF400A: to=<rickm@xxxxx.com>, relay=maildrop, delay=0, status=sent (xxxxx.com)
this is one mail relayed to a user a day after I removed the forward
herbie
17th November 2006, 00:08
Without being facetious, I'd like to state the lack of responses to my post has been a big help. I mean I actually was forced to doublecheck my work and learn how this thing works.
It seems problems were my own (doh!!!) and the relay problem was due to my own inattention to detail.
a) the user@domain.com mailfilter was cp of the original, therefore maildrop was correctly sending all mail to the original user@domain. My doh!
b) it appears that (as I discovered in a post I can't relocate) /home/vmail/user/domain must be entered in the maildir field of your SQL user table. I'm not sure, but everything started to work once I did this, so I won't remove it and try again at the moment.
c) one minor detail is in the example mailfilter:
if ( /^Subject: SPAM/)
should read
if ( /^Subject: ***SPAM/)
to comply with the default ***SPAM*** subject marking from the amavisd setup.
Here's the mailfilter log example of the successful setup
------------------------------------------------------------- Spam general.
Date: Thu Nov 16 13:26:20 2006
From: "Levi Quinn" <Gustavowzredactor@goldenacorncasino.com>
Subj: ***SPAM*** Re: Hey
File: /home/vmail/xxxxx.com/userx/.spam (31225)
The logfile was what clued me into the original problem, it told me the user_mailfilter was being used by the maildrop relay.
So I can now test if I can redirect spam to /dev/null by altering the user_mailfilter's redirect. It should work.
A future project may be to see if you can pass variables to the user_mailfilter (ie: /home/vmail/$DOMAIN/$USER/.spam) so lazy bastards like me can write a dummyfile and just "cp save_spam user@domain.com" AFTER they get it working instead of BEFORE like I did.
Thank you, I actually I learned something. Pointing out 'look here' rather than 'here's the fix' made me. Once I am satisfied everything is copasetic, I will # out the write to athe logfile.
falko
17th November 2006, 15:11
Without being facetious, I'd like to state the lack of responses to my post has been a big help.
That's good, because I had no idea what could be wrong (so I read your posts, but didn't know what to answer...).
herbie
18th November 2006, 03:19
Haha! But thank you for a great series of tutorials. BTW the sending spam to /dev/null works well, and the user_mailfilter can relay to another account on the server. So if someone pisses you off you could direct all the spam from all of the users on all of the domains to his account....buah hah hah....
Here's one you may be able to figure out:
I have another postfix-courier-amavis-sarge server running in the rack. You can send from the new server's maildrop-enabled accounts to accounts on it with Squirrelmail. SquirrelMail sent from it to maildrop-enabled accounts simply disappears. Goes to domains without the maildrop transport, but not with.
I can see the messages go out on the one server, but they don't even show up in the logs of the new server if they're addressed to a maildrop-enabled domain.
????
falko
18th November 2006, 16:41
Here's one you may be able to figure out:
I have another postfix-courier-amavis-sarge server running in the rack. You can send from the new server's maildrop-enabled accounts to accounts on it with Squirrelmail. SquirrelMail sent from it to maildrop-enabled accounts simply disappears. Goes to domains without the maildrop transport, but not with.
I can see the messages go out on the one server, but they don't even show up in the logs of the new server if they're addressed to a maildrop-enabled domain.
????
Are the MX records of the domains pointing to your server?
herbie
18th November 2006, 22:23
The MX records are correct. Mail from outside is unaffected. All our servers use the same DNS server.
Mail to a domain without maildrop in the transport table is delivered successfully.
ALSO: the maildrop enabled domain is sending Quota notices.
falko
19th November 2006, 18:54
Is it maybe a Maildir vs. mbox problem, i.e. maildrop delivers to the wrong location/format?
herbie
19th November 2006, 20:58
Once again, my dooooohhhhhhhh!!!!!!!
The domain I'm using to test the setup used to be on the other box. I (doh!) forgot to mark-out the domain in the domain table of the original box (usually I just change domain name from domain.tld to xdomain.tld) so of course the DNS didn't matter, it was finding the domain in the virtusertable and sending it to the account still listed on the original server!
I found this when I made a new account on the maildrop box and tried to send something from the other. Error 550 user not listed in virtuser table. Where does it get virtusertable? Easy one.
Tell you what I have: TWO servers with half the domains on one half on the other, and every night they send the SQL structure to the other. If one dies you load the other's structure repoint the DNS in zone and everyone works on a single server until the other's fixed. When it is, you load the structure from the other and X out the domains in the domain table for the ones it's not going to serve, and repoint the DNS.
All that gets lost is mail on the dead server, and /home/vmail is too big to send back and forth regularly.
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.