On Mon, 28 Sep 2015, Amir Caspi wrote:
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.
You can whitelist on a per-recipient basis, at least in the tool I use
(milter-greylist).
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?
I'm working off rusty memory, but I don't think this specific annotation
rDNS-related, at least in Sendmail.
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
RE looks fine. I'd just describe it as "forgery warning in Received
header" rather than trying to interpret *why* the warning is there.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
You are in a maze of twisty little protocols,
all written by Microsoft.
----------------------------------------------------------------------
