SA Ignoring Config In LOCAL_RULES_DIR
Hello, and thank you in advanced for looking into the below, I've been pondering over this issue for the past number of days, and don't feel I'm getting anywhere now. I am a system administrator and have been using a Exim/ClamAV/SpamAssassin setup for around 8 years, over which time I had felt I had learnt all the in's and out of the system, but this one has struck me as straight out annoying. I have got seven systems of different age, and operating systems (either Fedora or CentOS). I'll base the below on one of these systems, but it's important to note I'm having this issue on four of the seven machines. So therefore I have compared the config files I would normally use between working and nonworking systems to try and find the fault, but everything appears to be the same. All systems are at different point of updates, and I've tried to "yum update" a faulty machine to fix any bugs but not updated a working machine to see if it breaks. What I am finding is any config saved in the "/etc/mail/spamassassin/" folder is loaded during a "spamassassin --lint -D" but ignored during operations. For example I have a "addresses.cf" file for whitelist_to & from as well as blacklisted_to & from and these are simply ignored, no 100 or -100 score is added to the email header report. I've also got a "latestspam.cf" that I've hand written to block the latest breed of spams that I find an "sa-update" doesn't correct, again these are ignored. I've managed to get my local rules going again by moving the contents of these files into " /var/lib/spamassassin/3.003001/updates_spamassassin_org/local.cf" so my users aren't screaming at me anymore, this is confirmed using a "blacklist_from" and a 100 score is added. This is a fine temporary fix, but I would love for this directory to start working correctly again and to separate these data sets, for synchronization and update proposes. Exim is talking to the spamassassin process by using 127.0.0.1:783, and I've confirmed this connection, as when I stop the SA process, Exim complains it is missing in action. I have checked all the files in "/etc/mail/spamassassin/" in case something isn't toggled correct but I'm wondering where SA looks initially for it configuration folders. I.E. how does it know about the "/var/lib/spamassassin/3.003001/updates_spamassassin_org/" folder? I feel as if I'm missing a master configuration file somewhere. Or is anyone aware what would be making SA ignore my local.cf file in the expected LOCAL_RULES_DIR as listed in the "lint". I feel I've had a good look online and through the http://spamassassin.apache.org/ wiki and etc. I'm sorry if it is a simple issue and I'm just doing something wrong. Thanks again. [root@mail2 ~]# ss -tlp State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 127.0.0.1:783 *:* users:(("spamd",18049,5),("spamd",20074,5),("spamd",35678,5)) [root@mail2 ~]# spamassassin -V SpamAssassin version 3.3.1 running on Perl version 5.10.1 [root@mail2 ~]# exim -bV Exim version 4.72 #1 built 10-Oct-2014 09:23:33 Copyright (c) University of Cambridge, 1995 - 2007 Berkeley DB: Berkeley DB 4.7.25: (September 9, 2013) Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc TCPwrappers OpenSSL Content_Scanning DKIM Old_Demime Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm nis nis0 nisplus passwd sqlite Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 OpenSSL compile-time version: OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL runtime version: OpenSSL 1.0.1e-fips 11 Feb 2013 Configuration file is /etc/exim/exim.conf [root@mail2 ~]# service spamassassin stop Stopping spamd:[ OK ] ==> /var/log/exim/main.log <== 2015-09-15 15:00:43 1ZbkEL-0009T1-Ob DKIM: d=icontactmail6.com s=default c=relaxed/relaxed a=rsa-sha256 [verification succeeded] 2015-09-15 15:00:43 1ZbkEL-0009T1-Ob spam acl condition: warning - spamd connection to 127.0.0.1, port 783 failed: Connection refused 2015-09-15 15:00:43 1ZbkEL-0009T1-Ob spam acl condition: all spamd servers failed 2015-09-15 15:00:44 1ZbkEL-0009T1-Ob <= bounces+1507538.10770803.82...@icpbounce.com H=drone058.ral.icpbounce.com [64.132.109.50] P=esmtp S=13408 [root@mail2 ~]# service spamassassin start Starting spamd:[ OK ] ==> /var/log/exim/main.log <== 2015-09-15 14:46:26 1Zbk0W-000Bcg-Bv DK
URIBL_BLOCKED while using local BIND
Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? Best regards, Marc
Re: URIBL_BLOCKED while using local BIND
Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard signature.asc Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
On 09/15/2015 12:51 PM, Marc Richter wrote: Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? remove the forwarding to your iSP . unless a wider range is being blocked, your problem should be solved btw: adding a hop to every query isn't faster.
Re: URIBL_BLOCKED while using local BIND
Hey Reindl, if you are trying to insult people at all costs, you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... > and *no* the ISP nameserver is *not* a lot faster in most cases Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. Marc Am 15.09.2015 um 12:55 schrieb Reindl Harald: Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard
Re: URIBL_BLOCKED while using local BIND
On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query?
Re: URIBL_BLOCKED while using local BIND
Am 15.09.2015 um 13:23 schrieb Marc Richter: if you are trying to insult people at all costs really? you would recognize it when i intend to do so *any* expierienced mailadmin out there has a local recursion nameserver on his MTA or at least somewhere in his LAN to use a central local cache but only you can't do it? you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. obviously it don't work What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... but it does forward otherwise the problem would be solved > and *no* the ISP nameserver is *not* a lot faster in most cases Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. *lol* yes, the second hit already in your local cache when you don't clear it before, you never ever have 2 ms with a forwarding reslover on the internet asked - never ever! for *that* one specific request if you have the luck it's in his cache it *can* be faster, otherwise the ISP would need to do the whole recursion itself and then answer to your cache with one additional hop what you also ignore is the fact that you get the lowered TTL depending on how old the cache entry on the forwarder is while you own cache entry with recursion would be valid the whole TTL of the SOA in other words: you don't look at the whole picture anyways 543 msec is high ;; Query time: 121 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Di Sep 15 13:27:59 CEST 2015 ;; MSG SIZE rcvd: 57 Am 15.09.2015 um 12:55 schrieb Reindl Harald: Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard signature.asc Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
Marc Richter skrev den 2015-09-15 12:51: But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? https://www.google.dk/search?q=dnswalk dig +trace uribl.com do NOT add forwards in named.conf in the options section its ok pr zone if needed, but not global and make sure resolv.conf ONLY have nameserver 127.0.0.1
Re: URIBL_BLOCKED while using local BIND
Yes Am 15.09.2015 um 13:30 schrieb Axb: On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query?
Re: URIBL_BLOCKED while using local BIND
Marc Richter skrev den 2015-09-15 13:23: That's 271 times faster than root-servers's lookup. hmm maybe your server is heavy loaded of spam ?, and your isp is not ? lets check this so: dig +trace uribl.com show me how it is for you note +trace do not care of forwards at all what version of bind and bind-tools are you using ? did you ask of help on bind maillist ? is threads enabled or disabled in compile time for your bind ?, eg does it use all cores when running ?, if not its forking with slows things down a little, this does not help if you are still on a single core cpu
New warnings after Perl upgrade to 5.20?
Getting the following on sa-learn: each on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 353. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 377. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 406. this is after I upgraded my PERL to 5.20. (SA 3.4.1 on FreeBSD 10.2-STABLE from Ports) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
Re: URIBL_BLOCKED while using local BIND
However you did not empty your ISP's dns server cache. That 2 msec response time is from his cache, the 543 msec for your server is when it's not in your server's cache. So you're not making a fair comparison. A response from a cache is always going to be faster, that's why people use caching servers. However with everybody & his cat using your ISP's server it gets query blocked and thus is caching the bad (blocked) response. So either you get bad data fast or good data slowly. Once you get a second spam with similar contents, queries for that copy will be in your cache and be fast. Given that a modern SA parallelizes DNS queries a somewhat slow DNS response (hundreds of Msecs) won't have too much overall affect on the spam processing time. On Tue, 15 Sep 2015, Marc Richter wrote: Yes Am 15.09.2015 um 13:30 schrieb Axb: On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query? -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: [Announce] SA-Plugins: RedisAWL, RuleTimingRedis
On 2015-06-09 17:57 +0200, Benning, Markus wrote: > RuleTimingRedis - collect SA rule timings in redis I'm trying this out. I have a little annoying problem: the logs beginning on line 178 seem to go to stdout or stderr as well as syslog. The result is that cron sends me email every time spamd is restarted (after every rule update). Do you know how to change that? I find nothing about logging in perldoc Mail::SpamAssassin::Conf. I suppose I could just delete those lines from the module :-) But then I would have extra work when I merge with any new versions you have. Thanks for your ideas. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: SA Ignoring Config In LOCAL_RULES_DIR
On 9/15/2015 3:55 AM, Nathan wrote: What I am finding is any config saved in the "/etc/mail/spamassassin/" folder is loaded during a "spamassassin --lint -D" but ignored during operations. For example I have a "addresses.cf" file for whitelist_to & from as well as blacklisted_to & from and these are simply ignored, no 100 or -100 score is added to the email header report. I've also got a "latestspam.cf" that I've hand written to block the latest breed of spams that I find an "sa-update" doesn't correct, again these are ignored. I've managed to get my local rules going again by moving the contents of these files into " /var/lib/spamassassin/3.003001/updates_spamassassin_org/local.cf" so my users aren't screaming at me anymore, this is confirmed using a "blacklist_from" and a 100 score is added. This is a fine temporary fix, but I would love for this directory to start working correctly again and to separate these data sets, for synchronization and update proposes. Exim is talking to the spamassassin process by using 127.0.0.1:783, and I've confirmed this connection, as when I stop the SA process, Exim complains it is missing in action. I have checked all the files in "/etc/mail/spamassassin/" in case something isn't toggled correct but I'm wondering where SA looks initially for it configuration folders. I.E. how does it know about the "/var/lib/spamassassin/3.003001/updates_spamassassin_org/" folder? I feel as if I'm missing a master configuration file somewhere. Or is anyone aware what would be making SA ignore my local.cf file in the expected LOCAL_RULES_DIR as listed in the "lint". It sounds like it might be an issue with your init script. Check the init script for spamassassin and see if it is starting spamd with a '--siteconfigpath' option or similar. You may also need to check in /etc/sysconfig if your init script pulls anything from there. -- Bowie
Re: [Announce] SA-Plugins: RedisAWL, RuleTimingRedis
On Tue, 2015-09-15 at 08:41 -0700, Ian Zimmerman wrote: > On 2015-06-09 17:57 +0200, Benning, Markus wrote: > > > RuleTimingRedis - collect SA rule timings in redis > > I'm trying this out. I have a little annoying problem: the logs > beginning on line 178 seem to go to stdout or stderr as well as > syslog. > The result is that cron sends me email every time spamd is restarted > (after every rule update). Do you know how to change that? I find > nothing about logging in perldoc Mail::SpamAssassin::Conf. > Assuming your sa_update script is the same as mine (I run Fedora Linux) The obvious quick fix is to change line 2 in case 0) to read: service spamassassin restart;; and remove lines 1 and 3, which (in my script) are both 'echo' commands reporting that the update completed and that Spamassassin was restarted. If you're still seeing the unwanted messages, replace the remaining line with: service spamassassin restart 1>/dev/null 2>/dev.null;; will will suppress anything that Spamassassin sends to stdout and stderr. The sa_update script I have would still report updating errors and the fact that there was no rules update because these are handled by case 1, 2 and * and so can't be silenced by this edit. > I suppose I could just delete those lines from the module :-) But > then I would have extra work when I merge with any new versions you > have. > Doing what I suggest would be easier than editing SA itself. Keep a copy of your cron script when its doing what you want so, if an upgrade slots in a new sa_update script that lets the unwanted text through again, you can simply slot your modified version back in. Martin
Re: New warnings after Perl upgrade to 5.20?
Larry Rosenman wrote: Getting the following on sa-learn: each on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 353. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 377. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 406. this is after I upgraded my PERL to 5.20. (SA 3.4.1 on FreeBSD 10.2-STABLE from Ports) Just warnings fortunately. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7208 fix in revision 1684653: https://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/URILocalBL.pm?r1=1684653&r2=1684652&pathrev=1684653 Mark
Re: URIBL_BLOCKED while using local BIND
On 9/15/2015 6:51 AM, Marc Richter wrote: Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? I would suggest temporarily removing the forward completely as a test and see if this fixes the problem. If so, then your exemptions are not working correctly. If not, then double-check that you are actually using the local server and not still querying the ISP's server. -- Bowie
Re: URIBL_BLOCKED while using local BIND
Hi. If you don't want change DNS resolver for all DNS queries from your server you can add in SA config line: dns_server x.y.z.k:53 where z.y.z.k is IP DNS server using to resolve only by SA. Then in resolv.conf you can use different (ex. ISP) DNS server. More info: http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port Best Regards.
Re: Live upgrade safe?
On 9/15/15, Reindl Harald wrote: > > > Am 15.09.2015 um 00:05 schrieb Nick Edwards: >> On 9/15/15, Matus UHLAR - fantomas wrote: > On 12.09.15 15:27, Reindl Harald wrote: >> and no, i am not the package maintainer but the first person who >> would >> file a bug for *any* package which rely on a internet connection due >> update >>> Am 14.09.2015 um 17:25 schrieb Matus UHLAR - fantomas: > in such case it's up to the distributions' maintainer to: > - provide static rules in the (maybe separate) package > - to warn user that he must immediately get new rules or the SA won't > work >>> >>> On 14.09.15 18:40, Reindl Harald wrote: it is a SA 3.4.1 bug that it don't start when /var/lib/spamassassin/3.004001/ while the package ships the static rules in /usr/share/spamassassin/ >>> with the original 3.4.0 setup it started just fine before sa-update as i installed all that stuff a year ago if you would have followed the thread before response you would know that already >>> >>> I see this particular information for the first time. >>> Maybe you could point me to proper place in the archive? >>> Or maybe you could be more specific instead of blame everyone for >>> everything? >>> - and no that is not rude, you have no idea how i sound if i start to get rude >>> >>> the fact you don't feel being rude does not mean you are not. >> >> Rude, arrogant, abusive, and obnoxious is all he knows, he's been >> kicked off many many mailing lists, and spends most his time here now >> Timo has finally moderated him on dovecot list, he has a huge track >> record of thinking he's not a bully and does nothing wrong, you only >> need 30 seconds of google to see otherwise. > > don't remember that i asked *you* especially after you are so much more > personally abusive as anybody else - the list of your personal attacks > is bookmarked, so don't play saint and shut up > > what a dreamland you live in, I'm not half as much an abusive arsehole as you are, and google shows it, despite any links you want to post to this list, google shows EVERYTHING, not only what you hope people will read but EVERYTHING How many lists has I been moderated? ONE - dovecot and thats for calling you out as the wanker you are, how many lists have you been moderated on? 6? 7 now with dovecot How many lists have I been kicked off? NONE, how many have you been kicked off? at least one that I know of, maybe two, or was it you left the fedora list because they refused to unmoderate you, cant recall, dont care like I said the evidence speaks for itself only you can change your attitude but since you dont think you do any wrong, snowlfakes in hell before you admit fault. So, that alone says it all.
Recommendations for mail with only an image
Hi, Apparently our users use email quite a bit to share pictures. These emails typically contain no subject and no body, just the image. This hits all sorts of rules (perhaps correctly), and was just looking for input on how it should be handled. There are a few rules that seem to overlap in these instances: * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text * 1.8 MISSING_SUBJECT Missing Subject: header * 1.0 FSL_EMPTY_BODY Message has completely empty body Those three are enough to qualify the email as spam alone, pending any points deducted for bayes. I understand these days no one should be sending emails with nothing in the body, not to mention an empty subject, but I'd like to make sure we're not being overly aggressive here as it relates to emails with large images, and also find a way for legitimate users to be able to send pictures (real estate customers, for example). I'm using amavis, and my $sa_mail_body_size_limit is set to 400k, yet multi-megabyte messages are still processed. I understand a chunk of that message may still be processed, but I'd like some way to somehow exclude messages with multi-megabyte picture attachments from being processed. Any ideas greatly appreciated. Thanks, Alex