Message not scanned- Size?
A message slipped through untouced. Obvious spam from Minister of Finance with many attachments. /var/log/mail shows a message skipped spamc[7262]: skipped message, greater than max message size (512000 bytes) at the time this came thru. I'd guess that was it. Unusual, but any way to prevent that in future? joe a.
Re: FROM_MISSP_* causing FPs
Alex, from prypiat.
Yes, I recycle.
On 12-12-03 02:04 AM, John Wilcock wrote:
Le 30/11/2012 18:18, John Hardin a écrit :
header __AJB_HAS_XEROXX-Mailer =~ /WorkCentre \d{3,5}/
header __AJB_XEROX_SUBJ Subject =~ /Scan from a Xerox/
Thanks! I will add those to my sandbox.
Question: how often do you see that subject _without_ that X-Mailer?
Whenever someone legitimately forwards a scanned document (which is
quite a common occurrence in offices that have such scanner/copiers).
Also worth noting that the default subject depends on the copier's
locale, and can be changed anyway.
Right. But thing is: spammers won't try this, they tend to mimic the
default title to lure unaware/imprudent end-users. Therefore the
relative utility of a meta including the default title ;-)
To answer John Hardin's question: I will have to query my logs, I don't
have much time, but I will answer your question someday :-D
PS: do you want genuine scans from other types of networked copier? I
can forward a Rex Rotary example offlist if that would be useful.
John.
signature.asc
Description: OpenPGP digital signature
Re: Message not scanned- Size?
Hi, I guess you may change your threshold for the cut off? the -s flag, when calling spamc seems to be it. I use amavisd-new to feed SA, it does the same thing, I had to change my threshold too to analyze bigger emails. Best, Alex, from prypiat. Yes, I recycle. On 12-12-03 06:25 AM, Joseph Acquisto wrote: A message slipped through untouced. Obvious spam from Minister of Finance with many attachments. /var/log/mail shows a message skipped spamc[7262]: skipped message, greater than max message size (512000 bytes) at the time this came thru. I'd guess that was it. Unusual, but any way to prevent that in future? joe a. signature.asc Description: OpenPGP digital signature
Re: FROM_MISSP_* causing FPs
On Mon, 3 Dec 2012, John Wilcock wrote:
Le 30/11/2012 18:18, John Hardin a écrit :
header __AJB_HAS_XEROXX-Mailer =~ /WorkCentre \d{3,5}/
header __AJB_XEROX_SUBJ Subject =~ /Scan from a Xerox/
Thanks! I will add those to my sandbox.
Question: how often do you see that subject _without_ that X-Mailer?
Whenever someone legitimately forwards a scanned document (which is quite a
common occurrence in offices that have such scanner/copiers). Also worth
noting that the default subject depends on the copier's locale, and can be
changed anyway.
PS: do you want genuine scans from other types of networked copier? I can
forward a Rex Rotary example offlist if that would be useful.
Sure.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
It is not the place of government to make right every tragedy and
woe that befalls every resident of the nation.
---
12 days until Bill of Rights day
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On 11/29/12 14:46:25, David F. Skoll wrote: We greylist after the end of DATA. This wastes bandwidth, but lets us use the Subject: line as an additional mix in the greylisting tuple. This catches ratware that retries in the face of greylisting, but mutates the subject line with each retry. We use grey listing on our low volume server, and as others have noted, it works well because a high percentage of spam bots do not bother to retry. But as others have mentioned, it can be painful waiting for the delayed confirmation on a registration to a web site to come in an hour/two later, or email from a new client who is waiting on a response. Since this is a Spam Assassin list: Is there a way of disabling grey listing, but still receiving some benefit from the principle that mail received from a first time or infrequent sender should be looked upon with some suspicion? Assume that either some to-be-implemented SA filter, or some mail gateway front-end (like MIMEDefang), adds a new tag/two, for example: SENDER_FIRST_RCPT, SENDER_LOW_FREQ, SENDER_HI_FREQ, or SENDER_HI_AVE_SA_SCORE? All these tags might be based upon some look back period (say: 90 days). Theoretically, these new tags could be calculated after the fact when passing through a spam corpus. And since many/most grey listing systems differentiate by some form of (sender, recipient) pairing this analysis can be reliably/repeatably performed by an SA plug-in at the point of delivery to the user, if needed. It would need to be shown that these new tags improve the ability to discriminate spam from ham. If the scheme worked well, there might be no need for grey listing at all.
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
On 11/29/12 10:44:54, John Hardin wrote: You will probably want to put a little effort into maintaining lists of regular correspondents who can bypass greylisting. There may be tools to automate that, e.g. to whitelist someone a local user has sent mail to. Has anyone looked into the use of a DNS-based white listing service? For example: http://www.dnswl.org/ It might be interesting to make a pass over a grey list database and see if the sites white listed there appear in the registry. And that sites that were black listed or simply did not retry are _not_ listed in the white list.
Re: Debugging bayes w/ '--virtual-config-dir'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2012 04:17 PM, Tres Seaver wrote: Running SA 3.3.2 on Ubunto 12.04. Here is how spamd is running: $ pgrep -lf spamd 26110 /usr/bin/perl -T -w /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir --username=vmail --nouser-config --virtual-config-dir=/home/vmail/spamassassin/%d/%l --syslog=/var/log/spamd.log --debug=all,bayes,check,config -d --pidfile=/var/run/spamd.pid 26112 spamd child 26113 spamd child And the tokens for my account: # sa-learn --dump=magic\ --dbpath=/home/vmail/spamassassin/example.com/localname 0.000 0 3 0 non-token data: bayes db version 0.000 0 3109 0 non-token data: nspam 0.000 0 24458 0 non-token data: nham 0.000 0 177188 0 non-token data: ntokens 0.000 0 1351290514 0 non-token data: oldest atime 0.000 0 1354054449 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 1354062194 0 non-token data: last expiry atime 0.000 02764800 0 non-token data: last expire atime delta 0.000 0 7488 0 non-token data: last expire reduction count But I see nothing in the log for 'bayes' during normal processing; I only see entries immediately after restart (e.g., the nightly restart after updating rulesets): # grep : bayes /var/log/spamd.log ... [25810] dbg: logger: adding facilities: all, bayes, check, config ... [26110] dbg: config: fixed relative path: /var/lib/spamassassin/3.003002/updates_spamassassin_org/23_bayes.cf ... [26110] dbg: config: using /var/lib/spamassassin/3.003002/updates_spamassassin_org/23_bayes.cf for included file ... [26110] dbg: bayes: learner_new self=Mail::SpamAssassin::Plugin::Bayes=HASH(0x2db7fe0), bayes_store_module=Mail::SpamAssassin::BayesStore::DBM ... [26110] dbg: bayes: learner_new: got store=Mail::SpamAssassin::BayesStore::DBM=HASH(0x26392f8) ... [26110] dbg: bayes: no dbs present, cannot tie DB R/O: /tmp/spamd-26110-init/.spamassassin/bayes_toks ... [26110] dbg: bayes: no dbs present, cannot tie DB R/O: /tmp/spamd-26110-init/.spamassassin/bayes_toks Which smells to me as though the bayesian stuff is not enabled. But: # grep bayes /etc/spamassassin/local.cf use_bayes 1 bayes_auto_learn 1 bayes_ignore_header X-Bogosity bayes_ignore_header X-Spam-Flag bayes_ignore_header X-Spam-Status # and a well-trained bayes DB can save running rules, too Any suggestions where I should be looking? I think I have identified the issue: using amavisd's built-in SA support means that per-recipient spam checks aren't feadible (amavisd wants to pass each message through SA exactly once, rather than once per recipient). I think that I'm not seeing any log activity in the spamd log because amavisd isn't delegating to spamd, but rather using the SA perl modules directly. Can anyone confirm that hypothesis? I believe the workaround is going to be to disable SA support inside amavisd and instead do the SA procesing during the delivery phase, where I can run 'spamc -u user' to play nicely with spamd's --virtual-config-dir. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC8xNkACgkQ+gerLs4ltQ78KACcCh2sijgh6uh7KHLSnQqXHqVh uloAoI+BxyxTJ8yF0+Q9Gzt6FRGB1KIW =yv5s -END PGP SIGNATURE-
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
We greylist after the end of DATA. This wastes bandwidth, but lets us use the Subject: line as an additional mix in the greylisting tuple. This catches ratware that retries in the face of greylisting, but mutates the subject line with each retry. We use grey listing on our low volume server, and as others have noted, it works well because a high percentage of spam bots do not bother to retry. But as others have mentioned, it can be painful waiting for the delayed confirmation on a registration to a web site to come in an hour/two later, or email from a new client who is waiting on a response. Using dnswl.org to whitelist against greylisting might help some. Since this is a Spam Assassin list: Is there a way of disabling grey listing, but still receiving some benefit from the principle that mail received from a first time or infrequent sender should be looked upon with some suspicion? Assume that either some to-be-implemented SA filter, or some mail gateway front-end (like MIMEDefang), adds a new tag/two, for example: SENDER_FIRST_RCPT, SENDER_LOW_FREQ, SENDER_HI_FREQ, or SENDER_HI_AVE_SA_SCORE? All these tags might be based upon some look back period (say: 90 days). Theoretically, these new tags could be calculated after the fact when passing through a spam corpus. And since many/most grey listing systems differentiate by some form of (sender, recipient) pairing this analysis can be reliably/repeatably performed by an SA plug-in at the point of delivery to the user, if needed. It would need to be shown that these new tags improve the ability to discriminate spam from ham. If the scheme worked well, there might be no need for grey listing at all.
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
You will probably want to put a little effort into maintaining lists of regular correspondents who can bypass greylisting. There may be tools to automate that, e.g. to whitelist someone a local user has sent mail to. Has anyone looked into the use of a DNS-based white listing service? For example: http://www.dnswl.org/ It might be interesting to make a pass over a grey list database and see if the sites white listed there appear in the registry. And that sites that were black listed or simply did not retry are _not_ listed in the white list. Been using it at least couple years to bypass greylisting. Seems to give no negative impact. Be sure to add the IP of your servers there.
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Mon, 2012-12-03 at 07:23 -0800, Gary Funck wrote: Since this is a Spam Assassin list: Is there a way of disabling grey listing, but still receiving some benefit from the principle that mail received from a first time or infrequent sender should be looked upon with some suspicion? Yes. If you keep a list of the recipients of outgoing mail its easy to whitelist any mail you receive from them. This approach does what you want: a sender is treated as suspicious until you've sent mail to them and recipient list maintenance is easy to automate. I use a mail archive system as my recipients list because it has a record of everybody I've sent mail to. I use an SA plugin to access the archive. The combination of it and an associated rule will whitelist anybody who is recorded in the archive as having received mail from me. However, the database archives messages at 4-6 /sec, so this and/or the storage requirements (4.3 GB to store 143,000 messages) may mean that, if you're a high volume site and/or don't need an archive, you'd be better off just keeping a list of the recipient(s) of outgoing messages. I wrote my archive for personal use because I can find an old e-mail with the archive search tool faster than I can by ferreting though a set of mail folders: it was never designed as a high volume solution, but should manage small business volumes quite easily with both it and SA running on a typical desktop PC. Up to early this year I was using an 866 MHz P3 with 512MB RAM that easily kept up while PostgreSQL,the archive, Postfix and SA. That is all now running on a 3GHz dual Athlon with 4 GB RAM but not going any faster - an upgrade to Fedora 16 forced the change because its installer wouldn't run in less than 1GB RAM. If you think my SA plugin or the mail archive would be of use to you, contact me off-list. Martin
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
On Mon, 2012-12-03 at 07:27 -0800, Gary Funck wrote: On 11/29/12 10:44:54, John Hardin wrote: You will probably want to put a little effort into maintaining lists of regular correspondents who can bypass greylisting. There may be tools to automate that, e.g. to whitelist someone a local user has sent mail to. Has anyone looked into the use of a DNS-based white listing service? Everybody's mail stream is different (I don't see any of the spam types discussed over the last week or two) so my guess is that any public whitelister would not be specific enough for any particular site. Its quite likely that stuff you and your users don't want would be whitelisted by it and OTOH you probably have a few mail sources that you want to see but aren't being whitelisted. For instance, I doubt that a US-based whitelister would whitelist customer information sent out by, say, Australian energy companies or British telcos. Martin
Re: Debugging bayes w/ '--virtual-config-dir'
On 12/3/2012 10:27 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2012 04:17 PM, Tres Seaver wrote: Running SA 3.3.2 on Ubunto 12.04. Here is how spamd is running: $ pgrep -lf spamd 26110 /usr/bin/perl -T -w /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir --username=vmail --nouser-config --virtual-config-dir=/home/vmail/spamassassin/%d/%l --syslog=/var/log/spamd.log --debug=all,bayes,check,config -d --pidfile=/var/run/spamd.pid 26112 spamd child 26113 spamd child And the tokens for my account: # sa-learn --dump=magic\ --dbpath=/home/vmail/spamassassin/example.com/localname 0.000 0 3 0 non-token data: bayes db version 0.000 0 3109 0 non-token data: nspam 0.000 0 24458 0 non-token data: nham 0.000 0 177188 0 non-token data: ntokens 0.000 0 1351290514 0 non-token data: oldest atime 0.000 0 1354054449 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 1354062194 0 non-token data: last expiry atime 0.000 02764800 0 non-token data: last expire atime delta 0.000 0 7488 0 non-token data: last expire reduction count But I see nothing in the log for 'bayes' during normal processing; I only see entries immediately after restart (e.g., the nightly restart after updating rulesets): # grep : bayes /var/log/spamd.log ... [25810] dbg: logger: adding facilities: all, bayes, check, config ... [26110] dbg: config: fixed relative path: /var/lib/spamassassin/3.003002/updates_spamassassin_org/23_bayes.cf ... [26110] dbg: config: using /var/lib/spamassassin/3.003002/updates_spamassassin_org/23_bayes.cf for included file ... [26110] dbg: bayes: learner_new self=Mail::SpamAssassin::Plugin::Bayes=HASH(0x2db7fe0), bayes_store_module=Mail::SpamAssassin::BayesStore::DBM ... [26110] dbg: bayes: learner_new: got store=Mail::SpamAssassin::BayesStore::DBM=HASH(0x26392f8) ... [26110] dbg: bayes: no dbs present, cannot tie DB R/O: /tmp/spamd-26110-init/.spamassassin/bayes_toks ... [26110] dbg: bayes: no dbs present, cannot tie DB R/O: /tmp/spamd-26110-init/.spamassassin/bayes_toks Which smells to me as though the bayesian stuff is not enabled. But: # grep bayes /etc/spamassassin/local.cf use_bayes 1 bayes_auto_learn 1 bayes_ignore_header X-Bogosity bayes_ignore_header X-Spam-Flag bayes_ignore_header X-Spam-Status # and a well-trained bayes DB can save running rules, too Any suggestions where I should be looking? I think I have identified the issue: using amavisd's built-in SA support means that per-recipient spam checks aren't feadible (amavisd wants to pass each message through SA exactly once, rather than once per recipient). I think that I'm not seeing any log activity in the spamd log because amavisd isn't delegating to spamd, but rather using the SA perl modules directly. Can anyone confirm that hypothesis? Confirmed. Amavisd does not do per-user SA and uses the SA libraries internally rather than talking to spamd. I believe the workaround is going to be to disable SA support inside amavisd and instead do the SA procesing during the delivery phase, where I can run 'spamc -u user' to play nicely with spamd's --virtual-config-dir. That is what I do. Pass in the user with 'spamc -u email-address' and use the --virtual-config-dir to tell spamd where to find the directories for each user. -- Bowie
Re: Message not scanned- Size?
On 12/3/2012 8:13 AM, Alexandre Boyer wrote: Hi, I guess you may change your threshold for the cut off? the -s flag, when calling spamc seems to be it. I use amavisd-new to feed SA, it does the same thing, I had to change my threshold too to analyze bigger emails. I'm currently testing some tricks. I use MimeDefang to call spamc through a custom filter to interacts with spamd. I've added two tricks to this filter. One, I pass the load_avg to the filter and use it to modify the size limit for spamc based on load. The lower the load, the higher the multiplier. Two, I'm trying a system that also truncates messages mid-message at the threshold to scan them anyway. The second idea has been pretty controversial but I think the first one is a neat idea. This might be something neat to add to spamd/spamc natively where there is a load average multiplier concept. Thoughts? Regards, KAM
Re: Message not scanned- Size?
On Mon, Dec 03, 2012 at 01:54:44PM -0500, Kevin A. McGrail wrote: I've added two tricks to this filter. One, I pass the load_avg to the filter and use it to modify the size limit for spamc based on load. The lower the load, the higher the multiplier. Seems kind of pointless. Have you actually measured how larger messages affect cpu usage? Especially since usually there are much less messages the larger they get. If 10% more cpu or whatever makes your server hang, then you have other problems. :-) Two, I'm trying a system that also truncates messages mid-message at the threshold to scan them anyway. The second idea has been pretty controversial but I think the first one is a neat idea. Why is it controversial? Amavisd-new 2.6.3 had this feature since 2009, so it's used probably very widely - even without users knowing it. I've never seen any ill effects. This might be something neat to add to spamd/spamc natively where there is a load average multiplier concept. Thoughts? Load average is quite silly measurement. The maximum depends on the number of cpu cores/threads. Also this kind of limiting makes sense only on a pre-queue filter in which case such throttles should be applied way before anything gets to SA.
Re: Message not scanned- Size?
On 12/3/2012 3:03 PM, Henrik K wrote: Two, I'm trying a system that also truncates messages mid-message at the threshold to scan them anyway. The second idea has been pretty controversial but I think the first one is a neat idea. Why is it controversial? Amavisd-new 2.6.3 had this feature since 2009, so it's used probably very widely - even without users knowing it. I've never seen any ill effects. There have been emails on list in the past few weeks. I believe AXB is anti the concept. I have no opinion yet which is why I am testing. This might be something neat to add to spamd/spamc natively where there is a load average multiplier concept. Thoughts? Load average is quite silly measurement. The maximum depends on the number of cpu cores/threads. Also this kind of limiting makes sense only on a pre-queue filter in which case such throttles should be applied way before anything gets to SA. I'm simply trying to maximize resources and right now, the reason SA doesn't scan infinitely is because large messages take more time to process. Using Load Average, which I agree is a bit amorphous, is a quick gauge of resources that are available and allows me to automatically raise and lower the size limit for spamc/d in a way that is not controversial such as the truncation method. Regards, KAM
Re: Message not scanned- Size?
On Mon, 3 Dec 2012 22:03:25 +0200 Henrik K h...@hege.li wrote: On Mon, Dec 03, 2012 at 01:54:44PM -0500, Kevin A. McGrail wrote: [Test loadavg in filtering decisions] Seems kind of pointless. Have you actually measured how larger messages affect cpu usage? Especially since usually there are much less messages the larger they get. I agree. LoadAVG is a pretty useless measurement. And relaxing your filtering based on load gives spammers a clear signal how to defeat your filter. Two, I'm trying a system that also truncates messages mid-message at the threshold to scan them anyway. Why is it controversial? Amavisd-new 2.6.3 had this feature since 2009, so it's used probably very widely - even without users knowing it. I've never seen any ill effects. We truncate overly-long messages too, but we try to be intelligent about it. We shrink non-text MIME parts first and then if the message is still too large, we give up. Just blindly cutting a message in the middle might wreck the MIME structure and give unexpected and unwanted results. Regards, David.
Re: Message not scanned- Size?
On 12/3/2012 3:43 PM, David F. Skoll wrote: I agree. LoadAVG is a pretty useless measurement. And relaxing your filtering based on load gives spammers a clear signal how to defeat your filter. ... We truncate overly-long messages too, but we try to be intelligent about it. We shrink non-text MIME parts first and then if the message is still too large, we give up. Just blindly cutting a message in the middle might wreck the MIME structure and give unexpected and unwanted results. My goal is to implement something in spamc/spamd that's useful for people using SA more out of the box. I guess, my thought is that adding some logic to dynamically increase the size limit was better than the status quo. I agree your techniques are good and perhaps it's time to make MIME::Tools more integral to SA. Perhaps I'm focusing too much on better than now and you're both right, we need to focus on the best. Regards, KAM
Re: Message not scanned- Size?
On Mon, 03 Dec 2012 15:51:45 -0500 Kevin A. McGrail kmcgr...@pccc.com wrote: My goal is to implement something in spamc/spamd that's useful for people using SA more out of the box. I guess, my thought is that adding some logic to dynamically increase the size limit was better than the status quo. OK. I agree your techniques are good and perhaps it's time to make MIME::Tools more integral to SA. Well. :) I'm not sure about that... MIME::Tools can be pretty memory-hungry and I assume SA already has a way to parse MIME and build an in-memory representation of the MIME message. As long as you can manipulate that, you can truncated messages intelligently. Regards, David.
Re: Message not scanned- Size?
On 12/3/2012 3:43 PM, David F. Skoll wrote: On Mon, 3 Dec 2012 22:03:25 +0200 Henrik K h...@hege.li wrote: On Mon, Dec 03, 2012 at 01:54:44PM -0500, Kevin A. McGrail wrote: [Test loadavg in filtering decisions] Seems kind of pointless. Have you actually measured how larger messages affect cpu usage? Especially since usually there are much less messages the larger they get. I agree. LoadAVG is a pretty useless measurement. And relaxing your filtering based on load gives spammers a clear signal how to defeat your filter. I think you're looking at it the wrong way around. You start with the max size that is currently in use. You then increase the max size when the box isn't busy. You are not relaxing the filtering, you are tightening it. -- Bowie
Re: Message not scanned- Size?
On Mon, 03 Dec 2012 16:04:42 -0500 Bowie Bailey bowie_bai...@buc.com wrote: You are not relaxing the filtering, you are tightening it. It still IMO is a bad idea. Effectively, you are lowering your security when your box is busier no matter how you look at it. If your box can't handle load spikes, then when it gets busy you should just spool mail and scan it later when the load goes back down. If your box can't handle the *average* load, then it's time for a bigger box (or more boxes.) Regards, David.
Re: Message not scanned- Size?
On 12/3/2012 4:12 PM, David F. Skoll wrote: On Mon, 03 Dec 2012 16:04:42 -0500 Bowie Bailey bowie_bai...@buc.com wrote: You are not relaxing the filtering, you are tightening it. It still IMO is a bad idea. Effectively, you are lowering your security when your box is busier no matter how you look at it. If your box can't handle load spikes, then when it gets busy you should just spool mail and scan it later when the load goes back down. If your box can't handle the *average* load, then it's time for a bigger box (or more boxes.) Without this setup, you are always at the lower security level. Of course, everyone would like to have a box that can handle fully scanning every email that comes in, but for some people that is just not feasible. If you want to get the maximum out of the hardware that you have, then I don't see any reason not to use something like this. In reality, few spams exceed the current default size limits. So you are not losing much by staying with those limits anyway. -- Bowie
Re: Message not scanned- Size?
On Mon, 03 Dec 2012 16:20:30 -0500 Bowie Bailey bowie_bai...@buc.com wrote: Without this setup, you are always at the lower security level. Ah, so you believe the glass is half-full whereas I maintain it's half-empty. :) Of course, everyone would like to have a box that can handle fully scanning every email that comes in, but for some people that is just not feasible. In that case, such people have no business scanning their email and should outsource it or move to Google Apps. Seriously. We're talking about a critical piece of security infrastructure and skimping on it will bite you. If you want to get the maximum out of the hardware that you have, then I don't see any reason not to use something like this. If you want to maximize your scanning capacity, you'll put larger messages aside and scan them later when the load goes down. In reality, few spams exceed the current default size limits. So you are not losing much by staying with those limits anyway. In which case the whole thing is probably moot and basing the size limit on load is an unnecessary complication. Regards, David.
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Mon, 3 Dec 2012 07:23:59 -0800 Gary Funck wrote: Since this is a Spam Assassin list: Is there a way of disabling grey listing, but still receiving some benefit from the principle that mail received from a first time or infrequent sender should be looked upon with some suspicion? Personally I wouldn't want to do it that way round - with a positive score for unknown rather than a negative score for known. YMMV but almost all of the FPs I've had in the last ten years have been that sort of mail because it's less likely to be recognised by Bayes.
