On Sep 28, 2015, at 1:53 PM, John Hardin <jhar...@impsec.org> wrote: > Is greylisting an acceptable option in your environment?
Probably not. I've got some users who would not accept it. I'm thinking of implementing it anyway, but right now, not a viable option. > Also: both of those samples have URIs and From addresses using unusual new > TLDs. You might want to add something like this: I've adjusted the score of blacklist_uri_host down to only 3 points when Bayes is enabled, so blacklisting would effectively do the same as what you're suggesting, I think... maybe not handling the "From" part. But, as mentioned, I was hoping to find something that did not enable wholesale TLD trashing, although I do acknowledge that this is sometimes the best option. > IME "may be forged" in a Received header refers to the fact that an untrusted > user was running sendmail to submit the message. I don't know how good a spam > sign it is by itself, but in concert with BAYES_999 and/or URI_RARE_TLD it > would probably be worthwhile. AFAIK the "may be forged" indicates that rDNS lookup on the sending IP did not match the HELO information provided by the client, and wasn't specific to trusted or untrusted users. Is that not the case? Using it alone definitely would be a recipe for FP, because I've seen plenty of ham with this. However, I was thinking maybe scoring it 0.1 or 0.2 points, which would then be sufficient when added to BAYES_99 + BAYES_999 to knock an otherwise-non-scoring spam over the threshold. I guess it could be meta-ruled for additional protection. Would something like this be sufficient, or should I make the RE more stringent? # Add spamminess to "may be forged" warning in Received header header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/ describe RCVD_MAY_BE_FORGED Fake HELO info in Received header score RCVD_MAY_BE_FORGED 0.2 Thanks. --- Amir
