Den 2012-02-17 06:53, JP Kelly skrev:
No didn't work.
with --lint I got:
warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT:
/style=\"color: missing or invalid delimiters
^^
On Feb 16, 2012, at 7:53 PM, Benny Pedersen wrote:
Den 2012-02-17 02:12, JP Kelly skrev:
How
The '#' is a comment character, need to escape it.
Try:
rawbody HTML_TEXT_WHITE_SHORT /style="color\#FFF;/
On Thu, 16 Feb 2012, JP Kelly wrote:
No didn't work.
with --lint I got:
warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT: /style=\"color:
missing or invalid delimiters
O
No didn't work.
with --lint I got:
warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT: /style=\"color:
missing or invalid delimiters
On Feb 16, 2012, at 7:53 PM, Benny Pedersen wrote:
> Den 2012-02-17 02:12, JP Kelly skrev:
>
>> How do I implement this?
>
>>> rawbody HTML_TEXT_WHITE
Den 2012-02-17 02:12, JP Kelly skrev:
How do I implement this?
rawbody HTML_TEXT_WHITE_SHORT /style="color#FFF;/
add it to local.cf or user_prefs, its not tested here so it might not
work at all
it will score default 1.0 if no score is set
ok I'm a dummy.
How do I implement this?
On Feb 16, 2012, at 5:03 PM, John Hardin wrote:
> rawbody HTML_TEXT_WHITE_SHORT /style="color#FFF;/
Adam Katz-10 wrote:
>
> Thomas Rutter: If you have any objections to what I did, complain now.
>
That's fine.
I have been hard at work on tweaking these rules and have come up with new
versions which appear more effective. Have not spent much time on
performance though.
New version follows
On Thu, 16 Feb 2012, JP Kelly wrote:
I am getting a bunch of spam with white text on a white background. Any ideas
how to catch it?
Here is an example:
At the risk of playing whack-a-mole:
rawbody HTML_TEXT_WHITE_SHORT /style="color#FFF;/
The short color code is probably unlikely to
>
>> On 2/16/2012 4:54 PM, email builder wrote:
>
but it's misconfigured trusted_networks and
internal_networks what causes SPF to misfire...
>>> Thank you sincerely for your help. I can only imagine that SPF
>>> wouldn't
>>> fire if I accidentally specified Google in one of
> On 2/16/2012 4:54 PM, email builder wrote:
>>> but it's misconfigured trusted_networks and
>>> internal_networks what causes SPF to misfire...
>> Thank you sincerely for your help. I can only imagine that SPF wouldn't
>> fire if I accidentally specified Google in one of those settings or ha
>
> On 2/15/2012 7:08 PM, email builder wrote:
>> OK, but: Q: Are there any default rules as supplied by sa-update that would
>> prevent SPF rules from firing?
> Not that I can think of.
>>
>> Q: Any other ideas on how to learn what rules are actually being used?
> What I would likely do is s
On 2/16/2012 4:54 PM, email builder wrote:
>> but it's misconfigured trusted_networks and
>> internal_networks what causes SPF to misfire...
> Thank you sincerely for your help. I can only imagine that SPF wouldn't fire
> if I accidentally specified Google in one of those settings or had an error
>
>>> Q: Will some rules not fire if some condition exists based on other
>>> rules?
>>>
>>> A: Correct. There are plenty of rules that build on other rules. We
>>> call these
>>> meta rules.
>>
>> Q: Are there any default rules as supplied by sa-update that would
>> prevent SPF rules fr
On 2/16/2012 6:14 AM, Kevin A. McGrail wrote:
Couldn't begin to tell you. This sounds like some sort of panel for
hosting and is far outside of the SA project.
I wonder if perhaps it's logging the TO field as though that has
something to do with where the message will be delivered?
--
Dave
tagg...@riseup.net wrote:
Hi SA users,
In the past (3.2.5 or so) I used to be able to use local.cf to override
rule settings like this,
header __RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen
Hi SA users,
In the past (3.2.5 or so) I used to be able to use local.cf to override
rule settings like this,
header __RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '127.0.0.[45678]')
On 02/15/2012 04:43 PM, Thomas Rutter wrote (as neon_overload):
> I have created some rules which I have found to be very effective so
> far at identifying a certain type of spam that spamassassin
> otherwises cannot detect.
> I hereby license them under the WTFPL which is GPL and Apache license
On 2/16/2012 9:12 AM, netcapacity wrote:
Without an example, your statements are not clear to me. Can you cut
and paste what you saw?
Regards,
KAM
I understand. On the server statistics I can see what email addresses are
being used and filtered. Since this is a new installation I only ha
> Without an example, your statements are not clear to me. Can you cut
> and paste what you saw?
>
> Regards,
> KAM
>
I understand. On the server statistics I can see what email addresses are
being used and filtered. Since this is a new installation I only have 2
email addresses set up.
On 2/16/2012 6:44 AM, netcapacity wrote:
While checking the stats on a new installation I looked at the recipients
list. On the list was an email address that did not reside on my server.
Where did it come from? What exactly is it? Any ideas of where it came from
and any actions I need to take
On 2/15/2012 7:08 PM, email builder wrote:
OK, but: Q: Are there any default rules as supplied by sa-update that
would prevent SPF rules from firing?
Not that I can think of.
Q: Any other ideas on how to learn what rules are actually being used?
What I would likely do is save the gmail message
While checking the stats on a new installation I looked at the recipients
list. On the list was an email address that did not reside on my server.
Where did it come from? What exactly is it? Any ideas of where it came from
and any actions I need to take are appreciated.
--
View this message
Hi Kevin McGrail,
Was there any response on the dev list about this? I am not
subscribed to it.
I notice that RCVD_IN_MSPIKE_WL is listed in the updates:
# find -exec grep MSPIKE_WL \{\} \; -ls
meta RCVD_IN_MSPIKE_WLRCVD_IN_MSPIKE_H5 || RCVD_IN_MSPIKE_H4 ||
RCVD_IN_MSPIKE_H3
describ
Q: Will some rules not fire if some condition exists based on other rules?
A: Correct. There are plenty of rules that build on other rules. We call these
meta rules.
On 15.02.12 16:08, email builder wrote:
Q: Are there any default rules as supplied by sa-update that would
prevent SPF rules f
I need to whitelist a sender, and I typically use whitelist_from_rcvd,
but it's not working in this case, and I suspect because rDNS fails:
Received: from ideascollide1.ablehost.com (unknown [208.81.177.83])
Is the next best approach to create a rule that deducts points or is
there another wa
24 matches
Mail list logo
