DSpam and Postfix
Hi, I really hope there is a solution. I have been using postfix and dspam. However, /var became full. After looking into the problem, I found that /var/dspam/data was where all the disk space was being used. After deleting /var/dspam/data /var was almost empty. Well, I then created /var/dspam/data directory and did a new corpus training. However, dspam will only run for a few minutes at a time. Not really sure what the issue is. At this point, I just want to remove dspam from my config. However, postfix seems to have a large number of messages in its cache that it still wants to send to dspam. F26F6B7CC1 5822 Tue Oct 27 09:01:57 (delivery temporarily suspended: lost connection with [/var/dspam/ dspam.sock] while sending end of data -- message may be sent more than once) Some of these messages I need. Is there a way to get them out of postfix, or will I need to somehow fix dspam? Kind Regards, Al
Re: DSpam and Postfix
On Oct 28, 2015, at 9:58 AM, Noel Jones wrote: On 10/28/2015 6:41 AM, Al Zick wrote: Hi, I really hope there is a solution. I have been using postfix and dspam. However, /var became full. After looking into the problem, I found that /var/dspam/data was where all the disk space was being used. After deleting /var/dspam/data /var was almost empty. Well, I then created /var/dspam/data directory and did a new corpus training. However, dspam will only run for a few minutes at a time. Not really sure what the issue is. At this point, I just want to remove dspam from my config. However, postfix seems to have a large number of messages in its cache that it still wants to send to dspam. F26F6B7CC1 5822 Tue Oct 27 09:01:57 (delivery temporarily suspended: lost connection with [/var/dspam/dspam.sock] while sending end of data -- message may be sent more than once) Some of these messages I need. Is there a way to get them out of postfix, or will I need to somehow fix dspam? Kind Regards, Al After you remove dspam from the postfix config, requeue all the messages with "postsuper -r ALL" Hi, That did it, it is no longer using dspam. Kind Regards, Al
OT: webmail clients
Hi, I really hope that someone can help me on this list. I spent hours googling and hours installing webmail clients. Still, I was not able to find one that I like. The only one that I could get working was squirrel mail. They all seem to have too long of a list of dependencies, but I was not able to make it work with multiple domains. Does anyone know of a webmail client that is written in PHP, lightweight, authentication is done with pop3, supports html emails, and supports mysql? Kind Regards, Al
Re: postfix dspam intergration
Hi, On Jun 11, 2015, at 4:49 PM, Noel Jones wrote: On 6/11/2015 3:13 PM, Al Zick wrote: ... I don't know anything about dspam, but I have some comments on your postfix configuration. If I integrate it into my postfix's master.cf, dspam doesn't crash anymore, but I have greater problems. Here is my master.cf: # SMTP no filter 127.0.0.1:25 inet n - n - - smtpd 10.20.238.4:25 inet n - n - - smtpd # SMTP with filter smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/dspam/dspam.sock # Post Dspam filter 127.0.0.1:2424 inet n - - - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_c hecks -o smtpd_helo_restrictions= -o smtpd_client_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 The above looks reasonable, assuming you can configure dspam to pass mail back to postfix via SMTP port 2424. You should add -o syslog_name=postfix/dspam-out to the port 2424 listener to differentiate it in the logs. I added -o syslog_name=postfix/dspam-out to my config. This helped! With this integration, very quickly the server becomes 0% idle with a high load average. I am not sure if this is because it is bouncing the emails and then the spammers send them right back, or if the emails are being deferred. The logs will tell you what postfix is doing, no need to guess. Well, I have never seen the log look like this before. The log had a very large group of deferred emails. Then a very large group of emails that were being sent to dspam. I could not make any sense of it. My guess is that you're looping dspam output back to the wrong postfix listener and it gets filtered again and again, eventually triggering too many hops and bounce the mail to the sender. Yes, you were right. It was looping dspam output back to the wrong postfix IP/port. The only way that I could find to fix this was to change inet_interfacees = all I changed this to only use the IP addresses that are necessary and the problem went away. My guess is that dspam tries its default IP on port 25 first. It must be somewhere in 127.0.0.0/8. There are a lot of deferred emails in the log. The log shows why they are deferred, and the unreachable destination. Both valuable clues. Read your logs carefully. Well, my log is back to normal now. It must reject about 90% of the emails for one reason or another. Still, almost all the emails I get are spam. Next, it seems to save all the spam and reject all the real emails. This supports my guess that spam was detected, and good mail looped until it melted. At this point, you convinced me that it looped until there were too many hops. Also, I am still not sure what happened to all the emails. Were they were bounced, or just lost somewhere? The logs will show where mail went. It really looks like they eventually bounced. And procmail doesn't seem to know who to deliver the emails to if they are passed to it from dspam. I am getting errors in my maillog from procmail saying user unknown. Is this good mail or spam mail? Is it really the wrong username? Dspam takes what ever is before the @ in the email address and then passes that off as the user to procmail. Anyway, seems to me dspam should be sending all mail back to postfix for delivery, not trying to pass mail to procmail. It took me a while to get this working properly too. Kind Regards, Al
postfix dspam intergration
Hi,
I really hope that someone can help me.
I know that some of this may be off topic for this list, but some of
this has to directly deal with my postfix master.cf.
The goal is to provide the same filtering for everyone who receives
email on this system.
I have a mail server that is a relay for several other servers. It
needs to do this job regardless. It is also receives emails for about
30 domains. Anyway, we are having really bad spam issues and I need
to get this problem solved. So far I have tried to integrate dspam
into procmailrc. This only halfway works at best. My procmailrc looks
like this:
# dspam filtering:
:0fw
| /usr/local/bin/dspam --mode=toe --process --stdout --
deliver=spam,innocent --username spam --client
# kick out spam
:0
* ^X-DSPAM-Result: Spam
{
:0
* ^X-DSPAM-Confidence: 0\.(9|8[5-9])
/dev/null
:0
/var/mail/spam
}
However, retraining doesn't work at all with hash and toe. If I
switch to tum, then retraining works, but dspam crashes after about
12 hours because its css file has become corrupted. If using dspam-
retrain-forward.pl, then the dspam daemon crashes.
What it looks like is that dspam can not switch to the correct user
while processing email. I am not sure if there is away to tell
procmail to pass it off to dspam as a trusted user. If use --user to
pass it off as a user then dspam complains because it can not switch
that user because the user is untrusted. I would think that procmail
would pass it off as root, but it doesn't. It looks like it is
passing it off as the system user it should be delivered to. Is there
a solution to this user issue?
If I integrate it into my postfix's master.cf, dspam doesn't crash
anymore, but I have greater problems.
Here is my master.cf:
# SMTP no filter
127.0.0.1:25 inet n - n - - smtpd
10.20.238.4:25 inet n - n - - smtpd
# SMTP with filter
smtp inet n - n - - smtpd
-o content_filter=lmtp:unix:/var/dspam/dspam.sock
# Post Dspam filter
127.0.0.1:2424 inet n - - - - smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_chec
ks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
# Dspam retaining transport
dspam-retrain unix - n n - - pipe flags=XRu user=dspam argv=/usr/
local/bin/dspam-retrain-forward.pl
--debug=no
--client
--user spam
--class=${nexthop}
--source=error
--full=yes
--headers-only=no
--bodies-only=yes
--first-only=no
--skip-first=no
--bin-dir=/usr/local/bin
With this integration, very quickly the server becomes 0% idle with a
high load average. I am not sure if this is because it is bouncing
the emails and then the spammers send them right back, or if the
emails are being deferred. There are a lot of deferred emails in the
log. Next, it seems to save all the spam and reject all the real
emails. Also, I am still not sure what happened to all the emails.
Were they were bounced, or just lost somewhere? And procmail doesn't
seem to know who to deliver the emails to if they are passed to it
from dspam. I am getting errors in my maillog from procmail saying
user unknown. Ideally, postfix would pass all emails to dspam after
postfix did it's checks as the system user spam, so that everyone
would have the same filtering. Then, dspam would pass the spam to
procmail for sorting and pass all the ham back to postfix for delivery.
I really don't know what I have wrong.
Any help will be greatly appreciated!
Kind Regards,
Al
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Jun 18, 2013, at 12:19 PM, Steve Jenkins wrote: On Tue, Jun 18, 2013 at 9:07 AM, Steve Jenkins wrote: On Tue, Jun 18, 2013 at 9:00 AM, Rod K wrote: If the local postfix instance isn't handling anything else (or even if it is) the easiest solution would probably be to configure it to relay everything through Comcast's SMTP server. You're absolutely right, Rod. I was so focused on figuring out a way AROUND Comcast, that I never considered going THROUGH them. I'm setting up smtp_sasl_password_maps right now. :) Thanks again, Rod! Your advice was spot on: Jun 18 09:16:35 mugello postfix/smtp[25918]: EE44B5301F0: to=...@gmail.com, relay=smtp.comcast.net[76.96.40.155]:587, delay=1.3, delays=0.14/0.03/0.38/0.77, dsn=2.0.0, status=sent (250 2.0.0 psGa1l00H0lc5WA8dsGai2 mail accepted for delivery) A good reminder that we often try to over-complicate things, and that the simplest answer is often the best. :) Does anyone know if Comcast will let you relay emails through there mail server that do not have a comcast email address? Thanks, Al
error when using procmail to forward message
Hello, I setup procmail. I have a system wide config: LOGFILE=/var/log/procmail.log VERBOSE=on :0B: * (://[A-Za-z0-9.-]+\.ru) /dev/null :0: * ^Subject: (Rolex) /dev/null :0 * ^Subject: (anoncvs) ! m...@server1.com some...@server2.com I checked the log and it is putting spam in /dev/null, but there are errors in procmail.log when ever it tries to forward the emails: sendmail: warning: the Postfix sendmail command has set-uid root file permissions sendmail: warning: or the command is run from a set-uid root process sendmail: warning: the Postfix sendmail command must be installed without set-uid root file permissions Is there a way to fix this? Best Regards, Al
Re: error when using procmail to forward message
On Aug 7, 2012, at 1:18 PM, Ansgar Wiechers wrote: On 2012-08-07 Al Zick wrote: I setup procmail. I have a system wide config: LOGFILE=/var/log/procmail.log VERBOSE=on :0B: * (://[A-Za-z0-9.-]+\.ru) /dev/null :0: * ^Subject: (Rolex) /dev/null :0 * ^Subject: (anoncvs) ! m...@server1.com some...@server2.com I checked the log and it is putting spam in /dev/null, but there are errors in procmail.log when ever it tries to forward the emails: sendmail: warning: the Postfix sendmail command has set-uid root file permissions sendmail: warning: or the command is run from a set-uid root process sendmail: warning: the Postfix sendmail command must be installed without set-uid root file permissions These are warnings, not errors. You are correct! Is there a way to fix this? chmod u-s /usr/sbin/sendmail # ll /usr/sbin/sendmail lrwxr-xr-x 1 root wheel 21 May 12 20:33 /usr/sbin/sendmail - /usr/ sbin/mailwrapper # ll /usr/sbin/mailwrapper -rwxr-sr-t 1 root wheel 7839 May 12 20:33 /usr/sbin/mailwrapper Do I want to change permissions on /usr/sbin/mailwrapper? Best Regards, Al
Re: spam issues
Hi, On Jan 13, 2012, at 5:52 PM, /dev/rob0 wrote: On Friday 13 January 2012 16:57:21 Al Zick wrote: On Jan 12, 2012, at 3:57 AM, Egoitz Aurrekoetxea Aurre wrote: Apart from this if you use some trustable RBL, perhaps ^ greylisting and you update Spamassassin rules regularly... you should be pretty fine.. I am not using spamassassin, or greylisting, and I just removed the RBL's because of waay too many false positives. This is absurd. It surely means you chose some overly-aggressive (not trustable) DNSBLs. To say that all DNSBLs cause loss of mail is ridiculous. Why didn't you even consider it worth mentioning what lists you were using I am not trying to start a flame war with anyone. Obviously you understand what effective spam filtering should look like. Here is where I am at: I had about 10 of RBLs at one time (including some of the ones you mentioned), but I slowly removed them. What do you do when people that you need to be in contact with everyday are being blocked? I guess that you can use them if you don't mind having an ever growing whitelist. Can they they be weighted somehow? Thanks, Al
Re: spam issues
Hi, On Jan 12, 2012, at 3:57 AM, Egoitz Aurrekoetxea Aurre wrote: On Thu, 12 Jan 2012, Stan Hoeppner wrote: On 1/11/2012 11:15 PM, Al Zick wrote: Hi, For a while we ran Qmail. Qmail would accept all emails regardless, creating a very serious backscatter problem. Of course, switching to Postfix with it configured to only accept emails for our recipients fixed this problem. Qmail can be properly patched for checking a valid rcpt list in a cdb database avoiding this problem. Just as a detail... and yes without breaking smtp-auth. This is something that I didn't know. Maybe I will take a look at the patch, although I am pretty happy with Postfix. Still we seem to be losing the war with spam. I whitelisted any server that has a .forward set to mine. Any email from a server that is whitelisted gets delivered. This is unacceptable, so I started using procmail with some rules so that email from servers that are whitelisted just get delivered without any filtering. Could someone recommend some low resource way of rejecting more spam. I am considering policyd. http://www.postfix.org/docs.html See section UCE/Virus This page is very helpful! I suppose there's no the situation... but if you have a mail scanning machine in front of a mailbox storage machine (where mailboxes are) and the mailbox machine has an smtpd instance accesible from the Internet it should not be accepting unathenticated mail not comming from the mail scanning machine. If I don't whitelist these servers, then if it bounces an email that has been sent because of a .forward, then the server with the .forward tries to redeliver the email for something like 5 days to my server. Is there another solution to this? I don't have control over the other servers that are whitelisted. Apart from this if you use some trustable RBL, perhaps greylisting and you update Spamassassin rules regularly... you should be pretty fine.. I am not using spamassassin, or greylisting, and I just removed the RBL's because of waay too many false positives. Right now most of my filtering is being done with a set of rules for procmail and with bogofilter, although I am considering using policyd and dovecot with sieve plugin. Policyd (or graylisting) should mean more email is rejected (like it should be) and a filtering during dovecot should mean that whitelisted servers still get their email filtered. I would imagine there is a better way, I just don't know it. However, I am open to suggestions. Thanks, Al -- Stan
spam issues
Hi, For a while we ran Qmail. Qmail would accept all emails regardless, creating a very serious backscatter problem. Of course, switching to Postfix with it configured to only accept emails for our recipients fixed this problem. Still we seem to be losing the war with spam. I whitelisted any server that has a .forward set to mine. Any email from a server that is whitelisted gets delivered. This is unacceptable, so I started using procmail with some rules so that email from servers that are whitelisted just get delivered without any filtering. Could someone recommend some low resource way of rejecting more spam. I am considering policyd. I recently setup dovcot to replace uw-imap. It seems to work fine when I am telneting from localhost, but even though it lets me log in from another system, it will not allow me to download the mail. I can't figure out why, does anyone have any ideas? Thanks, Al
[no subject]
I know I don't have a back scater problem.
getting emails into inbox
Hi, We have been using the same mail server for a long time with the same IP. It relays the email for several webservers and of course all of our email. Yet, lately (maybe the last month or so) I have been getting a lot of complaints about their emails not being delivered and sending the same email via yahoo it gets through. I have been considering sending the email to google for relay, but is this even an option? Do we need to implement outgoing spam filtering? Thanks, Al
Re: postfix doubling emails and spam!
Hi, On Oct 27, 2010, at 11:50 PM, Noel Jones wrote: On 10/27/2010 7:02 PM, Al Zick wrote: Is there a replacement for procmail? I know it seemed to take longer and did raise cpu usage, but when I first installed it with bogofilter, it almost eliminated spam getting into my inbox. depends on why you're using procmail... If you need a way to interface spam/virus filtering, amavisd-new + spamassassin + clamav + sanesecurity clam signatures are a popular and effective combination, although SpamAssassin can use quite a bit of resources. Currently, I just use procmail to interface with the spam filters. I would really like to put a bunch of rules into procmail too, for example: if is sees the word viagra anywhere in the email, it is spam, there is no reason to go any further with it. Right now, I am concerned that I would need a quad core, quad processor system that was dedicated to just running spamassassin, so I am looking at other solutions. problems lately have been with email. I feel like I need to get postfix to stop using so much cpu. Show some evidence. Postfix shouldn't use very much CPU. per second hitting the mail server just to be temporarily bounced by the graylisting when in the end they get bounced anyway. Even after they are bounced, they just keep coming anyway. Most greylist services use DEFER_IF_PERMIT so that mail that can be permanently rejected is not deferred to retry. I think that I need to accept and delete email that is being sent to maybe the top few email address that don't exist and never had existed. They add the most lines to the log. When I was just accepting them and deleting them, then the log was very quiet. If your forwarded mail is what's attempting repeated delivery despite being rejected, you'll need to whitelist those servers and eat the mail. Otherwise, firewall clients who refuse to go away. I will definitely be whitelisting all the servers that forward email to me. I will also be whitelisting all my friend's mail servers. This will probably help with a lot of the bounce rebouncing. Identify the problem, then address it Sounds as if you've foolishly set soft_bounce = yes # postconf -d | grep soft_bounce soft_bounce = no man postconf to see what -d does and why the above information is useless. But no matter; soft_bounce doesn't appear in your postconf -n listing, so that's not it. Is there anything else that could cause a soft_bounce? [postconf output] bounce_queue_lifetime = 2d default_destination_concurrency_limit = 5 default_process_limit = 15 maximal_backoff_time = 4h maximal_queue_lifetime = 3d minimal_backoff_time = 2h qmgr_message_active_limit = 50 qmgr_message_recipient_limit = 50 queue_run_delay = 30m Your settings resemble what someone with an underpowered server with a bad backscatter problem might try. If that's not your situation, use the defaults. If that *is* your situation, address the source of the problem rather than putting postfix colored band- aids on it. What exactly is a backscatter problem? If I do have a backscatter problem, what should the settings be? Mucking around with the above settings is a good way to cripple postfix performance. Tread carefully here. With a process limit of 15, any server less than 10 years old should hardly get above idle. The default has been 100 for years; most servers can easily support several times that. This install of postfix is from a few years ago and it was not up to date then (it is what installed with the OS and I never updated it). A friend of mine recompiled OS for better optimization. I think it was already pretty old when I install it. Really, I was supposed to upgrade Postfix through the packaging system because there was some known problems with what came with the OS, but I never did. I had a friend of mine look at it because it would not receive or send emails to the outside world, and I am not really sure what he did anymore. I think he added one line to master.cf and I think he had me make other changes to master.cf (although, he may have made them). I do remember that the server would basically not work at all and I think the process limit was set to something lower and I raised it to 15. This server runs a lot of other things, like 2 web servers, named, squid, and a whole lot of custom written software, and it pretty much does everything that both of my other dedicated servers do, so that may be why it was set so low. Could this be one of the reasons I see so many bounces in the log? Would this act like a soft bounce? Besides the process limit what else should be raised? smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client
Re: postfix doubling emails and spam!
Hi, On Oct 27, 2010, at 12:38 PM, Noel Jones wrote: On 10/27/2010 10:37 AM, Al Zick wrote: Hi, I hope that someone can help me. Last night I had a strange problem. Every email that came in was there twice. Emails that I would normally get 2 copies of, I received 4 copies of. Any ideas on what could cause this? Careful examination of the logs will probably enlighten you. With no information, speculation is pointless. I have been looking at the logs. I have never seen this before: Oct 27 15:10:03 agnus postfix[27341]: dict_eval: expand $myhostname, $mydomain, localhost.$mydomain - agnus.datazap.net, datazap.net, localhost.datazap.net Oct 27 15:10:03 agnus postfix[27341]: dict_eval: expand $mydestination - agnus.datazap.net, datazap.net, localhost.datazap.net Oct 27 15:10:03 agnus postfix[27341]: dict_eval: expand $relay_domains - agnus.datazap.net, datazap.net, localhost.datazap.net Also, it seems to have rejected almost double what it delivered to command: /usr/local/bin/procmail. There also seems to be a very large number of lost connection after RCPT from unknown. I don't think it would be possible for all of these to be port scans with just how many there are and the log only goes back to 5 pm last night. I think mostly what an mta has to deal with is stupid crap! Also, it seemed to be working correctly this morning, but for hours it duplicated messages. I think it is because of some spammer attempting to relay or send me spam. Not likely. A broken alias is the first guess. What did you change? I didn't change anything and I can't find any duplicates in the log. I have to wonder if the problem didn't occur after it was delivered to procmail. I restarted postfix. I then have postfix pass the email to procmail where it is filtered with bogofilter. I keep giving bogofilter more spam to look at, but it doesn't seem to block all the spam anymore, although it blocks some spam. When I first installed it, bogofilter worked very well. Sounds as if bogofilter is poorly trained. Ask for help on a bogofilter forum, or just delete the database and start over. I have deleted the database many times and started over. If I delete the older spam and the spam that is out of order being sorted by date it will work again for a while. The other thing that is very disturbing to me is that twice last week my mail server went down. I guess from all the repeated attempts to use it as an open relay. From everything I have seen in the logs, postfix successfully stops all relay attempts. A crash is an indication that something is broken. Normally- operating postfix (even under extreme loads) will not cause a crash. Rejecting relay attempts or unknown recipients places very little load on the computer; even a small server can easily reject hundreds of attempts per second with little load. Examine your logs (not just the mail log) for hints of what caused the crash; ask for help on a forum for your operating system. Make sure that security patches for your OS are applied. I looked at all the logs. I really don't see anything that could have caused the problem. I guess that I am making an assumption that I shouldn't be, but it seems like all of my problems lately have been with email. I feel like I need to get postfix to stop using so much cpu. I don't think there are any security patches that I haven't applied. Although, I did look at the what is installed too. I had postfix 2.4 installed. I am now compiling a newer version. One thing that bothered me is that when I was trying to use header checks in postfix to block some of the spam, it would work for a while, but would then stop working and would work just like the header checks were not even configured. The other thing that I see in the log is attempts to send emails to email addresses that never existed. For example: ad...@datazap.net is a valid email address. Why do I 10,000's of attempts to send email to admi...@datazap.net in my log? This has never been a valid email address. These should be quickly rejected by postfix and cause very little load. Spammers send to all kind of non-existent addresses. The problem is that a dozen different mail servers with dozens of different non-existing addresses are all doing it at once, each mail server sending 100's of emails. When I used to use postgray (I gave that up years ago), postgray would use all the cpu. I was using other rbls. This was a mistake, way too many false positives, does anyone have a list of good rbl_clients? zen.spamhaus.org is widely recommended as safe and very effective. If you're too large for the free service, the paid service is well worth the price. http://www.spamhaus.org/organization/dnsblusage.html If you have a fairly recent postfix you should also use reject_rhsbl_* dbl.spamhaus.org http://www.postfix.org/postconf.5.html#reject_rhsbl_client http://www.postfix.org
Re: postfix doubling emails and spam!
Hi Noel, On Oct 27, 2010, at 5:15 PM, Noel Jones wrote: On 10/27/2010 4:44 PM, Al Zick wrote: Hi, On Oct 27, 2010, at 12:38 PM, Noel Jones wrote: On 10/27/2010 10:37 AM, Al Zick wrote: Hi, Turn off verbose logging. That may help your CPU usage too. ok. Not likely. A broken alias is the first guess. What did you change? I didn't change anything and I can't find any duplicates in the log. I have to wonder if the problem didn't occur after it was delivered to procmail. A procmail delivery problem wouldn't surprise me. Is there a replacement for procmail? I know it seemed to take longer and did raise cpu usage, but when I first installed it with bogofilter, it almost eliminated spam getting into my inbox. I just turned on procmail logging, so maybe I will get some answers there. I then have postfix pass the email to procmail where it is filtered with bogofilter. I keep giving bogofilter more spam to look at, but it doesn't seem to block all the spam anymore, although it blocks some spam. When I first installed it, bogofilter worked very well. Sounds as if bogofilter is poorly trained. Ask for help on a bogofilter forum, or just delete the database and start over. I have deleted the database many times and started over. If I delete the older spam and the spam that is out of order being sorted by date it will work again for a while. If bogofilter isn't working for you, try another tool. But remember that nothing will work long term without some attention. I really don't know how much more attention I can give bogofilter. I give it new spam to look at every few days, although recently I have given up on it. problems lately have been with email. I feel like I need to get postfix to stop using so much cpu. Show some evidence. Postfix shouldn't use very much CPU. Over the last month or so I am getting something like 2 to 3 times the spam, so Postfix cpu usage has changed with it. It is not that it is using an abnormal amount of cpu for the increased work it is doing. I am sorry I should have explained that before. each mail server sending 100's of emails. When I used to use postgray (I gave that up years ago), postgray would use all the cpu. So you have a 200MHz 386 or something? So then you are saying it is normal to have 1,000s of emails per second hitting the mail server just to be temporarily bounced by the graylisting when in the end they get bounced anyway. Even after they are bounced, they just keep coming anyway. The problem is these same emails continue to be bounced by my mail server. If I just let them be delivered then it does Sounds as if you've foolishly set soft_bounce = yes # postconf -d | grep soft_bounce soft_bounce = no This would be a good time to share your postconf -n output and the contents of master.cf alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases bounce_queue_lifetime = 2d canonical_maps = hash:/etc/postfix/canonical.sender command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_destination_concurrency_limit = 5 default_process_limit = 15 disable_vrfy_command = yes html_directory = /usr/share/doc/html/postfix inet_protocols = all mail_owner = postfix mailbox_command = /usr/local/bin/procmail mailbox_size_limit = 51200 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_backoff_time = 4h maximal_queue_lifetime = 3d minimal_backoff_time = 2h mydestination = $myhostname, $mydomain, localhost.$mydomain mydomain = datazap.net myhostname = agnus.datazap.net mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases qmgr_message_active_limit = 50 qmgr_message_recipient_limit = 50 queue_directory = /var/spool/postfix queue_run_delay = 30m readme_directory = /usr/share/examples/postfix sample_directory = /usr/share/examples/postfix sender_canonical_maps = hash:/etc/postfix/canonical.sender sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain,reject_rbl_client bl.spamcop.net,reject_rbl_client cbl.abuseat.org, permit strict_rfc821_envelopes = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual smtp inet n - n - - smtpd #submission inet n - n - - smtpd # -o smtpd_enforce_tls=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions
Re: Posfix: deliver to spam folder analog of reject_rbl_client
Hi,
sorbs.net is very agressive, many ISPs get blocked for several
years and
are not willing to delist b/c sorbs doesn't offer free delist for
them.
So there is problem with false-positives. There are not much of them,
but all cases needs additional investigation.
I removed several rbl myself a few days ago. It is very frustrating
when you can't get your email because it is rejected. It also doesn't
make the sender very happy.
So the question is: how it is possible to direct SPAM mail to a
user's
imap spam folder?
This is basically what I do with procmail and bogofilter (although, I
have had some problems with it lately). You can also use rblcheck
with procmail, but I can't find documentation on how to use it with
postfix. I believe that you need postfix to pass the IP address of
the mail server to procmail/rblcheck. I am not sure why it can't use
what is in the header.
Use something like amavisd or MailScanner, add a specific spam
header, and use sieve
If there is a way to set specific header instead of rejecting mail it
would be easy to move tagged mail to spam folder by SEIVE filters.
This
would be prefered variant.
An example sieve script we use on internal mail which is only imap
would be
require [fileinto];
if header :contains X-Spam-Status [Yes,] {
fileinto Junk;
stop;
}
I have found 2 packages:
dovecot-sieve
libsieve
Could you tell me which one you are using with the example above?
Sincerely,
Al
