Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
Ed, I'm looking to set up a spam filtering server to replace our ISP's spam filtering service. I've seen this tutorial ( ftp://orn.mpg.de/pub/unix/mail/Fairly-Secure_Anti-SPAM_Gateway_Using_SpamAssassin.html#antivirus ) and I'd be very interested in YOUR opinion; do you think, fundamentally, a server with these software packages could be an effective combination at fighting spam? We're a (I guess) medium size organization with appx. 1000 end users. What about weaving clam-av into the mix? Although this tutorial uses OpenBSD, I'll probably be using FreeBSD. Thank you for your input! I use the same setting on FreeBSD with good enought results. Most of the products are from the ports. I have added to the scheme: - postgrey: grey listing is a very effective way to drop spam, at the cost of a 15 to 60 minutes delay in incoming email; - ClamAV and Kaspersky for viruses (even though there are not that many lately); they fit well in amavis as amavis was preliminarily designed to catch viruses... - procmail to handle the mail delivery and quarantine and daily summary of spam. I have 250 users. Good luk, Olivier
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
Gentlemen, Thank you for your feedback! I'll be sure to check into Postgrey. Are there any special considerations to installing/configuring it or is it simply a matter of installing, reading the docs and configuring? Ed
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
Am 29.11.2012 17:04, schrieb Ed Flecko: Gentlemen, Thank you for your feedback! I'll be sure to check into Postgrey. Are there any special considerations to installing/configuring it or is it simply a matter of installing, reading the docs and configuring? Ed yes dont do greylist all, use selective also for other checks like rbl, spf etc i.e http://www.arschkrebs.de/postfix/postfix_greylisting.shtml i dont use amavis on gateways i use spamass-milter with sanesecurity antispam sigs and clamav-milter but thats mostly a matter of taste amavis has tons of more features but therefor its more complex anyway in milter mode you are able to reject on smtp income stage Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
On Thu, 29 Nov 2012, Ed Flecko wrote: I'll be sure to check into Postgrey. Are there any special considerations to installing/configuring it or is it simply a matter of installing, reading the docs and configuring? The biggest consideration is not technical, it's managing the expectations of your users. You will need to educate your users that email is *not* instant messaging. 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. Some users are extremely allergic to any delays in their email; you may have to maintain a list of exception destination addresses to keep them happy, or for addresses where no delay is acceptable, e.g. support@... or sales@... -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
Good thoughts...thank you John. Ed
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
From: John Hardin jhar...@impsec.org Some users are extremely allergic to any delays in their email; you may have to maintain a list of exception destination addresses to keep them happy, or for addresses where no delay is acceptable, e.g. support@... or sales@... I fully agree. When I purchase an air-line ticket, I want the mail immediately in my inbox. If the greylisting software replies a 4xx Please come back in 299 seconds, the truth is that you will have to wait an undetermined amount of time, depending on the sending server setup, and not at all under your control. Very frustrating. Use good blacklists such as zen.spamhaus.org (free for small installations). Frédéric De Mees Brussels
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
From: John Hardin jhar...@impsec.org I fully agree. When I purchase an air-line ticket, I want the mail immediately in my inbox. If the greylisting software replies a 4xx Please come back in 299 seconds, the truth is that you will have to wait an undetermined amount of time, depending on the sending server setup, and not at all under your control. Very frustrating. I use a blend of greylisting and spamassassin, so that only mails which are close to the margin by SA score get greylisted; lower-scoring mails are accepted immediately, and high-scoring mails are rejected outright. It works pretty well. I've never had any complaints about delivery speed, but some senders have broken mail servers that don't retry on receiving a temporary failure. Greylisting.org maintains an incomplete list of such servers: http://www.greylisting.org/whitelisting.shtml --Ian
Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012 14:36:45 -0500 vec...@vectro.org wrote: I've never had any complaints about delivery speed, but some senders have broken mail servers that don't retry on receiving a temporary failure. Many such servers use broken SMTP implementations that can't handle a 4xx code in response to RCPT properly. 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. Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Regards, David.
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
I'll expand a little on John's comments below On 29/11/12 18:44, John Hardin wrote: On Thu, 29 Nov 2012, Ed Flecko wrote: I'll be sure to check into Postgrey. Are there any special considerations to installing/configuring it or is it simply a matter of installing, reading the docs and configuring? The biggest consideration is not technical, it's managing the expectations of your users. You will need to educate your users that email is *not* instant messaging. Indeed. But do also play around with the delays in postgrey (--delay). A minimal delay of 60 seconds is enough to force a retry and is adequate - legit hosts will retry, non-legit hosts won't so a longer delay is generally unnecessary. 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. Postgrey has an auto-whitelisting mechanism that can be fine tuned by reducing the number of times a client must successfully retry (--auto-whitelist-clients) before auto-whitelisting and adjusting the age of the cache (--max-age) so whitelisted clients are cached for longer. Generally after a couple weeks of normal mail flow, all regular hosts should be cached so only new contacts will get greylisted. Also don't be afraid to whitelist big clients that you receive correspondence from - you know they are legit and will resend so it's pointless greylisting them. Postgrey is very configurable and all the options above are documented in the manpage. Some users are extremely allergic to any delays in their email; you may have to maintain a list of exception destination addresses to keep them happy, or for addresses where no delay is acceptable, e.g. support@... or sales@...
Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?
On 11/29/2012 12:01, Ned Slider wrote: Indeed. But do also play around with the delays in postgrey (--delay). A minimal delay of 60 seconds is enough to force a retry and is adequate - legit hosts will retry, non-legit hosts won't so a longer delay is generally unnecessary. This is only one of the benefits of greylisting; it's one that spammers can trivially bypass by implementing a retry mechanism of their own. The other benefit of greylisting is that you can defer (or re-check) DNSBLs before making the final decision to accept or decline, so a fresh zombie or new spam sender doesn't get a free bite at the inbox. Instead, fact-acting DNSBLs have a chance to get the new sender listed before a greylist retry period expires. Here we do a combination of the two approaches, immediately whitelisting any address to which the user has sent mail in the past, as well as a fairly large list of known senders. After that, we only look at greylisting if the session or message is otherwise a bit suspicious, be it missing or mismatching rDNS, SPF softfail or worse, DK/DKIM failures, BAYES 70+ or SpamAssassin 4+, etc. If it trips one of these normally-too-sensitive-to-use-for-blocking rules, it gets passed over to the greylisting subsystem and then can try again after a few minutes before getting through. This has proved to work very well since it allows a majority of legitimate mail through without greylisting even on the first attempt, but still nets us most of the benefits of greylisting in the end. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
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/2012 08:46 PM, David F. Skoll wrote: [...] Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Do you treat yahoo like spam sources in the same way?
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/2012 12:27, Andrzej A. Filip wrote: On 11/29/2012 08:46 PM, David F. Skoll wrote: [...] Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Do you treat yahoo like spam sources in the same way? There's almost no point in greylisting an IP that you know will retry properly anyway, so why wouldn't you allow that IP to bypass greylisting in the future? -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
Am 29.11.2012 20:46, schrieb David F. Skoll: On Thu, 29 Nov 2012 14:36:45 -0500 vec...@vectro.org wrote: I've never had any complaints about delivery speed, but some senders have broken mail servers that don't retry on receiving a temporary failure. Many such servers use broken SMTP implementations that can't handle a 4xx code in response to RCPT properly. 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. Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Regards, David. greylisting isnt state of art, however it might helpfull in some domains ( everyone has its own spam), using postscreen with postfix before selective greylisting is a good choice Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
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/2012 09:31 PM, Dave Warren wrote: On 11/29/2012 12:27, Andrzej A. Filip wrote: On 11/29/2012 08:46 PM, David F. Skoll wrote: [...] Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Do you treat yahoo like spam sources in the same way? There's almost no point in greylisting an IP that you know will retry properly anyway, so why wouldn't you allow that IP to bypass greylisting in the future? I assume that greylisting of yahoo like spam sources increases chances of bulk detectors detecting spam. Is not it trues? [based on real data]
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com wrote: Do you treat yahoo like spam sources in the same way? With respect to greylisting, of course. If a machine passes greylisting once, it's extremely likely to pass it in future and it's an utter waste of time to greylist it. 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 11/29/2012 09:53 PM, David F. Skoll wrote: On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com wrote: Do you treat yahoo like spam sources in the same way? With respect to greylisting, of course. If a machine passes greylisting once, it's extremely likely to pass it in future and it's an utter waste of time to greylist it. Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in case of yahoo like spam sources? [ based on your experience ]
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012 21:59:45 +0100 Andrzej A. Filip andrzej.fi...@gmail.com wrote: Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in case of yahoo like spam sources? [ based on your experience ] I suppose it might, but I don't use razor, pyzor, dcc or anything similar so I have no personal experience. Regards, David.
FROM_MISSP_* causing FPs
I've just had another couple of reports of false positives due to hits on one or more of the FROM_MISSP_* rules. Curious coincidence: Almost all of the reports to date have involved webform email for real estate companies. Most of the rest have involved scan-to-email multifunction devices - mostly Xerox used by real estate companies. O_o It's become enough of a problem that I've sighed, rolled my eyes, and disabled the scored rules in this cluster, since they're also not making much of a difference in spam catch rate locally. (They're hitting as much as ~3% of mail scanned daily, but only making the difference between ham and spam on ~10-15 of ~80-90K messages daily - including an unknown number of FPs that don't get reported.) While I agree that this is triggering on a real RFC-SHOULD structural problem with the emails, it's clear that people writing webform handlers and people writing email code for multifunction printer/scanner devices don't see this as a problem. I've tried contacting several websites offering services to real estate agents, for instance, and I have had no response. -kgd
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
I've never had any complaints about delivery speed, but some senders have broken mail servers that don't retry on receiving a temporary failure. Many such servers use broken SMTP implementations that can't handle a 4xx code in response to RCPT properly. 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. Also, once a given IP passes greylisting, we remember that and we don't greylist that server for 40 days. If you have a large-enough user population, this can greatly mitigate the problems caused by initial greylisting delays. Every 60 seconds we look at all messages that arrived in last 60 seconds. If there Spamassassin score is less the 1 we add that server to a whitelist for 6 months. If its already on whitelist we update the last message time. If a message scores over 5 we remove it from whitelist if its on it. We do not greylist servers on the whitelist. Works very well. Even though we use greylisting our users very rarely notice if at all due to this.
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
Just wondering how many boxes: rcpt domains: rcpt users: you guys are sending through greylisting. Axb
Trouble with bayes poisoning spam
Hi, I have an example of spam that I just can't reliably detect: http://pastebin.com/YuuLuA1x It's basically some HTML with a URL to an ad for Lantern with 9 LED bulbs. I've trained hundreds of these, and they still report BAYES_50. I've just tested it now, a few hours after having first received it, and it's already being flagged by several URIBLs and is hitting BAYES_99 since I've now trained it. I was just wondering if there was something else that could be triggered on in the header to catch these sooner? I'm assuming the sending IP part of a botnet? I'm using v3.3.2 on fc15 with amavisd. Thanks, Alex
Re: FROM_MISSP_* causing FPs
On Thu, 29 Nov 2012, Kris Deugau wrote: I've just had another couple of reports of false positives due to hits on one or more of the FROM_MISSP_* rules. Curious coincidence: Almost all of the reports to date have involved webform email for real estate companies. Most of the rest have involved scan-to-email multifunction devices - mostly Xerox used by real estate companies. O_o Is there any possibility of getting user agent headers for these FPs? If a particular piece of legit software always does this then obviously those rules should ignore such messages. -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: Trouble with bayes poisoning spam
On Thu, 29 Nov 2012, Alex wrote: I have an example of spam that I just can't reliably detect: http://pastebin.com/YuuLuA1x I was just wondering if there was something else that could be triggered on in the header to catch these sooner? I'm assuming the sending IP part of a botnet? I'm using v3.3.2 on fc15 with amavisd. I'm wondering why this didn't hit any rules: font-size:4px; That's too small to read and should be a good indicator of bayes poison, just like setting the font to white. -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012, David F. Skoll wrote: On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com wrote: Do you treat yahoo like spam sources in the same way? With respect to greylisting, of course. If a machine passes greylisting once, it's extremely likely to pass it in future and it's an utter waste of time to greylist it. Modulo spamvertised URIs and spam checksums sent via such hosts, particularly if they are freemail. Filtering out the spambots who don't retry (and as trivial as that is to defeat, a large amount still gets blocked by this in my experience) is not the _only_ reason to greylist. Giving the URIBLs a chance to list a new URI and the checksum services a chance to recognize a new body are also benefits of greylisting. (But, as you said, you don't take advantage of those tools.) Also, greylisting generally keys on host+sender, not just host. -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012 22:47:45 +0100 Axb axb.li...@gmail.com wrote: boxes: About 50 000 rcpt domains: About 2000 rcpt users: Lots. I don't have an exact figure. you guys are sending through greylisting. This is on our machines. Our larger customers have significantly higher numbers. Regards, David.
Re: FROM_MISSP_* causing FPs
On 11/29/2012 05:43 PM, John Hardin wrote: On Thu, 29 Nov 2012, Kris Deugau wrote: I've just had another couple of reports of false positives due to hits on one or more of the FROM_MISSP_* rules. Curious coincidence: Almost all of the reports to date have involved webform email for real estate companies. Most of the rest have involved scan-to-email multifunction devices - mostly Xerox used by real estate companies. O_o Is there any possibility of getting user agent headers for these FPs? If a particular piece of legit software always does this then obviously those rules should ignore such messages. I had one guy actually read the rejection message and contact postmaster@ about this. His sig shows: Sent from my MOTOROLA ATRIX™ 2 on ATT And the headers: X-Spam-Flag: NO X-Spam-Score: 4.224 X-Spam-Level: X-Spam-Status: No, score=4.224 required=5 tests=[FREEMAIL_FROM=0.001, FROM_MISSP_EH_MATCH=2.499, FROM_MISSP_FREEMAIL=1.723, HTML_MESSAGE=0.001] autolearn=disabled From: u...@example.comu...@example.com X-Mailer: Motorola android mail 1.0 It was relayed through AOL, who you think would clean that up. This particular model also base64 encodes the entire message...
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in case of yahoo like spam sources? No. A remarkable fraction of ratware still doesn't bother to retry, so the most simple minded greylister will deter them. That's why it's useful. I've never seen any support for the theory that greylisting delays make it more likely that the host will be blacklisted when it retries. I haven't seen many legit senders that don't retry as David says he has, but I don't have his volume of mail, either.
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 30 Nov 2012, John Levine wrote: Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in case of yahoo like spam sources? No. A remarkable fraction of ratware still doesn't bother to retry, so the most simple minded greylister will deter them. That's why it's useful. I've never seen any support for the theory that greylisting delays make it more likely that the host will be blacklisted when it retries. It's not so much the host being blacklisted, as a checksum of the spam being published by pyzor et. al., or for spamvertised websites in the spam being published by URIBLs, so that when the sender tries again the score for that message will be higher than it would the first time around, hopefully high enough to classify it as spam rather than a FN. -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: FROM_MISSP_* causing FPs
On Thu, 29 Nov 2012, Michael Orlitzky wrote: On 11/29/2012 05:43 PM, John Hardin wrote: On Thu, 29 Nov 2012, Kris Deugau wrote: I've just had another couple of reports of false positives due to hits on one or more of the FROM_MISSP_* rules. Curious coincidence: Almost all of the reports to date have involved webform email for real estate companies. Most of the rest have involved scan-to-email multifunction devices - mostly Xerox used by real estate companies. O_o Is there any possibility of getting user agent headers for these FPs? If a particular piece of legit software always does this then obviously those rules should ignore such messages. I had one guy actually read the rejection message and contact postmaster@ about this. His sig shows: Sent from my MOTOROLA ATRIX™ 2 on ATT And the headers: X-Spam-Flag: NO X-Spam-Score: 4.224 X-Spam-Level: X-Spam-Status: No, score=4.224 required=5 tests=[FREEMAIL_FROM=0.001, FROM_MISSP_EH_MATCH=2.499, FROM_MISSP_FREEMAIL=1.723, HTML_MESSAGE=0.001] autolearn=disabled From: u...@example.comu...@example.com X-Mailer: Motorola android mail 1.0 It was relayed through AOL, who you think would clean that up. This particular model also base64 encodes the entire message... Thanks, I will add some MUA rules for this and see what the corpus has to say, if anything. Kris, any from you? Anybody who sees FPs with the FROM_MISSP rules is more than welcome to send me X-Mailer and/or User-Agent headers directly. -- 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 --- Bother, said Pooh as he struggled with /etc/sendmail.cf, it never does quite what I want. I wish Christopher Robin was here. -- Peter da Silva in a.s.r --- 26 days until Christmas
Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)
On Thu, 29 Nov 2012 18:01:38 -0800 (PST) John Hardin jhar...@impsec.org wrote: It's not so much the host being blacklisted, as a checksum of the spam being published by pyzor et. al., or for spamvertised websites in the spam being published by URIBLs, so that when the sender tries again the score for that message will be higher than it would the first time around, hopefully high enough to classify it as spam rather than a FN. I would love to gather some hard data on this. Maybe a research project for the future... since we do our greylisting post-DATA, we could in principle run all the content-filtering and URIBL lookups and check if the score changes between the first attempt and the final attempt after greylisting. Or those who use SA without greylisting could reprocess messages after an hour or two and see if the score goes up. [My gut instinct says that a reasonable greylisting interval is too short for most DNSBLs to react. Pyzor/Razor/DCC may be somewhat more adept at reacting quickly.] 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 11/29/2012 17:37, John Levine wrote: Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in case of yahoo like spam sources? No. A remarkable fraction of ratware still doesn't bother to retry, so the most simple minded greylister will deter them. That's why it's useful. I've never seen any support for the theory that greylisting delays make it more likely that the host will be blacklisted when it retries. If I run my accepted-and-quarantined spam corpus through a filter to test against DNSBL effectiveness, I always see higher effectiveness ratings than what was shown during the SMTP phase. I haven't done so in recent enough memory to have any actual numbers, but when I last did a comparison, slow moving DNSBLs showed little/no change at all, fast-acting trap-driven ones show more of a difference. Now I've not studied the exactly amount of time it takes for hosts to start getting listed, but since I only greylist questionable stuff already and since I whitelist aggressively, I've been able to set my greylisting in the 30-60 minute range without too many seizures from users and with higher rejection counts -- Since greylisting doesn't cause higher reject counts, I assume (yes, just assume) that it's due to higher hit rates. I admit that it would make sense to do further testing, but for fast-acting DNSBLs, and body-hash based systems, it makes sense that the longer one defers a message, the greater the odds of a hit against a new zombie or a new spam-run. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
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/2012 18:54, David F. Skoll wrote: [My gut instinct says that a reasonable greylisting interval is too short for most DNSBLs to react. Pyzor/Razor/DCC may be somewhat more adept at reacting quickly.] Something trap-driven like NIX is a candidate. No, it's not safe enough to reject based on it's output, but it was worth use in a scoring system. Invalument too responds reasonably quickly, enough that it sometimes tripped during the greylist period. The other trick is how you define reasonable. A reasonable greylist period for greylisting all mail is about 3 seconds, otherwise you'll have users screaming. However, if you only greylist questionable stuff to start with (rDNS failures, mismatches, etc, SPF fails, borderline-spammy stuff, DUL hits), you can get away with much longer times since most of it is crap anyway but a greylist period can help let the odd gem through. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
