Wild hair

2024-09-25 Thread jdow
I've been running SpamAssassin for longer than seems realistic (2.28 with 1998 
Red Hat Hurricane?). Anyway I have started moving everything mail to yet a new 
machine, Ubunto LTS 24.04.01. That only supports SA 4.0.0. I've been 
contemplating the pain of sideloading 4.0.1 into the system. Then I noticed 
single user installs. That seems like a good way to keep a stable 4.0.0 mail 
server running that updates when Ubuntu gets around to it and a work 4.0.1 for 
Loren writing his rules.


Is such an attempt likely to blow up in my aged face or is it likely to work 
like it I intend?


{^_^}   Joanne


Re: Score 0.001

2024-05-12 Thread jdow

Um, "FORGED_SPF_HELO"? Are you sure this message is from MS?

{^_^}

On 20240512 06:56:59, Thomas Barth wrote:

Am 2024-05-12 12:39, schrieb Greg Troxel:

I would suggest that if Debian is modifying the default config from 5 to
6.31, then probably they should not be doing that.


This is a status of dmarc-report from microsoft today

X-Spam-Status: Yes, score=5.938 tagged_above=2 required=6.31
    tests=[ARC_SIGNED=0.001, ARC_VALID=0.001, BASE64_LENGTH_78_79=0.1,
    BASE64_LENGTH_79_INF=2.019, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1,
    DKIM_VALID=-0.1, DMARC_PASS=-0.001, FORGED_SPF_HELO=1, HTML_MESSAGE=0.001,
    MIME_BASE64_TEXT=0.001, MIME_HTML_MOSTLY=0.1, MPART_ALT_DIFF=0.724,
    PYZOR_CHECK=1.985, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001,
    T_TVD_MIME_NO_HEADERS=0.01]

A strike level of 5 is too low for microsoft mails ;-)

Re: Score 0.001

2024-05-11 Thread jdow

On 20240511 14:56:51, Greg Troxel wrote:

Thomas Barth  writes:


Am 2024-05-11 21:54, schrieb Bill Cole:

I have no idea who the Debian "spam analysts" are but I am certain
that they are not doing any sort of data-driven dynamic adjustments
of scores based on a threshold of 6.3 nor are they (obviously)
adjusting that threshold daily based on current scores.

I found the passage in my old Postfix book. The author writes: "It is
recommended not to carelessly set the value of $sa_kill_level_deflt to
any fantasy values. The score of 6.31 is not arbitrarily chosen, but
the statistically calculated optimum for the best possible spam filter
rate with as few false positives as possible. If you increase the
value, more spam will get through; if you lower it, your false
positives will increase."

The comments about adjustments are true, but the idea that it is optimum
is flat-out nonsensical.

The key question is how you weight a false positive compared to a false
negative.  Only after you decided that can you pick an optimium, for a
given corpus of already-received mail.


It may be that the value is outdated, but that is for the maintainers
of the relevant Debian package to decide. I'll just adapt my rules to
this one value.

That is an odd position.  It is very easy to set the threshold in a
local config.   Deciding instead to adjust scores to an oddball
threshold seems bizarre to me.

Personally, I don't use the 5, but instead have shades of grey, where

=1 is binned into mailboxes that are "maybe spam" through "very likely"

spam, and at some score, I reject at the MTA level.

I find that legit mail shows up in e.g. spam.2 (>= 2 and < 3), but it is
almost never mail that I would be upset to have missed (but I don't) or
mail that I would be upset to not get in a timely manner (I only see it
every day or so).  However, this really drops the FN rate of spam in my
INBOX, which matters a lot to me.Basically I consider a FP into my
"spam.1" mailbox, as long as it isn't really important to me, to be not
a big deal at all, and I'd rather have 10 or those than 1 FN in my
INBOX.  But, actually MTA-rejecting mail that I shouldn't, a FP at that
level, is a big deal, and I avoid it.  I think it's about one message a
year -- and while it's ham, it's very spammy ham.


Methinks this is a perfect example of "one man's spam is another man's ham." Or 
in my case, "A woman's spam is often a man's ham."


{^_-}   <- hopelessly square and antiquarian by today's standards. e.g. the 
XXXlist wars.


Re: Score 0.001

2024-05-10 Thread jdow

On 20240509 23:57:12, Thomas Barth wrote:

Am 2024-05-10 06:19, schrieb Reindl Harald (privat):

Am 10.05.24 um 00:05 schrieb Thomas Barth:

Am 2024-05-09 21:41, schrieb Loren Wilton:
Low-score tests are neither spam nor ham signs by themselves. They can be 
used in metas in conjunction with other indicators to help determine ham or 
spam. A zero value indicates that a rule didn't hit and the sign is not 
present. A small score indicates that the rule did hit, so the sign it is 
detecting is present.


0.001 seems to be the default lowest value. Is it possible to change it to 
0.01 or 0.1?


what do you not understand in meta tests?
it's irrelevant if it's 0.001 or 0.01

these rules are used in combination with other rules

HTML_MESSAGE or SPF_HELO_NONE alone don't mean anything and so it must not 
score higher - it makes only sense combined with other rules


Most of the messages I receive only have a few hits because they hardly differ 
from a regular e-mail. That's why I want to assign a higher value to the 
individual tests. I don't know how many of the possible tests with a value of 
only 0.001 exist. With this value, theoretically 1000 different tests would 
have to be positive in order to achieve a total value of 1. Therefore, it is 
not irrelevant whether I have a minimum value of 0.001 or 0.1. I would even go 
further and say if there are more than 10 tests with a positive value: Spam! 
Either the strike level is reached or there are more than 10 tests with a 
positive value. So now I repeat my question: is it possible to increase the 
minimum value to 0.1 by default?


Values like .001 are generally used for meta rules. I use meta rules chiefly to 
combine multiple relatively benign tests into something significant when they 
all appear at once. (Or variations on that theme.) The tiny minimum score 
assures the rule gets processed and reported but has minimalist contributions to 
the overall score. If you want a minimum score of 0.004, 0.01, 100, whatever 
then use a "score" line associated with your rule. That saves you from the 
fruits of being too lazy to give a real score to a rule that is important to get 
just right.


{o.o}


Re: Score 0.001

2024-05-09 Thread jdow

On 20240509 15:05:46, Thomas Barth wrote:

Am 2024-05-09 21:41, schrieb Loren Wilton:
Low-score tests are neither spam nor ham signs by themselves. They can be 
used in metas in conjunction with other indicators to help determine ham or 
spam. A zero value indicates that a rule didn't hit and the sign is not 
present. A small score indicates that the rule did hit, so the sign it is 
detecting is present.


0.001 seems to be the default lowest value. Is it possible to change it to 
0.01 or 0.1?



1) This cyberunit is unwarrantedly curious, why does this matter to you?

2) Probably not as  it may be related to how perl handles numbers.

{^_^}


Re: Defining what the default welcomelist means

2024-04-12 Thread jdow

On 20240412 16:14:44, Greg Troxel wrote:

jdow  writes:


One pesky detail still exists. There is a very broad fuzzy area where
my spam is your ham and vice versa. You could probably drive yourself
to an early grave trying to get the perfect Bayes training plus
perfect rule set.

spam is bulk and unsolicited.   So yes the same message could be either,
but if a sender spams anyone, they are spammer, even if they send mail
that isn't spam.


Ah, no, that way leads to disaster. Some people resign from lists by declaring 
the sender spam. That could end up cutting access to all the people who want the 
emails. (At various times this list and most 'ix lists were unusually difficult 
to resign from. And, yes, I have been around that long. I'm just too politically 
incorrect for most lists these days, {^_-}) It is wise to be careful about how 
soon you pull the "spammer" trigger. YMMV and YAMV (Attitude).


{^_^}


Re: Defining what the default welcomelist means

2024-04-12 Thread jdow

On 20240412 15:56:15, Greg Troxel wrote:

I see it very slightly differently, but mostly agree

Bill Cole  writes:


1. We serve our users: receivers, not senders. Senders claiming FPs
need the support of a corroborating would-be receiver.

Agreed.  Or maybe we take requests to add only from receivers.


2. If senders have FPs on objectively legitimate mail, their first and
most important step is to identify WHY SpamAssassin thinks it is
spam. and address that. Do you need the invisible text? Is the message
embedded in a remotely-fetched image? The sea of "&zwnj" entities in
your messages' HTML serves what purpose exactly? If there's a real FP
problem with some rule that regularly is proved out by RuleQA, open a
bug.

Sure, but if you serve receivers, often people will have misfiling and
the sender is opaque, even if not spam and dkim.  So saying the sender
should fix is misaligned with serving receivers.  Yes, they *should*,
but people shouldn't send html mail either :-)

I agree that requests from senders should be met with "make your mail
less spammy".


3. This is NOT a general-purpose reputation list. It exists to aid SA
users who have FPs from SpamAssassin default rules for wanted mail,
where we cannot determine any acceptable adjustment to rules which
would avoid the problem. It is a "last resort" form of FP mitigation
when we cannot find an acceptable general solution that isn't
domain-specific to a widely accepted sender domain.

I see all spam classification as probabalistic and there is risk of FP.
If a domain emits *only ham* and is dkim signed, and we believe that
receivers want it, I think it makes sense to have it in.

I think of things like alerts from banks, airline saying your flight
time has changed, etc. where FPs are a real problem.

I am extremely skeptical of anything that smells of email marketing
here.  I would expect only places sending transactional mail and alerts
to established customers.


4. We should only add or remove listings based on specific requests
backed by transparent evidence. Subversion commit messages are not
enough, we need a bug report or a mailing list discussion.

sure


5. Existing entries are presumed valid unless and until they cause a
false "ham" classification of spam which can be shared publicly in a
useful form.

I guess, or if someone makes an argument that they aren't right.


6. New entries must pass prolonged RuleQA testing of sender-specific
rules before being added to the default welcomelist.

I don't follow this.  Do you mean add 'def_welcomelist_dkim foo@bar' to
a testing ruleset and see if it's ok?  That seems fine if so.  If not, I
didn't follow you.


It might also make sense for each welcomelist rule to have a score.
Basically to bring the mail down to -2, to give it some headroom.   But
that might be too complicated compared to benefit.


One pesky detail still exists. There is a very broad fuzzy area where my spam is 
your ham and vice versa. You could probably drive yourself to an early grave 
trying to get the perfect Bayes training plus perfect rule set.


{o.o}   Joanne


Re: dkim-test valid but spamassassin scores DKIM_INVALID

2023-10-25 Thread jdow


On 20231024 23:46:18, Niels Kobschätzki wrote:

Matus UHLAR - fantomas  hat am 25.10.2023 08:16 CEST 
geschrieben:

  
On 25.10.23 07:21, Niels Kobschätzki wrote:

I'm having here a mail that scores as DKIM_INVALID.  I tried sending the
same mail to gmail for example and it tells me that DKIM is valid.  Now I
put it through "spamassassin -D" and I am even more baffled because the
debug seems to say that DKIM is valid but then scores as INVALID.
Any idea why this could be?

debug-output from "spamassassin -t -D dkim < message":

Oct 25 07:10:52.341 [1687666] dbg: dkim: VALID DKIM,i=@my.domain.com, 
d=my.domain.com, s=inx, a=rsa-sha256, c=relaxed/relaxed, key_bits=2048, pass, 
matches author domain
Oct 25 07:10:52.342 [1687666] dbg: dkim: signature verification result: PASS
Oct 25 07:10:52.342 [1687666] dbg: dkim: adsp not retrieved, author domain 
signature is valid
Oct 25 07:10:52.342 [1687666] dbg: dkim: adsp result: - (valid a. d. 
signature), author domain 'my.domain.com'
Oct 25 07:10:52.352 [1687666] dbg: dkim: VALID signature by my.domain.com, 
autho...@my.domain.com, no valid matches
Oct 25 07:10:52.352 [1687666] dbg: dkim: autho...@my.domain.com, not in any 
dkim whitelist
Oct 25 07:10:54.125 [1687779] info: util: setuid: ruid=0 euid=0 rgid=0 0 egid=0 0
Oct 25 07:10:54.364 [1687666] info: rules: meta test DKIM_INVALID has 
dependency 'DKIM_VALID' with a zero score

did you set score of DKIM_VALID do 0 ?

DKIM_VALID is not overwritten by any of my local rules. So I would expect that 
this is the case. But even if I set for example

score DKIM_VALID 0
in local.cf there is no change

Best,

Niels


Methinks you have here a very good clue to set a non-zero value, perhaps (most 
likely), a modest negative score.


{o.o}   Diving back into obscurity


Re: Sudden surge in spam appearing to come from my email address

2023-07-15 Thread jdow

On 20230715 20:20:03, Thomas Cameron wrote:

On 7/14/23 23:59, Loren Wilton wrote:
I am suddenly getting hammered by a BUNCH of spam that appears to be from 
me. It scores low, and even though I keep feeding it to Bayes, it's still 
not hitting the threshold to be marked as spam.


When I check the headers, it's coming from multiple random email servers, 
but many appear to originate from hotmail/outlook.com. So from outlook.com, 
through some unsecured email server, then to my server.


SA can't block this trash by itself, but if something post the SA invocation 
can look at the headers you might be able to block it. You can certainly mark 
it as spam.

For instance:

#
# Ok, catch 'from me' when it isn't

header __FROM_ME_1 From =~ //i
header __FROM_ME_2 From =~ /\"First Last\" /
header __FROM_ME_3 From =~ /First Last /
meta NOT_FROM_ME __FROM_ME_1 && !(__FROM_ME_2 || __FROM_ME_3)
score NOT_FROM_ME 10
describe NOT_FROM_ME Spammer faking the mail from me!

Mind the backslash on the quotes and at sign. Depending on versions of things 
these are necessary, and don't hurt if they are not necessary.


Forgive my ignorance, I haven't really played with custom rules before. Are 
the entries like //i meant to edited for my actual 
email address and domain, or does "me" and "@myhost" get expanded somehow? I 
actually use sendmail for bunch of domains on my mail servers, and I want to 
make sure this will work for all those domains.


I assume this just needs to go in /etc/mail/spamassassin/local.cf, right? Or 
do I need to do separate stanzas for each domain?


Thomas



Edit your username for "me", and your hostname plus most of its domain for "my 
host" and probably you can change .net to match your TLD. And "first last" would 
be your first name and last name as appears in emails.


I do it basically the same way Loren does. You are creating a rule or rules to 
match your legitimate email address. That is the _FROM_ME_n stuff. Then you are 
creating a meta rule that looks for email that claims to be from your raw email 
address that does not have the correct formats for your outgoing email. If it 
has your raw address but lacks your name components it fires off a score of 10. 
The oddity at the end of the first rule is something I treat differently but the 
concept is the change. Legitimate user accounts at Earthlink all end with .net. 
So if it ends in .com it is automatically a dumb spam. My rules are a little 
different. But the concept is the same.


{^_^}


Re: Facepalm

2022-11-24 Thread jdow


On 20221124 00:42:22, Marc wrote:

I accidentally forwarded one (or more) messages to the SpamAssassin
mailing list which I meant to forward to SpamCop. High-latency remote
control, address prefix collision, and lack of sleep are contributing
factors.

I will update address books to reduce likelihood of collisions in the
future.

To those that asked if I was mentally ill, I don’t think so. Rather I
think this was an honest mistake. All be it one with considerable egg on
my face.  Also, please reframe from as hominem attacks as they are
unnecessary.

You should be including a bitcoin address, so we can buy you a coffee ;)


Past a certain point more coffee means you are sleeping with your eyes wide 
open. Somebody needs to purchase an extra hour or two per day. Personally I'd 
love it if the Earth had about a  30 to 32 hour day. But, then, I'm probably not 
really an Earthie.


{^_-}


Re: Enabling USER_IN_BLOCKLIST

2022-10-18 Thread jdow

And "gabor.sz...@gmail.com" can stuff his mail setup where the sun doesn't 
shine.

{^_^}

On 20221018 16:23:26, jdow wrote:

On 20221018 07:29:49, Laurent S. wrote:

On 3.4.X, adding those rules should be enough:

score   URI_HOST_IN_BLOCKLIST 100.0
score   URI_HOST_IN_BLACKLIST 0
score   URI_HOST_IN_WHITELIST 0
score   URI_HOST_IN_WELCOMELIST   -100
score   USER_IN_BLOCKLIST 100.0
score   USER_IN_BLACKLIST 0
score   USER_IN_WELCOMELIST   -100.0
score   USER_IN_WHITELIST 0

You should put them in your LOCAL_RULES_DIR. For most users, it is in 
/etc/mail/spamassassin. Adding them to local.cf is probably a good place.

Jdow, don't change stuff directly in /var/lib/spamassassin and don't recommend 
others to do so. Nothing is broken because of that renaming, except your ego.


I'm sorry you read it that way. My intent was to provide documentation that 
could lead to understanding what was going on. You are correct, use user_prefs 
or local.cf or a custom XXX.cf file in the appropriate place for local.cf. 
(Specifically I'd have it in with the surviving SARE rules I use.)


{^_^}


Re: Enabling USER_IN_BLOCKLIST

2022-10-18 Thread jdow

On 20221018 07:29:49, Laurent S. wrote:

On 3.4.X, adding those rules should be enough:

score   URI_HOST_IN_BLOCKLIST 100.0
score   URI_HOST_IN_BLACKLIST 0
score   URI_HOST_IN_WHITELIST 0
score   URI_HOST_IN_WELCOMELIST   -100
score   USER_IN_BLOCKLIST 100.0
score   USER_IN_BLACKLIST 0
score   USER_IN_WELCOMELIST   -100.0
score   USER_IN_WHITELIST 0

You should put them in your LOCAL_RULES_DIR. For most users, it is in 
/etc/mail/spamassassin. Adding them to local.cf is probably a good place.

Jdow, don't change stuff directly in /var/lib/spamassassin and don't recommend 
others to do so. Nothing is broken because of that renaming, except your ego.


I'm sorry you read it that way. My intent was to provide documentation that 
could lead to understanding what was going on. You are correct, use user_prefs 
or local.cf or a custom XXX.cf file in the appropriate place for local.cf. 
(Specifically I'd have it in with the surviving SARE rules I use.)


{^_^}


Re: Enabling USER_IN_BLOCKLIST

2022-10-17 Thread jdow
Go find the rule in the rule sets. In my old SL7 install I get a bundle more 
than makes sense with a simple  "sudo grep -r USER_IN BLACKLIST 
/var/lib/spamassassin". People with more prejudices than good sense decided 
"BLACK" in a rule name is R*A*C*I*S*T so they broke everything renaming it 
"BLOCK". So change any rules YOU may have that say USER_IN_BLACKLIST to 
USER_IN_BLOCKLIST so the block heads are happy.


I'll go crawl back in my hole of hates needless controversy and leave the rest 
to you and others. I'm racist because I'd rather spend effort on something 
productive after dealing with a government jerk over the term of art "fork". 
Basically we were told to do the impossible and "get the fork out of there," 
That wasted about $100,000 of our time that could have been used to make the 
product work better. After the ensuing problems we went back to the unmodified 
version of GRiD-OS and magically everything worked again. The waste was 
offensive - in that case and this one.


{o.o}

On 20221017 09:42:39, Roberto Puzzanghera via users wrote:

Hello,
I have plenty of these in my headers

0.0 USER_IN_BLOCKLIST  From: user is listed in the block-list
100 USER_IN_BLACKLIST  DEPRECATED: See USER_IN_BLOCKLIST

but I don't know how to get USER_IN_BLOCKLIST working in place of 
USER_IN_BLACKLIST.


Any help appreciated

Greetings, Roberto

Re: Enabling USER_IN_BLOCKLIST

2022-10-17 Thread jdow
Go find the rule in the rule sets. In my old SL7 install I get a bundle more 
than makes sense with a simple  "sudo grep -r USER_IN BLACKLIST 
/var/lib/spamassassin". People with more prejudices than good sense decided 
"BLACK" in a rule name is R*A*C*I*S*T so they broke everything renaming it 
"BLOCK". So change any rules YOU may have that say USER_IN_BLACKLIST to 
USER_IN_BLOCKLIST so the block heads are happy.


I'll go crawl back in my hole of hates needless controversy and leave the rest 
to you and others. I'm racist because I'd rather spend effort on something 
productive after dealing with a government jerk over the term of art "fork". 
Basically we were told to do the impossible and "get the fork out of there," 
That wasted about $100,000 of our time that could have been used to make the 
product work better. After the ensuing problems we went back to the unmodified 
version of GRiD-OS and magically everything worked again. The waste was 
offensive - in that case and this one.


{o.o}

On 20221017 09:42:39, Roberto Puzzanghera via users wrote:

Hello,
I have plenty of these in my headers

0.0 USER_IN_BLOCKLIST  From: user is listed in the block-list
100 USER_IN_BLACKLIST  DEPRECATED: See USER_IN_BLOCKLIST

but I don't know how to get USER_IN_BLOCKLIST working in place of 
USER_IN_BLACKLIST.


Any help appreciated

Greetings, Roberto

LONGLN_LOW_CONTRAST

2022-05-13 Thread jdow
Has anybody else noticed this rule is hitting rather often since Thunderbird has 
changed to a gray fond rather than black font for their default?


{o.o}


Re: "Please send us a quote..."?

2021-04-05 Thread jdow
lso figure it's nearly free to email everybody in a loosely, often very loosely, 
defined geographic area. A microscopic number of such emails hit a marketdroid 
or a CEOdroid whose brain misfires at the thought of a new contract. Then the 
scam is on.


This is a question I keep asking myself. I have to rerun the swag level 
computations in my head again.You send 100 million emails. Half of them go to 
second and third accounts the same person owns, perhaps. So you have fifty 
million emails. One in 100,000 might hit the real target audience and one on ten 
of those may reply. Depending on the scam even one reply can feed the scammer 
for a year or more. I call it my "firebug" calculation. If they are one in a 
million the Los Angeles California area has more than ten of them lurking around 
for optimum fire conditions. That's a good part of how we burn ourselves up each 
year.


{o.o}

On 20210405 19:18:25, Bill Cole wrote:

On 5 Apr 2021, at 21:30, John Hardin wrote:

Can anybody explain to me the reason behind the blind "please send us a quote 
for your product X" emails? I mean, I know they are somehow a scam, but I 
can't figure it out how it's supposed to work when the target isn't a 
business...


A vast amount of spam can only be explained by including the fact that 
spammers are for the most part not very bright.


Most examples of that which I have in my archives include lures to get the 
target to download a "real" RFQ/RFP file or otherwise visit some website of 
indeterminate legitimacy. The others are indeed impossible to understand 
without postulating that the sender truly has no idea who they are mailing.






Re: Are X-MC-xxx headers legit?

2021-03-28 Thread jdow

Thank you, sir.

{^_^}

On 20210328 21:29:55, Kevin A. McGrail wrote:

Ahh, I was dense.  the X-MC headers are mailchimp
https://mailchimp.com/developer/transactional/docs/smtp-integration/ 
<https://mailchimp.com/developer/transactional/docs/smtp-integration/>

--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail <https://www.linkedin.com/in/kmcgrail> - 
703.798.0171



On Mon, Mar 29, 2021 at 12:26 AM jdow <mailto:j...@earthlink.net>> wrote:


That is well known. Now, who is using the X-MC-xxx header set and are they
legitimate?

{^_^}

On 20210328 21:20:17, Kevin A. McGrail wrote:

Loren,

See https://tools.ietf.org/html/rfc6648
<https://tools.ietf.org/html/rfc6648> but basically for email think of X-
as local headers, 100% allowed, do whatever you want with them, no one
should pay any attention unless you publish what they mean. Lots of
places, my firm included, add X-* headers for various purposes.

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail
<https://www.linkedin.com/in/kmcgrail> - 703.798.0171


On Sun, Mar 28, 2021 at 11:08 PM Loren Wilton mailto:lwil...@earthlink.net>> wrote:

I've started seeing a number of spams with the following block of X
headers
in it. I've never seen these before. While these look really fake to me
(from the content of most of them), does any real tool or site make
headers
like this, or are they just from some spam tool and I can use them as a
guarantee of spam?

x-mcpf-jobid: mc.us6_13712451.1216993.5a2d921a72084.full_03
X-MC-User: 6b669534c4be2b401d8744486
X-MC-Tags:45829
X-MC-Track:456
X-MC-Autotext:global
X-MC-AutoHtml: format
X-MC-Template: smiley
X-MC-MergeVars: {"_rcpt": "emailadr...@domain.com
<mailto:emailadr...@domain.com>", "fname": "John",
"lname":"Smith"}
X-MC-GM-Analytics: normal
X-MC-GoogleAnalyticsCampaign: good
X-MC-Metadata: { "user_id": "45829", "location_id": "111" }
X-MC-URLStripQS:   link to 
X-MC-PreserveRecipients: 123
X-MC-InlineCSS:  used
X-MC-Subaccount: sendgrid
X-MC-ViewContentLink: {uurl}
X-MC-BccAddress: {ourl}
X-MC-Important: notes
X-MC-IpPool: 99%
X-MC-ReturnPathDomain: server1.tech
X-MC-SendAt: "AsianBeauties Team"
X-MC-MergeLanguage: {all language}
X-MC-MergeVars: {"var1": "global value 1"}
X-MC-MergeVars: {"_rcpt": "emailadr...@domain.com
<mailto:emailadr...@domain.com>", "fname": "John",
"lname":"Smith"}
X-MC-GoogleAnalytics: www.domain.com <http://www.domain.com>, domain.
X-MC-Metadata: { "user_id": "45829", "location_id": "111" }
X-MC-Metadata: { "group_id": "users_active" }
X-MC-Metadata: { "_rcpt": "f...@example.com <mailto:f...@example.com>",
"user_id": "123" }
X-MC-Metadata: { "_rcpt": "b...@example.com <mailto:b...@example.com>",
"user_id": "456" }
x-mcda: TRUE








Re: Are X-MC-xxx headers legit?

2021-03-28 Thread jdow
That is well known. Now, who is using the X-MC-xxx header set and are they 
legitimate?


{^_^}

On 20210328 21:20:17, Kevin A. McGrail wrote:

Loren,

See https://tools.ietf.org/html/rfc6648  
but basically for email think of X- as local headers, 100% allowed, do 
whatever you want with them, no one should pay any attention unless you 
publish what they mean. Lots of places, my firm included, add X-* headers for 
various purposes.


Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail  - 
703.798.0171



On Sun, Mar 28, 2021 at 11:08 PM Loren Wilton > wrote:


I've started seeing a number of spams with the following block of X headers
in it. I've never seen these before. While these look really fake to me
(from the content of most of them), does any real tool or site make headers
like this, or are they just from some spam tool and I can use them as a
guarantee of spam?

x-mcpf-jobid: mc.us6_13712451.1216993.5a2d921a72084.full_03
X-MC-User: 6b669534c4be2b401d8744486
X-MC-Tags:45829
X-MC-Track:456
X-MC-Autotext:global
X-MC-AutoHtml: format
X-MC-Template: smiley
X-MC-MergeVars: {"_rcpt": "emailadr...@domain.com
", "fname": "John",
"lname":"Smith"}
X-MC-GM-Analytics: normal
X-MC-GoogleAnalyticsCampaign: good
X-MC-Metadata: { "user_id": "45829", "location_id": "111" }
X-MC-URLStripQS:   link to 
X-MC-PreserveRecipients: 123
X-MC-InlineCSS:  used
X-MC-Subaccount: sendgrid
X-MC-ViewContentLink: {uurl}
X-MC-BccAddress: {ourl}
X-MC-Important: notes
X-MC-IpPool: 99%
X-MC-ReturnPathDomain: server1.tech
X-MC-SendAt: "AsianBeauties Team"
X-MC-MergeLanguage: {all language}
X-MC-MergeVars: {"var1": "global value 1"}
X-MC-MergeVars: {"_rcpt": "emailadr...@domain.com
", "fname": "John",
"lname":"Smith"}
X-MC-GoogleAnalytics: www.domain.com , domain.
X-MC-Metadata: { "user_id": "45829", "location_id": "111" }
X-MC-Metadata: { "group_id": "users_active" }
X-MC-Metadata: { "_rcpt": "f...@example.com ",
"user_id": "123" }
X-MC-Metadata: { "_rcpt": "b...@example.com ",
"user_id": "456" }
x-mcda: TRUE






Re: Has anyone heard of these people?

2021-03-17 Thread jdow



On 20210317 22:55:26, Benny Pedersen wrote:

On 2021-03-18 04:47, Bill Cole wrote:

On 17 Mar 2021, at 23:39, jdow wrote:


2(oO0)7.net all are registered to the same people.


Note that this is just 2 domains registrations: 2o7.net and 2O7.net
are the same thing.


spamassassin see it as X-Spam-Uri-Domains-Ham: 7.net

hmm


TO be fair in the original email it was a 0 so it's 207.net. If SA sees THAT as 
7.net you found a bug. Collect your trophy at the usually designated location.


{^_-}


Re: Has anyone heard of these people?

2021-03-17 Thread jdow

On 20210317 20:26:32, Benny Pedersen wrote:

On 2021-03-18 04:17, Bill Cole wrote:

On 17 Mar 2021, at 22:35, Loren Wilton wrote:


Has anyone come across 102.122.2O7.net before?


Ever heard of Adobe?

They do web-bugs in addition to graphics software.


+1

chrome://settings/content/siteDetails?site=http%3A%2F%2F102.122.2o7.net


Interesting, they have heavily protected that address for typo-squat attacks. 
2(oO0)7.net all are registered to the same people.


{^_^}


Re: Apache SpamAssassin and Spammers 1st Amendment Rights

2020-11-20 Thread jdow

On 20201120 18:35:35, noel.but...@ausics.net wrote:

On 2020-11-21 04:59, Jakob Curdes wrote:


To all: please also rememember that this list is international and not
every corner of the world is interested in the way the current
conflicts in the U.S. are handled.



well said!



Or, in other words, the Nth amendment is part of the U.S.
constitution, for me as a german  my own constitution is the
guide-rail. And yes, it allows me to block spam.
And yes, please let us keep politics out of this list.



and as an Australian, the right to block spammers was supported by the courts 
a very long time ago (those of us old enough i'm sure remember t3 direct who 
insisted he had the right to spam and not be blocked - but the courts ruled 
otherwise)


That said, our own Spam Act also excludes charities, pollies and religions - 
however we still have a right to filter/trash/block/not-deliver their trash to 
inboxes, its just those orgs cant be prosecuted.


It's worth noting that based on what these loud-mouths are saying they have not 
really read the US Consitution carefully in at least their lifetime. All they 
know is what their favorite pundit says the constitution says when said pundit 
is itself ignorant or is intentionally biased and trying to use outrage to 
increase viewership. Americans, at least, should read what they are prattling about.


{o.o}   ( <- has an unfortunate habit of revisiting those words rather often. So 
I am led to shake my head ruefully and laugh at the same time over the ignorance 
and extreme bias and indeed "projection" I've seen posted here.)


Re: the pending whitelist* -> welcomelist* change

2020-10-17 Thread jdow

On 20201017 10:58:13, RW wrote:

On Fri, 16 Oct 2020 23:18:16 -0400
Bill Cole wrote:


On 16 Oct 2020, at 21:06, Noel Butler wrote:


perhaps, the rules above should be defined only for version >=4
and versions <4 should have the original rules.

The rule name change is an artifact of how the rules are
version-controlled. We have exactly one version of the rules and it
resides in the trunk of the Subversion repository.

And that one version of rules has separate definitions for SA versions
that support "feature_blocklist_welcomelist" and those that don't.

There's no excuse for providing confusing information.



What does NOT work is to conflate the change in rule names with a
change in configuration directive names. They are different things.

That's not at all clear from the "describe" text displayed for 3.*. The
OP assumed it was time to switch configuration and that's perfectly
reasonable IMO.


It would be wonderful if I could simply do something like "define whitelist_from 
as welcomelist_from" and admit I am a racist as far as idiots whose opinions 
about me are beneath contempt are concerned. This whole thing is falling apart 
about the way I thought it would with this kind of fundamental political 
correctness minded change.


{+_+}


Re: Why the new changes need to be "depricated" forever

2020-07-22 Thread jdow

On 20200722 15:17:03, Ralph Seichter wrote:

* Charles Sprickman:


Rather than tolerate the tiniest of changes you throw a tantrum.


"Tiny changes", as in small stones getting kicked down a slope, causing
an avalanche. Attempts to restrict vocabulary should be a very familiar
and worrying concept to anyone who read Orwell. Speaking out against
this is very necessary. Silently tolerating stupid changes stems from
either weakness, lack of understanding or disinterest.

-Ralph


It is a technique that predated Orwell's story and even predated my birth. At 
the very least the Germans tried to frame their arguments by restricting 
vocabulary. Stalin certainly did. Mao certainly did.


I am glad somebody else feels this is as important an issue as I do.

{^_^}


Re: Why the new changes need to be "depricated" forever

2020-07-22 Thread jdow

On 20200722 00:28:22, Marc Roos wrote:



Oh my god, you snowflakes, please just get over yourselves.


The term "snowflake generation" was one of Collins English Dictionary's
2016 words of the year. Collins defines the term as "the young adults of
the 2010s, viewed as being less resilient and more prone to taking
offence than previous generations".

Do you get that it is the other way around? You are using this term
incorrectly?

Seems to me the snowflakes took offense to an imaginary manufactured "problem". 
The rest of us are taking offense at the snowflakes being so fragile and 
demanding. And do remember to discard any devices that might have an RMA color 
coded part inside.


{^_^}


Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread jdow

On 20200721 10:34:13, Grant Taylor wrote:

On 7/21/20 9:09 AM, Peter L. Berghold wrote:
This is the first time this long time lurker has posted here and I'm probably 
going to offend a lot of people by what I have to say.


I don't think your post is offensive.  It is said as a statement of facts and 
does not seem to contain any malicious intent.  Sometimes facts hurt.  Sometimes 
they don't.


I really don't get why anyone would be offended by blacklistd and whitelist 
given neither have any sort of connection to race or skin color.


I think that many people are ~> some of society is hypersensitive to the two 
five letter strings "white" and "black".  Some people are so hypersensitive that 
they can't see the forest (meaning of the words containing said five letter 
strings) for the trees (said five letter strings).


It is absurd in my opinion that there is a population going about that is 
offended by seemingly everything and sees racism where none exists.


I agree and share your opinion that it is absurd where people are ascribing 
racism where none has historically exists.


Will we be asked to rename "blacktop", which is a specific subset of asphalt?  
Or what about renaming the SR-71 Blackbird?  Or will White Castle need to 
rename, when the name was originally meant to reference clean and safe to eat 
at?  Or dare I say it, what about renaming the U.S.A.'s White House?


*NONE* of these three examples were named with any racism in them.  They were 
named based on the color of their appearance.


Sure, the White House may be associated with specific individuals, many of whom 
happened to be white, which have done some questionable things. But the occupant 
of the building has nothing to do with the building's naming.


What offends me more is the notion we have to wreak havoc in order to 
accommodate these thin skinned social warriors.


I am willing to consider new accepted norms for things going forward. (See 
below.)  I think that retroactively changing things because of a sub-string 
collision is fraught with errors.



Looking at a dictionary blog: https://www.macmillandictionaryblog.com/blacklist

there is no indication the term was racial at all.  A list of "objectionable 
or suspicious people" is not necessarily with regard to race.


I completely agree.

I wonder when these folks are going to want black and white as colors stricken 
from the English language?


IMHO completely removing the words is a very bad idea.  Lest we forget where we 
have been in the past, thus dooming us to repeat it in the future.


For better or worse, we are at an inflection point in society where society as a 
whole is deliberating the meaning and / or use of the terms "white" and "black".


"gay" had a significantly different meaning 100 years ago than it does today.  
Language, much like society grows, changes, and evolves.


I think that it is generally a good thing to use the current accepted words when 
creating new things.  But creating new is decidedly different than retroactively 
changing things that exist today.  That being said, I think that the majority of 
people would agree that we have not yet crossed the tipping point for "white" 
and "black".


Even if the meaning changed overnight — something that I think is unlikely to 
happen — there will be years of cohabitation of the old meaning and the new 
meaning of the words.


I hear that the old RMA resistor color code is under attack as it is 
exceptionally discriminatory. As you may or may not know black is the lowest 
value 0, brown is only 1, Red is 2. This must insult the blacks as being the 
lowest of the low. Mexicans must be screaming about being below American 
Indians. And even the Asians at 4 have a cause to claim discrimination because 
white is all the way up past twice the Asian value at (GASP) 9. The lordly 
whites obviously designed the RMA color code, published as EIA RS-279, to put 
all the other races down. So it MUST be abolished. Scrap all your color coded 
resistors. They are racist reminders of oppression!


{O.O}


Re: More Responses about Various Questions revolving around WelcomeLIst/BlockList changes

2020-07-20 Thread jdow

On 20200720 11:53:37, Kevin A. McGrail wrote:

*> Why make the change?*

I believe it's the right thing to do and you are going to see more of the 
ecosystem changing to.  I will not preempt the news but you are going to see 
this change pretty broadly.


So this is basically your doing. What I think of you and your arrogance and 
racism displayed in your wording above and the nature of the change is not 
suitable for this list. The schools that produced you are training natural born 
losers.


{^_^}


Re: Screwed-up scoring

2020-07-19 Thread jdow

On 20200719 15:44:54, Luis E. Muñoz wrote:

On 19 Jul 2020, at 10:54, Kevin A. McGrail wrote:


Great question.  That's really a third party rule.  I would like to see it
change eventually but maybe that's another phase.  Thoughts?


My thoughts are to delay any further social/political motivated name changes 
until after the extents of the current process are fully completed and 
understood. At that time, I would also suggest bringing in the opinions of the 
people who will bear the larger extent of the implementation – the users 
themselves – as well as the allegedly aggravated people on whose behalf you seem 
to favor the change.


Best regards

-lem


There is something to be said for running SL 7.x rather than something fancy and 
newer. I get to see other people have problems and have plenty of time to deal 
with them before they hit me.


{^_-}


Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

2020-07-19 Thread jdow




On 20200719 18:02:18, John Hardin wrote:

On Sun, 19 Jul 2020, Loren Wilton wrote:

In other words, support both "black" and "block", and "white" and "welcome", 
for at least 3 months, I suggest.


The bug report that introduced this change claimed 100% backward compatability 
for at least one year, later changed to until 4.0 came out, whenever that will 
be.


You're misreading that. Backwards compatibility in the code will be maintained 
for at least one year after the 4.0 release, when the code changes take effect, 
and would not be removed until 4.1 is released if it has not been released by 
that point (which is unlikely - 4.0 and 4.1 released within one year?). So if 
4.1 was released within a year of 4.0, it would include backwards compatibility 
and that would remain until at least 4.2


Unfortunately some rule name changes are making it out ahead of the 4.0 release. 
We're working on addressing this, it should be a temporary condition.


Am I granted an "I told you so?" The results coming out of this betray a 
breathtaking level of arrogance and overt racism.


{o.o}


Re: Thanks to Guardian Digital & LinuxSecurity for the nice post about SpamAssassin's upcoming change

2020-07-15 Thread jdow
Tokenism is a big thing in politics, probably everywhere on this planet. Gotta 
be seen as doing something, ya know. We need a third house in our legislature, 
the House of Repeals that strikes out dumb laws hastily drafted to appease loud 
mouths.


{o.o}

On 20200715 20:52:51, Noel Butler wrote:
I guess they're going to go back to the yellowish tinged incandescent bulbs too, 
since LEDs available today produce " white " light. They'll have to change their 
story books as well, cant call it after "dark" or "dark" night|skies|...



It's amazing how SOME Americans are quick to jump on bandwagons about innocent 
terms are called, yet FAIL to do ANYTHING about their population - even KIDS, 
getting slaughtered and gunned down nearly every second day in mass shootings. 
but you only have to look at how they are acting with COVID19 to know they have 
NFI about civil priorities.


No wonder the USA is the joke of the world - and its not all Trumps fault  <--- 
(jesus christ, I never thought I'd hear myself say that)



On 16/07/2020 13:37, Eric Broch wrote:

You're the ones who've moved, I've gone nowhere. You'll never run out of words 
to censor. Soon you'll be offended by everything. Where will you hide then. I 
don't know how you'll escape the planet when everyone and everything offends you.


More importantly calling those racists who are not racists is slander--bearing 
false witness against you neighbor--a violation of the 9th commandment. 
Instead of fearing God alone you adore the praise of wicked men.


On 7/15/2020 8:21 PM, Thomas Cameron wrote:


On 7/15/20 9:12 PM, Eric Broch wrote:


Using the word "blacklist" is racism. Does everyone get this! By definition 
you ARE a "RACIST" and ARE "White Privilege[d]."


This is a political movement to blacklist (oohhh, I said it) anyone 
who does not comply. We're no longer angry, we're "not excited," how generous.


The spamassassin leadership team are political hacks.



Don't let the door hit you on the way out, then.

Thomas



--

Kind Regards,

Noel Butler

This Email, including attachments, may contain legally privileged information, 
therefore remains confidential and subject to copyright protected under 
international law. You may not disseminate any part of this message without the 
authors express written authority to do so. If you are not the intended 
recipient, please notify the sender then delete all copies of this message 
including attachments immediately. Confidentiality, copyright, and legal 
privilege are not waived or lost by reason of the mistaken delivery of this 
message.




Re: Thanks to Guardian Digital & LinuxSecurity for the nice post about SpamAssassin's upcoming change

2020-07-15 Thread jdow

On 20200715 19:34:00, Noel Butler wrote:

On 16/07/2020 09:24, Kevin A. McGrail wrote:


All:

We're getting some positive attention from the verbiage change.  See
https://www.linkedin.com/posts/kmcgrail_apache-spamassassin-leads-a-growing-list-activity-6689260331719520256-gMy7
for a link to a Guardian Digital post about it.

Anyway, I hope those not excited by the change will come around.  We are
working hard to make it as painless as possible and we have gotten word
that several tools and projects that integrate with SpamAssassin will
follow suit.

Regards,

KAM



December 27 (our quietest time of year generally) this year has been slated for 
our changeover to remove spamassassin from our network.


Our policies have long excluded using politically motivated companies, 
organisations, equipment and software. you made this political, you do not care 
for the opinions of others unless they agree with yours, so adios amigos.


You can probably fork the project and go on running what exists now going 
forward. That is something I am mulling doing for myself. I just have to ask 
myself, which is more painful?


{o.o}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow
Sir, with all due respect, your extreme arrogance is exceptionally off putting. 
You imagine a problem. Then demand it be solved damn the consequences. You 
imagined the wrong problem. So your non-solution is doomed. Systemic racism is 
in YOUR head not MY head. Respect is in MY head. I am not sure it is in your 
head. Respect is the social lubricant you need not stupid word changes. It is 
sad you do not see this. And your sublime arrogance about it is rather off putting.


{o.o}

On 20200714 09:24:42, Kevin A. McGrail wrote:
We'll have to agree to disagree.  To me it is clearly racially charged language 
and you are cherry picking your sources.  Here's a well researched and 
documented article from a medical journal on the topic with expert citations: 
https://jmla.pitt.edu/ojs/jmla/article/view/490  The abstract says it very well: 
"This commentary addresses the widespread use of racist language in discussions 
concerning predatory publishing. Examples include terminology such as 
blacklists, whitelists, and black sheep. The use of such terms does not merely 
reflect a racist culture, but also serves to legitimize and perpetuate it."


I am proud to say I voted for this issue and support it as social issue, not a 
political issue.  However, I didn't do so unilaterally because that's not how 
projects at Apache work.


When the time comes for a 4.0 release, we, meaning the project management 
commitment, will follow our well documented voting procedures to create and 
approve a release announcement.  I have no interest in causing strife but if it 
quacks like a duck and walks like a duck, I will call it a duck.

--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 11:49 AM Rupert Gallagher > wrote:



 > racially-charged nature of blacklist

There is no such thing.

Black list originates from black book, that is a book with white pages and
black cover, with black ink, where sins are listed in haven for you to be
judged upon.

On the colour of the cover, it is black because that's how old leather turns
out to be.

On the colour of ink, try writing white ink on black paper if you can...

Stop using SA to push your political agenda. When v4 comes out, do not dare
writing that *we* decided to *change* blacklist into blocklist because of
the "racially-charged nature" of it, because it is not, because we said so,
and because you are forcing it.

Have the courage to put your own name under your own decision, do not blame
us for it.




Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow
Kevin, the mistake made every time this issue comes up, and I've seen since the 
N word letter was followed by egro, is the silly notion that changing 
nomenclature will change anything real when what is needed is more respect for 
what a person brings to a situation than manufactured respect for what they are 
physically. It implies very directly that a person who respects another for his 
accomplishments ignoring skin color is a de facto racist. You are sending 
exactly the wrong message. Respect a person for his abilities and character 
today. The past, the skin color, the number of properly working appendages, the 
presence or absence of hair on the head, the preferred partner choices, matter 
only in very specific circumstances. Respect for a person's abilities and 
character apply to every situation. Which does more good?


{^_^}

On 20200714 06:15:36, Kevin A. McGrail wrote:

Dave,

The goal of removing racially-charged language is to be more inclusive by being 
less offensive and more aware of the language we use without thinking.


Re: Apache naming, you are mixing up the duties of the Apache SpamAssassin 
Project with the Apache Software Foundation.  This is just an argument fallacy.  
My knowledge on the matter is that Brian Behlendorf, one of the ASF founders, 
reached out decades ago to discuss this with the Apache Nation council with all 
being good.  The only change is that in 2009, they asked us to standardize on 
referring to them as the Apache Nation but otherwise, there are no issues with 
the Apache name.  We are proud to use the name Apache and hope that our great 
work as a foundation brings it the honor it deserves.


Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 8:48 AM Dave Goodrich > wrote:


No, I am reading your words. The goal here is to remove language you, and
others, believe to be racially charged. To what goal, I cannot understand.

If you change whitelist/blacklist for the reason you have given, you must
change the name Apache and change it's logo. The root and origin of both are
not important, it is culturally insensitive to use the name Apache if you
are not a native American. To not go all the way with this would simply be
wrong.

DAve

- On Jul 14, 2020, at 8:28 AM, Kevin A. McGrail mailto:kmcgr...@apache.org>> wrote:

I think you are reading other people's take on things.  Clearer language
was an added bonus but never the reason.  The reason was to remove
racially charged language and 4.0 was a good opportunity to do it since
the major bump would allow for disruption.  Further, this article was
what reminded me to bring it up:

https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/
Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 8:23 AM Dave Goodrich
mailto:dgoodr...@greenfieldin.org>> wrote:

The wrong side of history? Are you kidding me?

I have been a long time user of Apache products. SA has been my go
to solution for decades. Until this morning, I was without opinion
on this issue and I even understood, and agreed, that the change had
merit for clarity. But, 'go along or be on the wrong side of
history' (sic) tells me this is not about a more clear and
understandable naming convention. This is posturing and pandering.

I am disappointed greatly. Very disappointed.

DAve

- On Jul 14, 2020, at 5:03 AM, Kevin A. McGrail
mailto:kmcgr...@apache.org>> wrote:

Marc and others about voting,

The ASF is a meritocracy not a democracy.  Voting privileges are
earned by demonstrating merit on a project.  That is the project
management committee aka the PMC.  Discussion with the PMC on
this change started in early April with a vote in early May by
the PMC.

To Marc, your Ad hominem attacks are not needed and I will
ignore messages that use them.

To you and others spouting off, be reminded that this is a
publicly archived mailing list and you will be on the wrong side
of history.  Consider that when you post.

Regards, KAM

On Tue, Jul 14, 2020, 03:51 Marc Roos mailto:m.r...@f1-outsourcing.eu>> wrote:


 > I never said it was being done for engineering reasons. 
The change is


   

Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow
They created a problem that was not there and then "solved it". Aren't they 
marvelous? Solving social problems by means of technical name changes does not 
solve either technical or social problems. This has been my experience 
repeatedly. Are we now not able to include a color in descriptions of technical 
features? What does that do to the black and white bands on resistor color 
codes? After all, white (9) is a higher number than black (1) which is, of 
course, blatant racial profiling, right?


What social problem is this supposed to solve? Is it real or is it made up? As a 
woman neologisms such as "hesh" and "hir" do not reassure me and make me more 
comfortable in the various technical communities I join because of my interests. 
A few times, not NEARLY as often as four decades ago or more, I've taken 
advantage of the fact you guys cannot see me and draw inferences mostly based on 
such technical expertise as I demonstrate. Then I let my being a woman leak out, 
I use my name in addition to my usual signature glyph. Some of the men cannot 
accept a woman being a peer. Recognition for expertise, ability, and knowledge 
is WAY WAY more important when you want to create an "inclusive" group than 
choice or pronouns. I figure I am included when people automatically presume I 
am part of "you guys" when they use that phrase. When I am accepted the pronouns 
drop out of importance.


I an not here to be a "gurl". I am here as somebody who commits sysadmin 
functions on a small two man* office for me and my partner. I can extrapolate 
the problems we will face to those people who perform system administration 
functions for collections of small businesses on a consulting basis. Customers 
will see their need to take actions or accept "somebody snooping on their 
settings" on the consultant. You guys at Apache are in the clear. The customers 
won't be charging their anger to your karma. I am not in technical groups to 
flaunt my femininity or lack there of. I am not here partner hunting. I am not 
here as a woman. I am here as a user who has some level of technical capability. 
I've not been demonstrating it lately because mostly it works and when it does 
not I make rules for myself that do work. And my partner is even better at 
making rules. Since SARE died sharing the rules has sort of fallen away. So I 
tend to be silent until I am faced with "it just works" quit working. I am 
human. I resent that imposition for reasons I rather consider spurious and 
utterly without technical merit.


I see a change being made to solve a phantom social problem pandering to some 
truly violent people some of whom brag about being trained Marxist agitators. 
That change causes technical and social problems for a class of your (admittedly 
non paying) customers to whom you pass along the need to make changes for no 
good technical reason. These violent people will never be appeased by changes 
you make. So why bother to make the changes? Rather ask, no demand, your lazy 
assed politicians to do their jobs.


As for the social problem, Kevin, I am afraid that as I see it you are a part of 
the problem not part of any applicable social or technical solution.


{^_^}

* "two man" is less typing than "two person" and less silly than any other three 
letter neologism that recognizes "man" is really "male" and "female" and 307 
different shades in between. Man means human here. That is something that so far 
is all inclusive. I do not expect that to last forever. The term has to grow to fit.


On 20200714 05:28:56, Kevin A. McGrail wrote:
I think you are reading other people's take on things.  Clearer language was an 
added bonus but never the reason.  The reason was to remove racially charged 
language and 4.0 was a good opportunity to do it since the major bump would 
allow for disruption.  Further, this article was what reminded me to bring it 
up: 
https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 8:23 AM Dave Goodrich > wrote:


The wrong side of history? Are you kidding me?

I have been a long time user of Apache products. SA has been my go to
solution for decades. Until this morning, I was without opinion on this
issue and I even understood, and agreed, that the change had merit for
clarity. But, 'go along or be on the wrong side of history' (sic) tells me
this is not about a more clear and understandable naming convention. This is
posturing and pandering.

I am disappointed greatly. Very disappointed.

DAve

- On Jul 14, 2020, at 5:03 AM, Kevin A. McGrail mailto:kmcgr...@apache.org>> wrote:

Marc and others about voting,

The ASF is a meritocracy not a democracy.  Voting privileges a

Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow

On 20200714 03:46:14, Mauricio Tavares wrote:

On Tue, Jul 14, 2020 at 5:54 AM Kevin A. McGrail  wrote:


I think you are focusing on the wrong part of my warning.  This is a public 
forum.  The public including search engines and reporters and employers and 
family can read it.  Minutes after a post is sent there are thousands and 
thousands of copies.


   In my book, that is veiled intimidation.


None the less it is a fact. And that fact does tend to keep normally cool minds 
from losing it. It's worth reminding ourselves, (looking annoyed, frustrated, 
and perturbed in equal measures) especially in this time of people not forgiving 
statements made 40 or 50 years ago as if people's opinions and behavior never 
really changes with maturity. That isn't "right". It;s a fact we all must live 
with until society matures a little more.


I gotta ask here, "Can't we all skip the ad hominem insults and stick to 
technical merits and goals involved in this change?" Please.


{o.o}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow
Please Marc, stick to technical merit for your argument. Getting nasty does not 
solve technical problems, which we have here. Attacks are not going to solve 
anything. Rational arguments may not. But, they should be made just the same. 
Then the open source developers will go off and do what they (think they) want. 
The job is to lead them to thinking they want something different for what they 
see as good reasons. Personally I believe the change is a technical failure and 
will not provide the social results they seem to desire. They should think about it.


{o.o}

On 20200714 02:57:19, Marc Roos wrote:
  





To you and others spouting off, be reminded that this is a publicly

archived mailing list and you

will be on the wrong side of history.  Consider that when you post.


You must be feeling like a king in your little PMC? Who are you to judge
whom is on the wrong side of history. No wonder people raise questions
here, with someone like you deciding things. I think the PMC should
disqualify your vote.



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow




On 20200714 02:03:06, Kevin A. McGrail wrote:

Marc and others about voting,

The ASF is a meritocracy not a democracy.  Voting privileges are earned by 
demonstrating merit on a project.  That is the project management committee aka 
the PMC.  Discussion with the PMC on this change started in early April with a 
vote in early May by the PMC.


That raises a question that deserves an answer. Who votes on whether somebody 
has earned merit? I suspect it is a closed system. {o.o}


To Marc, your Ad hominem attacks are not needed and I will ignore messages that 
use them.


I agree with you here. I am trying to keep my arguments on the technical merit 
of this change. I am trying to get them to reconsider their course of action. I 
am trying not to lay into them the way I'd love to. And I believe I have slipped 
a little. And I am extremely skeptical this change is going to make the project 
"more inclusive" and draw in new developers, which I believe was a stated 
non-technical aim.


To you and others spouting off, be reminded that this is a publicly archived 
mailing list and you will be on the wrong side of history.  Consider that when 
you post.


That would be wise. But, be aware that this may be taken as a combative threat 
by some people. Once you are trying to appease everybody you are doomed to 
failure. You find yourself trying to second guess which way to jump regarding 
how many of which people will be alienated. It is lose-lose. And it's 
heartbreaking to watch.



Regards, KAM


{o.o}



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow

On 20200714 00:31:19, @lbutlr wrote:

On 14 Jul 2020, at 01:22, jdow  wrote:

How does this move improve the technical quality of the product from the end 
users' perspective?


You've been told repeatedly that the decision has been made, and you have 
ignored everyone and attacked anyone who has posted on this any opinion that 
deviated from you WRONG opinion. No one cares.

Stop it.


Am I being bullied because you cannot answer a simple question?

I've been keeping my mouth shut until somebody aims a shot at me. At least have 
the grace to admit your changes have zero technical merit, may cause pain at the 
sysadmin and user level, and will happen anyway because of some nebulous social 
goodness from it. (Hint, betcha a nickle, my maximum bet, that it does not draw 
in more minorities to the development effort. OTHER problems need to be 
addressed at a social level.)


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-14 Thread jdow

On 20200713 20:10:36, Kevin A. McGrail wrote:

+pmc

So you are saying that to save somebody a passing bad feeling you are
throwing people under the bus who would have to edit scripts and pray.
What is the difference if it happens today or a year from now? What
Good Engineering Reason Is Served By This Pain?


Joanne,

I have no interest in debating you on this topic.

I never said it was being done for engineering reasons.  The change is
being done to remove racially-charged language from Apache
SpamAssassin.  As an open source project, we are part of a movement
built on a foundation of inclusion that has changed how computing is
done.  The engineering concerns are outweighed by the social benefits
and your huffing is not going to stop it.

The technical lift for a user will be an SQL query / perl one-liners to
search and replace your conf for things like whitelist_to to
welcomelist_to.  I'm sure the dev/user mailing list can come up with
some examples we can add to the UPGRADE file.  And if there are projects
that build on SA, they a year plus of warning to implement the coming
changes.  If you know of any programs/scripts that need help, point them
here or the dev list.

Regards,

KAM


user_prefs - every one will have to be edited to change names eventually. People 
will bitch when they have to edit their files. They will bitch of "root" goes in 
and edits the file for them (quite justifiably). Likely as not rules files will 
have to be repaired.


Engineering that is politically driven tends to be long term disasters. I've 
been around long enough to have seen it in action. Of course, that makes me an 
old irrelevant fossil. So you get to discover the same mistakes I discovered 
rather than benefit from inherited experience.


How does this move improve the technical quality of the product from the end 
users' perspective? It's a nightmare for sysadmins, "Do I save the customer the 
effort and modify HIS files or do I tell the customer she has to edit the arcane 
files?" One way he is damned for invading privacy. The other way he is ROUNDLY 
damned for making customer lives hardware. The change is not a long term win for 
anybody but those imagining "blacklist" and "whitelist" are racially related. 
Can't somebody just suggest they grow up? Or is that too good a technical 
quality solution?


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-11 Thread jdow

On 20200711 00:40:20, Luis E. Muñoz wrote:

On 10 Jul 2020, at 23:51, Bill Cole wrote:

"Terribly offended" is not what I've heard from anyone but the issue has
been raised by Black colleagues a few times in multiple contexts, as Yet
Another Minor Annoyance in a world stuffed full of such little things.

Reminds me of left-handed people back when I grew up. In my time children would 
use chairs with integrated tables that would be fit for /either/ right- or 
left-handed people. Since there were more right-handed children, left-handed 
people would have to be more creative to adapt.


So far we know:

  * Terms such as blacklist are a minor annoyance
  * There's no evidence of "how many people have thought less of SA" because of
the use of the term "blacklist"
  * The change has a very non-zero impact /everywhere/ the software is deployed,
as explained by other contributors to this ML

If you want a direct first-hand explication, hunt down the recent extended
rant on Twitter by Jackie Singh (@find_evil) triggered by the suggestion
that the Black Hat conference was considering a name change and the blowback
from that.

Sure, are you talking about this?

https://twitter.com/find_evil/status/1279945071371128834 – "The only person on 
that list who looks anything like me is the head of infosec at Fb"


In here she posts a poll asking whether you would apply to be part of a board 
composing by people that don't look like you – 
https://twitter.com/find_evil/status/1279948068411052045


I can't answer for everybody of course, but I would not care how the current 
members of a group I wanted to join look. I have been part of many groups that 
contained people that did not look like me – professional and otherwise. Up to 
that point in the thread, it seems to me as someone looking for excuses. If I 
missed something, please point me to it.


If I continue to look at her tweets, I find examples such as this: 
https://twitter.com/find_evil/status/1281735488437727233 – she seems surprised 
that someone would want to choose compatible people to work with. I don't know 
her or the context, and it is not my place to pass judgement, but I sincerely 
hope that whomever is in charge has better justification for this change than 
this lady's tweet rant.


I do not know the rules under which ASF and SAP operate, but this thread is 
evidence that the position you are defending is far from widely shared, and to 
me, looks very poorly justified.


Future software? Sure. Get rid of anything remotely offensive /the next time 
around/. Start by not using Assassin in the name, Apache in your organization 
and not mentioning any colors or university degrees. For existing, deployed, 
critical code? Don't change things to win cookie points.


Best regards

-lem



Female and an RF engineer. Look up what it took for that through 2000. I took up 
SW as a sideline hobby that bloomed on its own. And I was pretty unique among 
the people writing video software such as used in broadcast production 
facilities. "Adapt". Learn to dish it out as well as take it. I watched young 
men doing that so I did it. It worked. I am not averse to what works.


Looks like me? Maybe one or two out of a 100 or more who were not secretaries. I 
learned to bare my teeth at the mere suggestion that I go get the group some 
coffee. I learned to look VERY scary. It worked and engendered some humor. 
That's how I (over)learned to be assertive. I do not demand 50% of my peers be 
women. I simply demand that 100% of my peers carry their load. For THAT I am a 
racist fascist.


Screwit do what you will folks. It just hurts to see people take careful aim at 
their foot and shoot.


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-11 Thread jdow




On 20200710 23:51:19, Bill Cole wrote:

On 10 Jul 2020, at 20:02, Luis E. Muñoz wrote:


On 10 Jul 2020, at 12:29, @lbutlr wrote:

If people are so fragile that they have to hold on to terms that are 
extremely offensive to some of their peers, they will get more spam. Oh noes.


I keep hearing about this mythical people that get terribly offended by the 
use of these words. I've been working in IT since the 90s, and I've never 
actually seen one in real life. Do they really exist?


"Terribly offended" is not what I've heard from anyone but the issue has been 
raised by Black colleagues a few times in multiple contexts, as Yet Another 
Minor Annoyance in a world stuffed full of such little things. If you want a 
direct first-hand explication, hunt down the recent extended rant on Twitter by 
Jackie Singh (@find_evil) triggered by the suggestion that the Black Hat 
conference was considering a name change and the blowback from that.


When they get upset at words like blacklist I sit bemused if they bothered to 
sit back and learn the origination of the N-word. They are calling themselves 
black after deploring being called black. So the goal does not seem to be 
changing "blacklist". It is simply disruption. If it breaks something, who 
cares? Well, I care and don't want to have to fix the carnage from their 
(temporary) appeasement. This is particularly true since from here I cannot see 
the color of anybody's skin but my own. All I can see is accomplishments. That 
is what matters. And declaring that is racist is also declaring that you think 
some particular race needs special regard, making you a racist. It's a tricky 
word you cannot deploy without revealing it in yourself.


SA is free software. So I get exactly what I pay for, and usually a heck of a 
lot more. I'd hate to see it broken. That would break my regard for the 
development team, which has taken a couple heavy hits over the years but still 
remains relatively high. If having the high regard of users matters let it be 
known that another big dose of pain keeping it running will simply move me away. 
And there are tools which eventually would break even if foolist and barlist are 
synonyms with the latter created due to the former's bad connotations, which are 
not bad at all. Eventually foolist goes away or breaks and I have to diagnose 
the nonsense. And I am getting too old to bother with nonsense when email 
providers have filters I can suffer with or I can simply use something that 
works and never upgrade. Either way it would be a loss of one egoboost point to 
the developers for whatever that is worth. Bitter experience suggests changes 
with no good technical reason for them are dangerous.


{O.O}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-11 Thread jdow




On 20200710 17:02:02, Luis E. Muñoz wrote:

On 10 Jul 2020, at 12:29, @lbutlr wrote:

If people are so fragile that they have to hold on to terms that are extremely 
offensive to some of their peers, they will get more spam. Oh noes.


I keep hearing about this mythical people that get terribly offended by the use 
of these words. I've been working in IT since the 90s, and I've never actually 
seen one in real life. Do they really exist?


-lem


More importantly do they really matter? If they cannot take the discomfort off a 
word that they have translated into a false meaning I'd suggest they grow up and 
join the real world. Diverting resources from constructive use to a use that 
will introduce more points of failure in a working product for no tangible 
reward is counter productive.


(And over the years I've grown annoyed at the number of tools I built around 
spamassassin must be reinvented with updates. I finally gave up trying to keep 
auditing tools running. My favorite development hook from 2.x days vanished in 
3.x making diagnosing rule malfunctions messier. What will this NEW nonsense 
bring for my endless entertainment?)


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

1) You would not know fascism if it jumped up and bit your nose off.
2) You try to force your nonsense on me and I'll force my nonsense on you. 
Square?

{^_^}

On 20200710 15:26:49, Charles Sprickman wrote:

What makes you think anyone on the list wants to hear your complaints and your 
snide crypto-fascism?

Take it private or open an issue in the bug tracker.


On Jul 10, 2020, at 6:01 PM, jdow  wrote:

And every ancillary script sysadmins have written has to be rewritten. Every 
user_prefs has to be rewritten. You are forcing a boatload of hurt on innocent 
people. This is purely lifting a leg and peeing on something to mark it as 
YOURS. Isn't that rather selfish?
{^_^}

On 20200710 13:27:45, Kevin A. McGrail wrote:

Hello all,
A common question we are receiving is what about using this terminology
instead, for example allow/deny.
The use of welcomelist and blocklist has evolved from discussions since
April and work done creating patches.  We found that using these names
of welcomelist and blocklist are non offensive, reasonably descriptive
and since they still start with W and B, we avoid renaming things like
RBLs, WLBL, DNSBL, etc. This should help minimize the disruption when
4.0 is released with the new configuration options.
Regards,
KAM


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
I can just see the vocabulary Nazis forcing the world to change out red lights 
and yellow lights for more inoffensively named colors as they go out and rip 
down these statues to hierarchical control systems. These word Nazis CANNOT be 
appeased with simple changes in terminology. Their goal is to simply see the 
world burn so they can step in and take control. They are so ignorant of history 
they do not realize they are among the first for the gulags and firing squads 
they believe they will be running.


{+_+}

On 20200710 14:57:33, Eric Broch wrote:
No one has answered my question. What about the the word "Apache"?  Are their 
'redlist[s]' out there who'll be offended by this name?


For all the talk about giving SA more appropriate and descriptive names the 
motivation for changing them (whitelist, blacklist) was ultimately to be 
politically correct. Am I wrong?


Admit it, the SA community was never racist to begin with. It was some white 
guys trying to improve life for everyone. That's noble and commendable. This has 
been my goal in IT as well. Now is not the time to grovel to whiners, it's time 
to man up and continue to improve your product.


I'd like to see SA have as good a probability filter as DSPAM but with the 
ability to whitelist, which DSPAM does not have.



On 7/10/2020 3:25 PM, John Hardin wrote:

On Fri, 10 Jul 2020, sha...@shanew.net wrote:


On Fri, 10 Jul 2020, Axb wrote:


On 7/10/20 8:31 PM, Bill Cole wrote:

 The SpamAssassin Project has a particular self-interest in attracting
 contributors from a diversity of cultures, because we are always at risk
 of mislabelling a pattern of letters or words as 'spammy' when in fact it
 is entirely normal in a cultural context other than those of the existing
 contributors to the project. C


From what I see, until now, only two ppl of the SpamAssasin project have 
supported this motion and intend to impose this quatsch to the rest of the 
world.

Voices against these changes have been politely ignored.


The danger of judging the world only by what is within your sight is
that your field of vision is limited, and there are any number of
explanations for why what you see is not representative of the whole.

Maybe those who agree feel no need to comment.



Maybe a lot of people
on either side of the issue want to avoid adding more noise to a list
that's about SpamAssassin.


For me, this. But I do now feel I should contribute my 5¢ to the noise.

As a PMC member I did vote on the proposal when it came up a week or so back. 
I voted +1 with the strong condition that it include full backwards 
compatibility for a long time (ideally permanently), but that vote was reluctant.


I share the opinion that such terminology changes are "political correctness 
through newspeak" because the current terms are widely-known terms having a 
long standing without racist denotations or even connotations, and that those 
who are offended by them on that basis are the type of people who look for 
excuses to be offended. But my thought was if we can avoid that nonsense 
*without* greatly disturbing the project, we should probably do it.


But there is no technical reason whatsoever to make this change, and there are 
good technical reasons not to. I agree with Joanna 100%:


Political correctness has no place in engineering. Clarity of communications 
is a basis of the craft. When you disrupt it

things break.


and


Fixing what works is as fine a way to introduce new faults in
the code as I can think of.


I am rethinking my +1 vote for this change.




Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 13:58:32, Bill Cole wrote:

On 10 Jul 2020, at 3:38, Olivier wrote:


Axb  writes:


the US problems won't be fixed with renaming B&W lists.
Seriously.. you have more important issues...


While thet change in names will not fix any societal issue,


No one has suggested that it will or can.


for a
product like SpamAssassin that relies heavily on plugins (including some
plugins that may have been developped locally, long time ago, by someone
who is not working there anymore) and that is
also embeded (like in amavis) these sort of changes may break a lot of
implementations, to the point that people will be reluctant to upgrade.


As Kevin has explained here and as is explained in the ticket he referenced, 
compatibility with existing terminology will be retained through the 4.0.x 
release versions.


And that added complexity is just more places for it to break. Very very ancient 
wisdom runs, "If it ain't broke, don't fix it." That includes fixing things for 
a faulty definition of "broke".


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 13:43:21, Bill Cole wrote:

On 10 Jul 2020, at 8:37, Mauricio Tavares wrote:


  I do agree that accept works better than welcome here.


There's a practical issue in that: we have the WLBLEval plugin that has cemented 
the initial.


FWIW, the use of "blocklist" in spamfighting goes back to the '90s, when the 
primary resistance to "blacklist" was by people who were uncomfortable with its 
McCarthyist connotation.


Well, Bill, it was stupid then. What makes it not stupid today? The exact same 
logic applies, doesn't it?


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 12:34:03, @lbutlr wrote:

On 10 Jul 2020, at 02:06, Matus UHLAR - fantomas  wrote:

  thought guys can also mean women, at least I've seen it being used that
way…


Yes, guy/s is gender neutral, but many women do not agree.


Far more use it themselves. You males have lost control of the term to generic 
usage. Sorry. If that triggers you so be it.


{^_-}



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 12:34:03, @lbutlr wrote:

On 10 Jul 2020, at 02:06, Matus UHLAR - fantomas  wrote:

  thought guys can also mean women, at least I've seen it being used that
way…


Yes, guy/s is gender neutral, but many women do not agree.


Far more use it themselves. You males have lost control of the term to generic 
usage. Sorry. If that triggers you so be it.


{^_-}



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
And every ancillary script sysadmins have written has to be rewritten. Every 
user_prefs has to be rewritten. You are forcing a boatload of hurt on innocent 
people. This is purely lifting a leg and peeing on something to mark it as 
YOURS. Isn't that rather selfish?

{^_^}

On 20200710 13:27:45, Kevin A. McGrail wrote:

Hello all,

A common question we are receiving is what about using this terminology
instead, for example allow/deny.

The use of welcomelist and blocklist has evolved from discussions since
April and work done creating patches.  We found that using these names
of welcomelist and blocklist are non offensive, reasonably descriptive
and since they still start with W and B, we avoid renaming things like
RBLs, WLBL, DNSBL, etc. This should help minimize the disruption when
4.0 is released with the new configuration options.

Regards,

KAM



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
In other words "I am going to pee on the product and if you don't like it go 
pound sand."


Well, I am pounding sand in your general direction, loudly.

{^_^}

On 20200710 13:21:41, Bill Cole wrote:

On 10 Jul 2020, at 5:12, hospice admin wrote:


$0.02 from a woman of colour ...

I personally find stuff like this just a little bit patronising ... more of a 
matter of kicking the real problem into the weeds than actually doing anything 
practical to 'fix' it.


Well, in the context of the Apache SpamAssassin Project, "The Real Problem" that 
we have any capacity to work on is the low diversity of our developer community. 
Eliminating terminology that may be off-putting for even a minority of a 
minority of possible contributors is worthwhile, particularly when the 
block/welcome terminology we are replacing black/white with is explicitly 
descriptive rather than metaphorical and connotative.


We have no way of knowing how many people have thought less of SA because of 
terminology or whether any of those people might have otherwise become involved 
enough in the project to be contributors. If changing the terminology makes the 
Project look less like a bunch of white guys trying to make rules for the 
world's email, that's a positive step.



Right up there with Mercedes decision to paint their $100 Million F1 cars black.


This is a bit less symbolic. We're actually making the terminology better.


I'm sure the intent was positive though ...


The intent is to do what we can to make involvement in the SpamAssassin 
community less hostile to newcomers, even if elements of hostility that we can 
address are not universally recognized as such. We cannot do much for the bigger 
Real Problems that intersect with ours tangentially, because unlike 
Daimler-Benz, we don't have $100 Million or even $1 to spend. None of us has the 
time and skills to make a focused recruiting effort to get a more diverse set of 
contributors or even just more contributors. Changing a few labels in the code 
is something we CAN do.




Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
What I am seeing here, if I choose to think on their terms, is a small 
collection of males asserting dominance by lifting their legs and demanding we 
accept their peeing on a working product. If It Is Not Broke Don't Fix It. This 
is the experience of a 76 year life span giving you advice. I've seen managers 
pee on projects this way and destroy companies. I hated it then. I hate it now. 
And you are triggering me horridly.


{+,+}  I stick my tongue out in your general direction.

On 20200710 12:29:42, @lbutlr wrote:

On 10 Jul 2020, at 01:38, Olivier  wrote:

Axb  writes:


the US problems won't be fixed with renaming B&W lists.
Seriously.. you have more important issues...


While thet change in names will not fix any societal issue, for a
product like SpamAssassin that relies heavily on plugins (including some
plugins that may have been developped locally, long time ago, by someone
who is not working there anymore) and that is
also embeded (like in amavis) these sort of changes may break a lot of
implementations, to the point that people will be reluctant to upgrade.


If people are so fragile that they have to hold on to terms that are extremely 
offensive to some of their peers, they will get more spam. Oh noes.


And if SA is not upgraded, the user base will shrink and it may lead to
the death of SA.


If it cannot function without being offensive to many people, then so be it.

Allow/deny I think are better than welcome/block, but I don't care.

Allow/block might be better too.





Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow



On 20200710 11:52:11, Ralph Seichter wrote:

* Eric Broch:


As stated earlier by another very aware poster, this is nothing less
than, "Newspeak."


That was actually me, in message <87lfjr78zu@wedjat.horus-it.com>.
However, you did not quote the first part of the sentence, which I
consider just as important:


Racists are assholes, but "Newspeak" is not the solution.


Looking at the content of your website, I don't want to be associated
with your world views in general. We just seem to share a dislike for
Newspeak.

-Ralph


Ralph, you are free to avoid Eric. You are NOT free to try to force your world 
view on the world. And that is exactly what these mental, ethical, and moral 
failures are trying to do.


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 11:31:57, Bill Cole wrote:

On 10 Jul 2020, at 3:06, Rupert Gallagher wrote:


Whatever you do under the hood, make sure it does not affect external behaviour.

On your motivation, bear in mind that *lists here contain computer addresses, 
not people,


Which is an argument FOR changing our terminology.

so the reference you are trying to fix is mistaken, and changes will be 
painstaking for no reason at all.


That misses the actual rationale for the change.

There's a semantic collision in English where "Black" and "White" are used both 
to classify people and to denote moral and/or desirability dichotomies. That 
semantic collision can be removed from our code, while improving the clarity of 
our naming.


The SpamAssassin Project has a particular self-interest in attracting 
contributors from a diversity of cultures, because we are always at risk of 
mislabelling a pattern of letters or words as 'spammy' when in fact it is 
entirely normal in a cultural context other than those of the existing 
contributors to the project. Continuing to use 'black' and 'white' as indicators 
of value in code and configuration directives leaves in place a minor nuisance 
for some potential contributors and users who are understandably tired of being 
on the bad side of this semantic collision, where the most common word for their 
ethnic identity is constantly being used as a label for things which are bad, 
undesirable, malfeasant, etc. The naming collision is a problem and because the 
inanimate entities for which we use black and white do not in fact have any 
color we can both eliminate the collision AND improve the quality of the names 
we use.



And the terms master and slave have nothing to do with white and black, and 
again they refer to machine processes, not people.


This is actually almost irrelevant for SA. The main use of the master/slave 
metaphor is in the automation backend for rule QA (e.g. build/jenkins/run_build) 
where it merits changing simply because it is no longer consistent with the 
terminology used by Jenkins. In spamd, parent/child is already the terminology 
and fits the actual code better.


I am still trying to figure out the rationale for forcing everybody out there 
with established lists of "whitelist_from_rcvd" and "blacklist_from_rcvd" to go 
out there and edit EVERYBODY's user_prefs or explain to users they must do this 
themselves. *I* can do this easily enough and call them foolist_from_rcvd and 
barlist_from_rcvd if needed. I am thinking if people with setups in small 
business offices that have to invade privacy or explain how so that user_prefs 
can be changed. And how about all the ancillary scripts that train spam that 
also have to be changed?


This is something that is not broken, currently works, that some dolt is trying 
to fix. It's better you call that person a dolt than try to change the world and 
break everything. Making this change is dumb. It is counter-productive. It is 
even destructive. Just Say No.


{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
Um, you are a little information deprived. There are several videos out there of 
BLM organizers stating how proud they are of being well trained Marxist 
agitators. Ditto for Antifa and similar organizations. Wake up and smell the 
manure lest you find yourself swimming in it.


And if you REALLY want a hair raising read dig around for a copy of William 
Shirer's "The Rise and Fall of the Third Reich." Then tell me there is no 
resemblance at all between that and current events.


This is an attempt to control how you think by erasing useful and accurate 
vocabulary. (It also ignores the detail that the "Owner/Slave" relationship 
between human beings exists today and is fully legal in some countries 
(Mauritania) and illegal but not prosecuted in others (Saudi Arabia and others). 
BLM is closer to Black Lives Mangled as I see it.)


{^_^}

On 20200710 10:11:41, Axb wrote:

Not sure if this is sarcasm or not... but just in case:
Whoever may be the Marxist/Socialists, the're definitely not in the US... 
Assuming you never lived under such a government you're just talking thru your hat.


and now lets put this offtopic blah to rest.



On 7/10/20 7:07 PM, Eric Broch wrote:

Amen!

This is not about racism this is about a Marxist (Socialist) takeover. They 
don't care if you use the terms whitelist or blacklist, this is a revolution.


Soon, it will be as in Dr. Zhivago. You'll come home being dispossessed of 
your house and belongings under the supervision of the state, already going on 
as BLM freely loots and pillages.


The "Useful Idiots" (not trying to be offensive, Kevin, but get a grip) don't 
know that after the reorganization is done, their heads will be on the 
chopping block as well...all planned in advance.


These are sad days, woe is me if I don't speak out.


On 7/10/2020 8:14 AM, Ralph Seichter wrote:

..., but "Newspeak" is not the solution.


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 05:16:15, Martin Gregorie wrote:

On Fri, 2020-07-10 at 10:36 +0200, Matus UHLAR - fantomas wrote:

On 10.07.20 08:50, Axb wrote:

the US problems won't be fixed with renaming B&W lists.
Seriously.. you have more important issues...


while I am not a fan of renaming, I think that
"welcome list" and "block list" are more informational.
While people working with these terms know them, others may not so
well.


Still a bit woolly methinks. I think, acceptlist and rejectlist are a
more meaningful pair of terms.

Similarly I, and the places I've worked, have always used client and
server rather than slave and master. While I see no need to use 'slave'
term outside its historic and ongoing human designation, I do see a
continuing use for 'master', where it describes a unique object that is
frequently replicated of a person with extensive understanding of a body
of knowledge, e.g. master (of a sailing ship), master craftsman, or a
qualification: MSc, MA, etc.

Martin


How do you design a servo system without a master/slave concept?
{o.o}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 01:59:10, Matthias Leisi wrote:
Not responding to any of the messages in particular, but it may be worth to 
weigh in.


dnswl.org  will do a rebranding to a socially less loaded 
terminology. We have not decided on a new branding yet and do not yet have a 
timeline (renaming a project with 14 years of history has some different 
implications than renaming in code / config).


Of course we will provide backwards compatibility on the „list.dnswl.org 
“ and other names which are in use today for the coming 
years.


And yes, theoretically we could simply re-use the „w“ for „welcome“ :)

— Matthias, with the dnswl.org  hat on


Are we now going to be afraid of the unwelcome rather than the dark? Are we 
going to shine a welcome on problems rather than light?


You guys are MAKING problems where they do not exist. Shame on you, children.

{^_^}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 01:46:55, Olivier wrote:

Hi,

One solution maybe to release the next version of SA with only the
renaming and no other change in the features. And give the users time to
see whether it works or if the renaming creates serious problems of
compatibility.

While I find the words black/white list easy to use, I wou;ld not mind a
renaming if the new names are something common, like deny/allow. The
conned names block/welcome sound very artificial to me.

But the realy main issue is compatibility.

Best regards,

Olivier



Quick, somebody - fork the project while they er "fork" it.

{^_-}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

On 20200710 01:53:30, Axb wrote:

On 7/10/20 10:36 AM, Matus UHLAR - fantomas wrote:

while I am not a fan of renaming, I think that
"welcome list" and "block list" are more informational.



SA doesn't block anything so a blocklist only makes stuff naturally confusing


Oh, you're supposed to ignore that pesky detail. It bothers the snowflakes.

(Rule number one: Do NOT wake Joanne up.)

{^_-}


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
Besides, they are not black and Irish me is not white. We are all various shades 
of beige. And I am a racist because I judge people on their own individual 
actions, capabilities, and initiative. So surely that is being racist, at least 
as seen by people who deep inside feel that the people who call themselves black 
when they aren't (for the most part not even close) are really inferior. They 
are admitting their own racism. I'm a capability-ist if anything.


{^_^}

On 20200710 01:30:27, Cecil Westerhof wrote:

Matus UHLAR - fantomas  writes:


Good day Guys


On 10.07.20 09:45, Marc Roos wrote:

You are being a tad discriminative, by assuming there are no ladies
reading these messages. Which is highly inappropriate for the current
thread. ;)


I thought guys can also mean women, at least I've seen it being used that
way...

(on old english, word 'man' stood for human, while 'wer man' and 'wif man'
stood for male and female human)


I am reasonably sure that whitelist and blacklist have nothing to do
with race, still it has to be changed. So it is a bit strange that you
do not include the greeting part of your message in the inclusiveness.


We should change the name of Serbia and go on a crusade to ban the
word picnic.
Maybe we should also change the terms upper and lower Egypt?
And what about master degrees?
And whitewashing, black eye, black Friday, black market, …?



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
I have gentle fun in some of my code and note I have a pointer to my mommy. I 
figure people can figure that out and get the chuckle. Of course, that's in my 
own code for myself and maybe others if I toss it onto GitHub. I also stick in 
the occasional Daddy. So it might even out. I don't obsess at that level. I just 
try my level best, which is not as good as I'd like, to get it right.


{^_^}

On 20200710 01:35:16, Cecil Westerhof wrote:

jdow  writes:


As a woman engineer, retired, after many years in industry even "gents"
does not bother me. It goes with the territory. And if I had a dollar
for every time I heard "you guys" from a woman talking to other women
I'd be almost as rich as poor man Biden.

Political correctness has no place in engineering. Clarity of
communications is a basis of the craft. When you disrupt it things
break. (eg Mars landers)


I agree, but when you ban blacklist and whitelist, it is a bit
inconsistent when you not also take care of the gender terms.
To be honest, I think the gender terms have a better case to be
changed as blacklist and whitelist.



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

Historical precedent, which if changed breaks too many very valuable tools.

That "get the fork out of there" anecdote is 100% true. I was a part of the 
project using GRiD OS which used a lot of UNIX derived nomenclature. Fork was 
one such word. The AF had EDS proof reading the documents. EDS had some er "new 
hires" doing job. We had to patiently describe to them that "fork" was a term of 
art and was embedded within the OS on which the project rode. It was a very 
surrealistic fight. This blacklist/whitelist nonsense rivals it. Next we have 
problems in the security world with "Black" and "Red" worlds? Get used to it 
snowflakes. Fixing what works is as fine a way to introduce new faults in the 
code as I can think of.


{^_^}


On 20200710 01:19:12, Paul Stead wrote:

Let's look at other communities and their responses:

https://github.com/rails/rails/issues/33677
https://bugs.python.org/issue34605
https://tools.ietf.org/id/draft-knodel-terminology-00.html
https://github.com/openzfs/zfs/pull/10435
https://bugs.chromium.org/p/chromium/issues/detail?id=981129

I see no problem in removing/changing the suggested words with negative 
connotations with alternatives - especially as the backwards compatibility 
(software hat on) is being built in.

How would you explain to a 5 year old why being on a "blacklist" is seen as bad and a 
"whitelist" is seen as good?

Paul

On 10/07/2020, 08:39, "Brent Clark"  wrote:

 Good day Guys

 Lads you are being a tad silly.

 Various projects (and companies) are adopting and making the necessary
 change(s).

 You need to look and think bigger than the project itself. We don't want
 the SA Mailing list, the project, community to be seen as the project
 (or community ) that wont adapt to the times and be seen as insensitive.
 By not making the necessary change (i dont mean software change(s). I
 mean at oneself).

 I highly recommend, take a step back, and look at see whats happening.
 This is a good and right thing to do.

 Kevin, kudos to you for having the vision and will to drive this.
 You have my support.

 Thank you to all for your work and efforts.

 Regards
 Brent Clark



 On 2020/07/10 09:22, Axb wrote:
 > On 7/10/20 9:13 AM, Gianluca Furnarotto wrote:
 >> This is foolish, we are losing control. I have nothing else to think
 >> about ... and the next one that needs to change its name is the TV
 >> series "The Blacklist"?
 >> And the next would be to delete the word "black"?
 >
 > wanna bet there's plans to rewrite Tom Sawyer ?
 >
 >>
 >> This is my opinion.
 >> On 10 luglio 2020 a 09:05:26, Kevin A. McGrail (kmcgr...@apache.org)
 >> scritto:
 >>
 >> Gents, while this may appear to be a response to racial tensions in
 >> the US of late, you might be surprised to learn that the project has
 >> been working on this type of change for quite some time.
 >>
 >> - We start using Blocklist at least as early as 2012 when I drafted
 >> this: 
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/DnsBlocklistsInclusionPolicy
 >>
 >>
 >> - And the vote on and discussion on this change was based on a UK
 >> article
 >> 
https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/
 which
 >> I brought to the PMC on 4/5.  We brought it for a vote on 5/3.
 >>
 >> So this isn't about US politics, it isn't rash and no it's not a
 >> joke.  This is about doing the right thing and getting rid of racially
 >> charged language.  I'd appreciate support in this change or at least
 >> if you can't say something nice or helpful, just keep it to yourselves.
 >>
 >> Regards,
 >> KAM
 >> --
 >> Kevin A. McGrail
 >> Member, Apache Software Foundation
 >> Chair Emeritus Apache SpamAssassin Project
 >> https://www.linkedin.com/in/kmcgrail - 703.798.0171
 >>
 >>
 >> On Fri, Jul 10, 2020 at 2:50 AM Axb  wrote:
 >> the US problems won't be fixed with renaming B&W lists.
 >> Seriously.. you have more important issues...
 >>
 >> On 7/10/20 8:42 AM, jdow wrote:
 >>> Be sure to purge every instance of "fork" in the code because it sounds
 >>> too close to the other F..K word. Get the fork out of there.
 >>> {O,o}
 >>>i.e are you guys being just a little stupid here?
 >>> On 20200709 21:00:37, Kevin A. McGrail wrote:
 &

Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
As a woman engineer, retired, after many years in industry even "gents" does not 
bother me. It goes with the territory. And if I had a dollar for every time I 
heard "you guys" from a woman talking to other women I'd be almost as rich as 
poor man Biden.


Political correctness has no place in engineering. Clarity of communications is 
a basis of the craft. When you disrupt it things break. (eg Mars landers)


{^_^}

On 20200710 00:44:37, Olivier wrote:

"Kevin A. McGrail"  writes:


[1:text/plain Show]


[2:text/html Hide Save:noname (12kB)]

Gents,


Lets be inclusive and assume that some readers on the list may not be
gents, so may even not be women :)

Olivier



Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow

One should never let practicality get in the way of political correctness, 
right?

{O,o}


On 20200710 00:38:06, Olivier wrote:

Axb  writes:


the US problems won't be fixed with renaming B&W lists.
Seriously.. you have more important issues...


While thet change in names will not fix any societal issue, for a
product like SpamAssassin that relies heavily on plugins (including some
plugins that may have been developped locally, long time ago, by someone
who is not working there anymore) and that is
also embeded (like in amavis) these sort of changes may break a lot of
implementations, to the point that people will be reluctant to upgrade.

And if SA is not upgraded, the user base will shrink and it may lead to
the death of SA.

Best regards,

Olivier


On 7/10/20 8:42 AM, jdow wrote:

Be sure to purge every instance of "fork" in the code because it sounds
too close to the other F..K word. Get the fork out of there.

{O,o}
  i.e are you guys being just a little stupid here?

On 20200709 21:00:37, Kevin A. McGrail wrote:

IMPORTANT NOTICE

If you are running trunk, we are working on changing terms like
whitelist to welcomelist and blacklist to blocklist.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

The first test of this work is done with allowlist_to replacing
whitelist_to
Committed revision 1879456.

If you are using trunk, there may be disruption since routines,
plugins and rule changes will all interweave.

*IF YOU ARE RUNNING TRUNK: I recommend you subscribe to the
d...@spamassassin.apache.org <mailto:d...@spamassassin.apache.org>
mailing list to stay abreast of the changes.*
*
*
Please let me know if you have any questions!

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171








Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-10 Thread jdow
The problem is that at least one woman (me) reading this list doesn't give a 
tinker's damn. The intent is communicated and that's sufficient to satisfy my 
sensibilities. Seems I grew up and became an adult when I wasn't looking. Things 
like this just wash by me as I dive in for the meat of the communications.


{^_^}

On 20200710 00:53:07, Brent Clark wrote:

On 2020/07/10 09:45, Marc Roos wrote:




Good day Guys


You are being a tad discriminative, by assuming there are no ladies
reading these messages. Which is highly inappropriate for the current
thread. ;)



LOL
Touche

But you right.
I need to remember to start with 'Good day All'.

Regards
Brent


Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

2020-07-09 Thread jdow
Be sure to purge every instance of "fork" in the code because it sounds too 
close to the other F..K word. Get the fork out of there.


{O,o}
i.e are you guys being just a little stupid here?

On 20200709 21:00:37, Kevin A. McGrail wrote:

IMPORTANT NOTICE

If you are running trunk, we are working on changing terms like whitelist to 
welcomelist and blacklist to blocklist.


https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

The first test of this work is done with allowlist_to replacing whitelist_to
Committed revision 1879456.

If you are using trunk, there may be disruption since routines, plugins and rule 
changes will all interweave.


*IF YOU ARE RUNNING TRUNK: I recommend you subscribe to the 
d...@spamassassin.apache.org  mailing list to 
stay abreast of the changes.*

*
*
Please let me know if you have any questions!

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


Re: Question on Rule

2020-01-27 Thread jdow

On 20200127 09:01:10, Charles Amstutz wrote:



Hello,

Can someone explain what this actually means and maybe provide an
example?

Rule Name: FROM_MISSP_DYNIP
Rule Definition: misspaced + dynamic rDNS

Getting a high score on this and having trouble finding an actual real
definition and example. I get the dynamic rDNS I believe, but not sure
about the misspaced meaning for sure.


It means that there is no space between the display name and the '<', e.g.

From: John Smith

If you are seeing anything very different?


Thanks, however, I do see a space between the name and the '<'

This is what it looks like:

From: =?UTF-8?Q?Name?= 



Are you sure it is not the extra space between the routing headers and the 
"Subject:" line?


===8<---
From: =3D?UTF-8?Q?Sender_name?=3D 
To: =3D?UTF-8?Q?Recipient_name?=3D 

Subject: =3D?UTF-8?Q?Subject?=3D
Date: Sat, 25 Jan 2020 19:35:07 +
===8<---

That spacing is very typical of spam and never seen as ham here.

{^_^}


Um, T'Bird and Spamassassin are not seeing eye to eye lately

2019-06-19 Thread jdow
FORGED_MUA_MOZILLA is misfiring on my emails. You should be able to see that in 
an SA run against this email since it seems to trigger on all my emails. I am 
filtering with 3.004000 on a Scientific Linux 7.x system. I noticed this, 
finally, today when an email to a mailing list came back and triggered the 
forged rule. This may be specific to relays through groups.io. Here is a sample 
header and first part of a message:


===8<---
From - Tue Jun 18 20:06:37 2019
X-Account-Key: account2
X-UIDL: 002ebd304714358b
X-Mozilla-Status: 0010
X-Mozilla-Status2: 
X-Mozilla-Keys: 


Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
thursday.wizardess.wiz
X-Spam-Level: **
X-Spam-Status: No, score=2.7 required=5.0 tests=BAYES_00=-1.9,
DATE_IN_PAST_06_12=1.543,DKIMWL_WL_HIGH=-0.001,DKIM_SIGNED=0.1,

DKIM_VALID=-0.1,FORGED_MUA_MOZILLA=2.309,HEADER_FROM_DIFFERENT_DOMAINS=0.249,

JD_LO_BAYES=0.001,JD_VLO_BAYES=0.001,MAILING_LIST_MULTI=-1,RDNS_NONE=0.793,
SPF_HELO_NONE=0.001,SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no
version=3.4.0
X-Original-To: j...@thursday.wizardess.wiz
Delivered-To: j...@thursday.wizardess.wiz
Received: from thursday.wizardess.wiz (localhost [IPv6:::1])
by thursday.wizardess.wiz (Postfix) with ESMTP id 86B68419923C
for ; Tue, 18 Jun 2019 20:06:33 -0700 (PDT)
Received: from pop.earthlink.net [209.86.93.202]
by thursday.wizardess.wiz with POP3 (fetchmail-6.3.24)
	for  (single-drop); Tue, 18 Jun 2019 20:06:33 
-0700 (PDT)

Received: from noehlo.host ([209.86.89.133])
	by mdl-gnash.atl.sa.earthlink.net (EarthLink SMTP Server) with SMTP id 
1HDqV36lX3Nl3710; Tue, 18 Jun 2019 23:05:53 -0400 (EDT)

Received: from web01.groups.io ([66.175.222.12])
	by ibscan-saipan.atl.sa.earthlink.net (EarthLink SMTP Server) with ESMTP id 
1HDqV21gX3PGoUl1

for ; Tue, 18 Jun 2019 23:05:52 -0400 (EDT)
X-Received: from elasmtp-galgo.atl.sa.earthlink.net 
(elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61])

 by groups.io with SMTP; Tue, 18 Jun 2019 18:49:42 -0700
X-Received: from [47.140.131.91] (helo=[192.168.37.230])
by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4)
(envelope-from )
id 1hdLDY-0003Ou-5Z
for m...@airspy.groups.io; Tue, 18 Jun 2019 17:00:36 -0400
Subject: Re: [airspy] Help with AirSpy
To: m...@airspy.groups.io
References: <5d07ec0c.70...@yahoo.com> <29260.1560872734203103...@groups.io>
 <5d090e48.3060...@yahoo.com>
 
 <8076dc12-bebf-4e0f-adcf-d484f63ee...@blackcatsystems.com>
From: "jdow" 
Message-Id: <15a97a99fccb8db4.7...@groups.io>
Date: Tue, 18 Jun 2019 14:00:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <8076dc12-bebf-4e0f-adcf-d484f63ee...@blackcatsystems.com>
X-ELNK-Trace: 
bb89ecdb26a8f9f24d2b10475b5711209bcb8c5973b81554483f969212e6ff18f03e6360f34aaf19350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c

X-Originating-IP: 47.140.131.91
Precedence: Bulk
List-Unsubscribe: <https://airspy.groups.io/g/main/unsub>
Sender: m...@airspy.groups.io
List-Id: 
Mailing-List: list m...@airspy.groups.io; contact main+ow...@airspy.groups.io
Delivered-To: mailing list m...@airspy.groups.io
Reply-To: m...@airspy.groups.io
X-Orig-Message-Id: <1baf2ebe-0e60-a082-6119-c55ed310b...@earthlink.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io;
 q=dns/txt; s=20140610; t=1560913552;
 bh=TGutsx+DixyfPAnGgIW26vjB/U1mlUo7XjSQaqdeGa0=;
 h=Content-Type:Date:From:Reply-To:Subject:To;
 b=DGf+MNkwV4AQPpL7u/eHFnDlwhu+LUzPYD6uuorHQ2GwLxoZE9xObieCj6WzPu+rbMb
 Uo2QdUSS+eTztQXMt/YWIlyRAqQLe/Ki0AdvXaFwU82uwi0nXRfnAv1JNaMDD8PVvDRZB
 m/b+Gm7A5Deso+G9Afl1ir5If5s/gLU2fdo=
X-ELNK-TLSInbound:: 1
X-Authentication-Results: dkim="pass"; (0:DKIM_STAT_OK: function completed 
successfully); dmarc="none"; (1); dwl="miss"; den="not exempt"

X-ELNK-SMM: ---+10-10-52-70dkdd10
X-ELNK-AV: 0
X-ELNK-Info: sbv=0; sbrc=.0; sbf=00; sbw=000;
X-Jdow: user jdow

You might benefit from a modest gain preamplifier up at the antenna. If you have
5 dB of cable loss a 7 to 10 dB gain preamp would do wonders without overly
compromising your dynamic range.

Cable loss increases your noise figure dB for dB. So the long feed line you have
may be reducing your sensitivity considerably.

{^_^}===8<---

{^_^}   Joanne


Re: Email filtering theory and the definition of spam

2018-02-09 Thread jdow

On 20180208 23:24, Reindl Harald wrote:



Am 09.02.2018 um 01:20 schrieb jdow:

On 20180208 07:23, David Jones wrote:

On 02/07/2018 06:28 PM, Dave Warren wrote:

On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:

Technically, you asked for the email and they have a valid opt-out
process that will stop sending you email.  Yes, the site has scummy
practices but that is not spam by my definition.


Yes, under EU/UK that counts as spam because the regulations say that
the signer-upper must explicitly choose to receive e-mail from the
site, and by-default sign-in doesn't count as 'informed sign-in'.


Canadian law is the same, this is absolutely spam without any ambiguity.


But how can you tell the difference based on content then?  You can't. Two 
different senders could send the exact same email and one could be spam from 
tricking the recipient to opt-in and another could be ham the recipient 
consciously opted into.


This would have to be blocked or allowed based on reputation.  One would 
train the message as spam in their Bayes database and allow trusted senders 
via something like a domain whitelist, URI whitelist, or a whitelist_auth entry.


We are back to needing a curated WL based on something like DKIM. Alex just 
made me aware of http://dkimwl.org/ which looks brilliant. Exactly lines up 
with how I filter and what I have been wanted to do for a couple of years 
now. A community-driven clearing house for trusted senders.


If this is done as well as the bozos who block Earthlink then it will be 
largely useless. Who supervises the volunteers to keep them from being lazy, 
careless, or politically biased?


*lol* who supervises the companies?


Perhaps nobody as Facebook, Google, et al seem to prove all too thoroughly. 
Maybe we need a meta-trust monitor on the monitors. But, then, who trusts which 
meta-trust monitor? The common thing with "community-driven" this and that is 
the lack of people who actually working for a living who spend time feeding data 
to the effort. So it ends up biased really quickly. The advantage in that regard 
to having a Giggle, Facebunk, or little-burdy-told-me is they are treading on 
monopoly ground. So if they get too rough with their biases it is theoretically 
possible the government (who trusts it?) could be pressured into doing something 
about it using the monopoly arm-twist maneuver.


It's all an unholy mess no matter how you figure it. Some messes are worse than 
others. I read "community-driven" and started imagining OWS and ANTIFA in 
effective control of that community and what results we'd see.


{^_^}


Re: Email filtering theory and the definition of spam

2018-02-08 Thread jdow

On 20180208 07:23, David Jones wrote:

On 02/07/2018 06:28 PM, Dave Warren wrote:

On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:

Technically, you asked for the email and they have a valid opt-out
process that will stop sending you email.  Yes, the site has scummy
practices but that is not spam by my definition.


Yes, under EU/UK that counts as spam because the regulations say that
the signer-upper must explicitly choose to receive e-mail from the
site, and by-default sign-in doesn't count as 'informed sign-in'.


Canadian law is the same, this is absolutely spam without any ambiguity.



But how can you tell the difference based on content then?  You can't. Two 
different senders could send the exact same email and one could be spam from 
tricking the recipient to opt-in and another could be ham the recipient 
consciously opted into.


This would have to be blocked or allowed based on reputation.  One would train 
the message as spam in their Bayes database and allow trusted senders via 
something like a domain whitelist, URI whitelist, or a whitelist_auth entry.


We are back to needing a curated WL based on something like DKIM.  Alex just 
made me aware of http://dkimwl.org/ which looks brilliant.  Exactly lines up 
with how I filter and what I have been wanted to do for a couple of years now.  
A community-driven clearing house for trusted senders.


If this is done as well as the bozos who block Earthlink then it will be largely 
useless. Who supervises the volunteers to keep them from being lazy, careless, 
or politically biased?


{^_^}


Re: Email filtering theory and the definition of spam

2018-02-06 Thread jdow

On 20180206 16:56, Miles Fidelman wrote:



On 2/6/18 2:47 PM, Anne P. Mitchell Esq. wrote:
I know the definition of spam is very subjective and dependent on your 
particular the mail flow along with the expectations of the recipients.


Back when I was in-house counsel at MAPS, Paul (Vixie) and I came up with this 
definition of spam:


“An electronic message is “spam” IF: (1) the recipient’s personal identity and 
context are
irrelevant because the message is equally applicable to many other potential 
recipients;
AND (2) the recipient has not verifiably granted deliberate, explicit, and 
still-revocable
permission for it to be sent; AND (3) the transmission and reception of the 
message

appears to the recipient to give a disproportionate benefit to the sender.”

I think that it still holds up.



Not bad at all.  Actually, quite good!

(Of course, the old definition of pornography also holds:  "I know it when I see 
it." :-)


Miles Fidelman


"Spam is email *I* don't want to see and never asked for."

With that in mind, do remember that what you consider to be spam may not be the 
same as what I call spam or John Hardin considers spam or Marc Perkel considers 
spam. (I'm not about to start dating pretty Russian girls. 1) I don't swing that 
way. 2) I don't chase babies in arms. 3) ... well you get the idea. Some guys, 
however, might think that kind of bait is amusing or might need some under the 
counter stuff of one kind or another and be dumb enough to go for it. Males do 
seem to do things for unfathomable reasons. Me? I just like to pull the wings 
off spam wishing I could do that to the spammers themselves.)


{^_-}   Joanne


Re: From name containing a spoofed email address

2018-01-19 Thread jdow
After your first time being a victim of cyberstalking you'll soon enough wish 
your "from" line was as generic as mine. People who put their full name in the 
From: line haven't been mugged yet. I spent a year learning about this 1985-1986.


As a byproduct of this habit of mine, when I see a "To: John" or other name than 
mine it's automatically spam, especially when it cannot even get the gender right.


{^_-}

On 2018-01-19 08:10, sha...@shanew.net wrote:

I've got a basic plugin written for this now, but I'd like to do a
litle more testing before I make it widely available.  If you have
mail samples (ham or spam) with an "@" character in the name part of
the From field that you're willing to share, let me know.

BTW, I've already run into some false-positive situations, the most
common being things from yahoogroups, which apparently writes the
"true" sender address in the name part of From (they also dkim sign,
so not too hard to work around).  I started trying to handle these in
the plugin itself, but I'm beginning to think these would be better as
separate rules and then combined as metas to mitigate the actual
mismatch score.


On Wed, 17 Jan 2018, David Jones wrote:

Would a plugin need to be created (or an existing one enhanced) to be able to 
detect this type of spoofed From header?


From:  "h...@hulumail.com !" 

https://pastebin.com/vVhGjC8H

Does anyone else think this would be a good idea to make a rule that at least 
checks both the From:name and From:addr to see if there is an email address in 
the From:name and if the domain is different add some points?


We are seeing more and more of this now that SPF, DKIM, and DMARC are making 
it harder to spoof common/major brands that have properly implemented some or 
all of them.







Re: moving spam to junk folder

2018-01-13 Thread jdow

On 2018-01-13 09:42, Matus UHLAR - fantomas wrote:

On 13.01.18 09:35, Matthew Broadhead wrote:
i set my local.cf to use MySQL as a bayes store and it seems to work fine 
setting ham and spam in the database when a message is flagged. however it has 
had no impact on spam received to the inboxes.  we are still receiving a large 
amount of junk email.


i originally installed spamassassin according to this guide 
http://forums.sentora.org/showthread.php?tid=1118 and it does indeed filter 
the test message so it should be working ok?


spamassassin detects and marks mail, it does not deliver it.
the MDA (mail delivery agent) delivers the mail.

you need to configure your MDA (procmail, maildrop, sieve etc) to deliver
mail marked as spam to Junk folder.


Or, if it is sufficient, he could have his MUA sort incoming marked as spam into 
his local spam bucket for examination before disposal. I make that easy by 
telling SA I want a header that looks like this: "*SPAM* 009.1 ** You 
have 3 missed Nigerian Spam Pill Adds". Sorting incoming based on the 
"*SPAM*" part is rather easy.


{^_^}


Re: In anyone else getting 325KB spams from cont...@cron-job.org?

2017-09-14 Thread jdow
Hm, meant this to go to the list, too. The misdirection is part of why I am so 
quiet on the list, which is why I forget the misbehavior, which reinforces the 
problem when I reenter the list for a discussion. I gotta mess with my 
.procmailrc file to rewrite the headers for SA list emails, I guess. Then I can 
pester people better. {O,o} (Been using SA since the dark ages - before 2.20 if 
I recall correctly.)


The fragment of email probably would not base64 decode. It was a fragment from 
near one of the crossovers in its decorative layout design. This has been going 
on for a long time now. I catch the spams via other tricks. The "from" headings 
seem to be less imaginative then they could be.


Loren's actual problem of them leaking through goes back in history to the 
really old days on a really slow old machine. (Hey - it made over 400 days 
without a reboot during which it was relocated by about 70 miles to a new 
"home".) Back then processing more than 250k was too time consuming for that 
itty bitty machine. It has been replaced. But the .procmailrc recipe still 
included the 250k hard wired in. AND there was no --max-size=. So I 
corrected these, I thought. Alas I made it --max-size- thanks to a typo 
probably when blowing my nose thanks to the stuffiness hangover from a 
remarkably short head cold I had.


That is fixed now. But I'm mildly wondering if people are seeing that (real or 
pseudo) base64 junk, in two parts with the real payload, a URL, stuck between them.


{^_^}   Joanne

On 2017-09-14 15:35, Benny Pedersen wrote:

jdow skrev den 2017-09-15 00:16:

On 2017-09-14 14:06, Benny Pedersen wrote:

Dianne Skoll skrev den 2017-09-14 20:38:


https://cron-job.org/en/spam-statement/
They are victims of a joe-job.


yes prove that is really is us

if it goes, it goes


Loren's canny enough to not blacklist an address based on the from
address. The common element in the messages he's been receiving is a
325 kb payload and that "from" address. I'm sitting in the same room
as him on the same network and despite my incoming spam going up to
some 75 to 100/day (fron 1/4 of that last year) I am not getting those
specific spams.


spamassassin here scans up to 1024K, so this could be first step for recipient 
to make, atleast i found that cron-job.org have valid spf record to reject in 
mta stage if forged mails from cron-job


but if envelope sender is random it not possible to block it in mta stage, if 
thats the case it would make more sense to make clamav signature for content in 
this spams to be rejected in sendmail/milter stage


i dont know exact spam from them or even seen ham aswell

i self scan all mails in spampd so no exections here


I get varying lengths and widely varying subjects and from fields.
This is a small extract of the body with it's odd visual formatting.
(It really shows up if you have line wrapping enabled in a plain text
MUA.)


aha, encodeing fails ?


QYC9LYOXDU89JN94BBNNV5XED3HBHIJJWPNYTM38GKBBEF52G4T4BO6
reny9phehn9n65ibtzjmp8mssof5lq4qkqh5s59l4ezpztqmp1kb8r6c13p
SZFCF44OC5IWAUYLFBY8HZE6TCY71DPXYJQLZ2VSLRJLFVSWKP3ERPVK
2o3l61lnch8kfyub9ecnj2uv5oeg1zb2qdmfieeo84hzenq7devn4liwhy
E66ALUU4CIGV29JRRU6WPWZC4EI1WCP5M55SOZE8PBM9OH5U7WLUEGW8W
1tsq2nanaolmpm21q164t5o1ry2wc5gcq25q8d72eanj87ep7stgq58wa
VPNGHS4AET938S0OH263OGOBK1HKV5NDUMJPVDQALPP1XXM9YFGG7YH7ZR
cteeydhbt8ak7ycksvpvy8yeu3db3wf9iazx7n8jo21xdhd5vafc24l0
V8K7ENHU8RAWL9WPPHHAC0ZVTWXL8R98GAJX5CDH7EKWZC64TM4VHVPTA86
chy2kxu9196hwzvgedt7giw8iq22e89gfymg2sf4s2nebuorx7pqjtq
3SO1H0IYX7COZLSMVCGAS4N94AAV7XIWK0FE7WVDPO2W68DJM0FVQE3F0MP1

With a fixed width font it looks almost like overlapping bat wings or
saw-tooth waveforms when laid on its side.


base64 fails ? :=)



{^_^}




Re: [SOLVED] I'm an idiot

2017-07-07 Thread jdow

On 2017-07-07 03:38, Rainer Sokoll wrote:



Am 06.07.2017 um 18:27 schrieb Rainer Sokoll :


[...]


Hm, I got an email from cron:

---8<--
/etc/cron.daily/spamassassin:
error: unable to refresh mirrors file for channel updates.spamassassin.org, 
using old file
channel: could not find working mirror, channel failed
sa-update failed for unknown reasons
---8<--


After losing some hairs it turned out that there are no problems in DNS, no 
problems in my network.
/etc/cron.daily/spamassassin changes UID:GUID to debian-spamd:debian-spamd 
during run.
But /var/lib/spamassassin/ was owned by root:root :-(

Sorry for all the noise,

Rainer


On the other hand, FireFox reports:
This site can’t be reached

updates.spamassassin.org’s server DNS address could not be found.
Go to http://spamassassin.org/
Search Google for updates spamassassin org
ERR_NAME_NOT_RESOLVED

{o.o}   God never promised us only one problem at a time.


Re: updates.spamassassin.org gone?

2017-07-06 Thread jdow

No A or PTR record:

===8<---
[jdow@thursday ~]$ dig updates.spamassassin.org ns1.apache.org all

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> updates.spamassassin.org 
ns1.apache.org all

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7892
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;updates.spamassassin.org.  IN  A

;; AUTHORITY SECTION:
spamassassin.org.   3415IN  SOA ns2.pccc.com. 
pmc.spamassassin.apache.org. 2017062901 7200 3600 604800 3600


;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 06 15:28:44 PDT 2017
;; MSG SIZE  rcvd: 125

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.apache.org.IN  A

;; AUTHORITY SECTION:
apache.org. 1800IN  SOA ns2.surfnet.nl. 
hostmaster-2005-alpha.apache.org. 2017070600 3600 900 604800 3600


;; Query time: 321 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 06 15:28:45 PDT 2017
;; MSG SIZE  rcvd: 115

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56671
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;all.   IN  A

;; AUTHORITY SECTION:
.   10740   IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2017070601 1800 900 604800 86400


;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 06 15:28:45 PDT 2017
;; MSG SIZE  rcvd: 107
===8<---

It looks like somebody fat fingered when updating the Apache.org NS records. (Or 
perhaps it was  ns.pccc.com that was fscked up perhaps on June 29th.)


{^_^}   Joanne

On 2017-07-06 11:39, RW wrote:

On Thu, 6 Jul 2017 12:14:02 -0500
David Jones wrote:


On 07/06/2017 12:02 PM, Rainer Sokoll wrote:
   

Am 06.07.2017 um 18:55 schrieb David Jones :
   

You can also run 'sa-update -vvv' to see more information on what
it's looking for.


Now I'm really confused: it works the way described in this thread:



   


That's odd.  Nothing has changed in DNS for almost 2 weeks so that
shouldn't have happened.


Both DNS txt lookups worked, all the HTTP downloads failed. If the
script has worked in the past, and nothing has changed, it was most
likely just a temporary networking problem.



Re: Absurd mail headers in new spam

2017-05-31 Thread jdow



On 2017-05-31 16:59, Kim Roar Foldøy Hauge wrote:

On Wed, 31 May 2017, John Hardin wrote:


On Thu, 1 Jun 2017, Benny Pedersen wrote:


 John Hardin skrev den 2017-06-01 00:29:

>   That sort of thing has happened before, and there are rules to *try*
>   to catch nonsense headers in my sandbox, but IIRC they never worked
>   well enough in masscheck to actually get published.

 would it be possible to make list of non nonsense headers, and count based
 on that how many other headers is in mail ?


Define "nonsense".

There are a fairly limited number of headers explicitly defined by the various 
RFCs which could be used to restrict the hits, but the number of *valid* 
headers is unbounded - any header that begins with "X-" is permitted.



 and thus based on how many other headers a mail have say its more spammy
 by to many no nonsense headers ?

 anyway food for bayes training


Potentially.

The headers' randomness could be a clue. Perhaps a plugin that records headers 
in a database with a "seen" count, and if a message has more than a half-dozen 
or so low-seen-count headers then it would earn a point or two. The risk there 
is FP on messages with a bunch of unusual but not-spammy headers.




To me, this sounds like an excellent candidate for some sort of bayes filtering. 
Use the headers to make tokens. Tokens token that are only in spam, or never 
seen before, should lead to a slightly higher score.


Regular headers should be scored 0 or an extremely low negative score.

Since headers are somewhat more limited than the body, there should be less room 
for false negatives if there is a decent default set of headers already in the 
database.


Legitimate mail with a lot of odd headers, is hopefully, a very rare occurance.

If I were to guess, adding such headers is done to confuse tools that compute 
hashes based on headers or use bayes filtering on the entire mail,

since it adds innocent words to the mail without showing them to most end-users.


That's basically the "Bayes Poison" argument. It should be possible to do 
better. I'm also finding here that a Bayes that remembered two word phrases 
could go a long way to killing off spam. (In this context a, and, the, his, and 
other such words would be ignored in gathering the two word phrases.) I suspect 
it would be a nasty piece of code to write; but, I do think it could produce 
some nice results. Specifically results on the random headers might be pretty 
good, too.


{^_^}


Re: HTTPS_HTTP_MISMATCH and explanation

2016-09-25 Thread jdow

On 2016-09-25 12:39, Alex wrote:

Hi,

On Sun, Sep 25, 2016 at 3:29 PM, Sean Greenslade
 wrote:

On Sun, Sep 25, 2016 at 03:12:00PM -0400, Alex wrote:

Hi, I'm seeing quite a few FPs with HTTPS_HTTP_MISMATCH and its score
of 2.0. Isn't that kind of high for a rule that doesn't even have a
description?

Can someone explain what the rule does, and consider whether its score
should be adjusted?

Thanks,
Alex


From my quick glance over the code, it looks like that rule is meant to
trigger when a link presents its text as an https://... link, however
the actual link is to an http://... URL. Like this:

http://spammersite.com/virus";>https://www.email-service.com/login

The only place I would imagine false positives arising from this rule
would be if an email sender uses some sort of automatic link replacement
(e.g. for click-through tracking) that doesn't support https. And I
personally am inclined to agree that an email that mis-represents
insecure links as secure should be considered suspisious.

Contact the senders of the flagged emails and ask them to fix their
systems. Spam or not, that is a real problem.


I think it must be something more than that. I've included the HTML
component of an FP I received, and I don't see any occurrences of an
https link where the text component is just http, or even vice-versa.

http://pastebin.com/BNM9sLRL

The HTML is a bit hard to read. Let me know if you want the whole
email (which is even harder, consider it's encoded, so you'd have to
actually run it through SA).

Thanks,
alex


These days even mixed links, some https and some simple http, is suspicious. 
It's easy to include https links to page elements and an http link to the real 
intended payload. With http you know nothing about who sent it. With https you 
know either who sent it or who has an insecure system. Conceptually you can turn 
your pet lawyer loose on 'em. (That being the "nicest" thing I think should 
happen to them.)


{o.o}


Re: HTTPS_HTTP_MISMATCH and explanation

2016-09-25 Thread jdow

Yeah, it should have a much higher score.

{O.O}

On 2016-09-25 12:12, Alex wrote:

Hi, I'm seeing quite a few FPs with HTTPS_HTTP_MISMATCH and its score
of 2.0. Isn't that kind of high for a rule that doesn't even have a
description?

Can someone explain what the rule does, and consider whether its score
should be adjusted?

Thanks,
Alex



Re: SoughtRules

2016-08-29 Thread jdow

On 2016-08-29 22:42, Axb wrote:

On 08/30/2016 07:32 AM, jdow wrote:

On 2016-08-29 17:51, li...@rhsoft.net wrote:


Am 30.08.2016 um 02:45 schrieb John Hardin:

On Mon, 29 Aug 2016, Anthony Hoppe wrote:


I just learned about the sought ruleset via
https://wiki.apache.org/spamassassin/ImproveAccuracy.  Is this ruleset
still actively maintained?  I'm considering implementing it in my
environment, but want to make sure just in case.


Sadly, no. I think it's been at least a couple of years since they were
regenerated


but they still hit junkmails and are even part of the fedora default
install
pulled with the first "sa-update"

rpm -q --file /etc/mail/spamassassin/channel.d/sought.conf
spamassassin-3.4.1-9.fc24.x86_64

cat /etc/mail/spamassassin/channel.d/sought.conf
# http://wiki.apache.org/spamassassin/SoughtRules
CHANNELURL=sought.rules.yerp.org
KEYID=6C6191E3
# Ignore everything below.
return 0




The late lamented SARE rule sets also work remarkably well if you
captured a suitable snapshot.

{^_-}


But some are a huge source of FPs...

After SARE shutdown I dumped the last release (for posterity)
https://sourceforge.net/p/sare/code/HEAD/tree/rules/DO-NOTUSE-rulesets-obsolete-/

be VERY carefull when playing with them - they are a huge 7 year old can of 
worms.



They sure can be. I spent time winnowing the particularly bad rules out. I still 
make custom rules that are quite helpful, especially for large mailinglists such 
as the LKML. I use a collection of meta rules to expand Bayes scores away from 
about 80. Otherwise I get too much ham getting punished for too little spam 
getting punished. Now it errs somewhat too far towards ham getting through 
meaning LKML leaks spam. But, what gets through is usually quite humorous 
considering the LKML relay.


{^_^}   Joanne says, "One woman's spam is another man's ham. How ya gonna score 
it?"


Re: SoughtRules

2016-08-29 Thread jdow

On 2016-08-29 17:51, li...@rhsoft.net wrote:


Am 30.08.2016 um 02:45 schrieb John Hardin:

On Mon, 29 Aug 2016, Anthony Hoppe wrote:


I just learned about the sought ruleset via
https://wiki.apache.org/spamassassin/ImproveAccuracy.  Is this ruleset
still actively maintained?  I'm considering implementing it in my
environment, but want to make sure just in case.


Sadly, no. I think it's been at least a couple of years since they were
regenerated


but they still hit junkmails and are even part of the fedora default install
pulled with the first "sa-update"

rpm -q --file /etc/mail/spamassassin/channel.d/sought.conf
spamassassin-3.4.1-9.fc24.x86_64

cat /etc/mail/spamassassin/channel.d/sought.conf
# http://wiki.apache.org/spamassassin/SoughtRules
CHANNELURL=sought.rules.yerp.org
KEYID=6C6191E3
# Ignore everything below.
return 0




The late lamented SARE rule sets also work remarkably well if you captured a 
suitable snapshot.


{^_-}


Re: New Install - Tons of Spam Getting Through

2016-08-18 Thread jdow

On 2016-08-18 17:11, RW wrote:

On Thu, 18 Aug 2016 18:14:47 -0500
Jerry Malcolm wrote:



I'm still trying to see why I'm not getting the report back.  I've
gone all the way back to the source code that does the streaming of
the spamd invocation on port 783.   I can't seem to find the
documentation anywhere on the format of the data I should read back
on port 783 from spamd.   It looks like I'm getting two text lines
back on the read: SPAMD/1.1 0 EX_OK
Spam: True ; 7.7 / 5.0



This a waste of time. Just try sending a file to spamd  with spamc and
look at the output. If the header is missing them SA is probably not
picking up the config. If it is then the problem is with James.

My guess is that James adds the x-spam-status header itself.



And I suppose the following line in local.cf is insufficient for James' needs?

rewrite_header Subject *SPAM* _SCORE(00)_ **

Then all he need to do is look for the string "*SPAM* _SCORE(" in the 
title of the message and sort it into the spam bucket.


{o.o}


Re: My new method for blocking spam - REVEALED!

2016-01-20 Thread jdow
This observation invites a heretical question. Is nearly perfect spam 
classification dangerous compared to merely 99.9%/0.1% accurate classification? 
If people get used to no spam do they become more vulnerable to really well 
crafted spam?


{o.o}

On 2016-01-20 14:48, Marc Perkel wrote:

It could be challenging if someone impersonated a bank and they did it right.
I'm looking at more aspects than just the content of the message but that's an
area where there is some possible weakness. There are other tricks to address
the specifically. And I am looking at behavior and headers as well.

To be a little clearer. This new system isn't perfect. And it's main strength is
identifying good email. It does catch a lot more spam for sure but when people
scream at me it's because I blocked something important. So think of this more
as detecting ham as it's big feature.

On 01/20/16 14:37, jdow wrote:

And just how well does this work against spearfishing? And would the same
magic list work for ma and pa Kettle well into their 80s only receiving emails
from their children and Freddie Burfle with his heads buried in a corporate
accounts payable office?

{^_^}




Re: My new method for blocking spam - example

2016-01-20 Thread jdow

On 2016-01-20 13:26, Matt Garretson wrote:

I am not an expert but it does seem like the main novel thing is how
(and how many) multi-word tokens are generated.  I use have been using
multi-word tokens with bogofilter for years and it does help.  Of course
bogofilter only uses adjacent words -- perhaps OP's way of combining
words could yield an increase in accuracy, at the expense of processing
time.

The stuff about not-matching rather than matching seems like nonsense.

Not to sound mean, but this is not the first time OP has come out with
the latest greatest revolution in spam blocking.  :)  I admire his
dedication, in any case!



Matt, it's amazing how many times this particular person has come up with the 
greatest secret sauce This reads like deja vu all over again to me.


{^_^}


Re: My new method for blocking spam - REVEALED!

2016-01-20 Thread jdow
I wonder how this differs from some of the classifiers within CRM114. Several of 
them seem to work on phrases (with high costs) or single words.


{^_^}

On 2016-01-20 11:05, Dianne Skoll wrote:

On Wed, 20 Jan 2016 08:52:05 -0800
Marc Perkel  wrote:


Suppose I get an email with the subject line "Let's get some lunch".
I know it's a good email because spammers never say "Let's go to
lunch".


Really?  You know that for a fact?


In fact there are an infinite number of words and phrases
that are used in good email that are never ever used in spam.


Really?  You know that for a fact?  [I mean, it's demonstrably false
that the number of good words and phrases are "infinite", but I'll give
you the benefit of the doubt and assume you mean "very large"]


A new message comes in. It is tokenized and fingerprinted and
hundreds of fingerprints are generated. Then it's all set operations.
the set of fingerprints of the test message is intersected with the
spam and ham corpi creating sub sets of matches. Then you do a set
diff both ways (ham - spam) (spam - ham) and whichever side is bigger
wins. Generally it will match on only one side or very predominately
on one side.


I see what you're doing... if there are more tokens that have been
seen in ham but NEVER in spam than the other way around, it's hammy,
otherwise spammy.

But I'm not convinced this will actually work.  In fact, it seems that
this algorithm is even more susceptible to poisoning than Bayes.
Because it only relies on a token *ever*, even once, appearing in a
ham or a spam, it's far more sensitive to poisoning... just *one*
appearance of a ham-token in a spam poisons that token for all time and
vice-versa.


SpamAssassin is all about matching rules. This is all about not
matching. Not matching allows you to compare to an infinite set
rather than a finite set. So when spammers start misspelling words to
not match the rules, my system catches that and makes its own rules.


Bayes does that too.  And probably with more theoretical justification.


This new method (I'm calling it the Evolution Spam Filter because the
algorithm mimics evolution.) it doesn't just block spammers, it
decimates spammers. It's not just a treatment - it's the cure.


I think it's FUSSP.  I have no doubt that the algorithm works *for
you* because you probably only see a really tiny percentage of the
email on the whole Internet.  And also, for small data sets, it
probably gives results very similar to Bayes which is itself quite
effective, especially if you consider multi-word tokens.

I doubt it will be or remain any more effective than Bayes if used
widely.  I'd be happy to be given hard data proving me wrong, though.


The side effects is this is a very fast and simple recursive learner.
What happens is that as people converse by email it learns more words
and phrases about the stuff that people talk about that are never
used in spam.


Bayes does that too.


It doesn't have to know what language you are using, it
will learn it on it's own.


Bayes does that too.

Regards,

Dianne.



Re: My new method for blocking spam - REVEALED!

2016-01-20 Thread jdow
And just how well does this work against spearfishing? And would the same magic 
list work for ma and pa Kettle well into their 80s only receiving emails from 
their children and Freddie Burfle with his heads buried in a corporate accounts 
payable office?


{^_^}

On 2016-01-20 08:52, Marc Perkel wrote:

OK - following up on this. I have my provisional patent filed. I'm still doing
development to improve it and working on a licensing contract. But the license
will be based on the Creative Commons patent with some restrictions added.
Basically I want to get a license fee from the big guys and my spam filtering
competitors. So unless you are in the spam filtering business or have more than
10,000 email addresses it's not going to cost you anything.

I'm going to describe the concept here. I'm not going to share my code because
my code is specific to my system and it a combination of bash scripts, redis,
pascal, php, and Exim rules. And the open source programmers are likely to
implement it better than I have. Basically I'm trying not to put myself out of
business and this new method is a bigger breakthrough than Bayesian filtering.

Maybe I should call it a new plan for spam?

So - I'm just going to introduce the concept right now about how it works. Once
you know what I'm doing it should be easy to implement, I had it working in a
couple of days and I'm not an outstanding programmer. One thing to keep in mind
is this is a paradigm shift. It's not about matching - *it's about NOT
matching*. And although it is far better at catching spam, it best feature is
actively identifying good email.

The secret sauce

Suppose I get an email with the subject line "Let's get some lunch". I know it's
a good email because spammers never say "Let's go to lunch". In fact there are
an infinite number of words and phrases that are used in good email that are
never ever used in spam. And if I'm using words and phrases *never used in spam*
that are used in ham - it's good email. And similarly - if I'm using words and
phrases that are used in spam and *never used in spam* - it's spam.

So - how do I get a list of words and phrases never used in spam? I create a
list of words and phrases that are used in spam and check to see if it's *not on
the list*.

What I do is tokenize the spamiest parts of the email, like the subject line,
into words and phrases of 1 2 3 and 4 word phrases.

the quick brown fox jumps over the lazy dog - becomes

"the" "quick" "the quick" "brown" "quick brown" "the quick brown" "fox" "brown
fox" "quick brown fox" "the quick brown fox" "jumps" "fox jumps" "brown fox
jumps" "quick brown fox jumps" "over" "jumps over" "fox jumps over" "brown fox
jumps over" "the" "over the" "jumps over the" "fox jumps over the" "lazy" "the
lazy" "over the lazy" "jumps over the lazy" "dog" "lazy dog" "the lazy dog"
"over the lazy dog"

These tokens are learned as ham or spam and added to sets. I'm using Redis to do
this because it has extremely fast set operations. I don't know of anything
other than Redis that can do this. So think about Redis as the way to implement
this.

A new message comes in. It is tokenized and fingerprinted and hundreds of
fingerprints are generated. Then it's all set operations. the set of
fingerprints of the test message is intersected with the spam and ham corpi
creating sub sets of matches. Then you do a set diff both ways (ham - spam)
(spam - ham) and whichever side is bigger wins. Generally it will match on only
one side or very predominately on one side.

So I'm not just tokenizing the subject. Also the first 25 words of the message,
the text of links in the message, The name part of the from address, The header
names, the attachment names, the PHP script if there is one, and various
behavior characteristics, (slow, no quit, no RDNS, number on mime parts,
multiple recipients, etc.)

SpamAssassin is all about matching rules. This is all about not matching. Not
matching allows you to compare to an infinite set rather than a finite set. So
when spammers start misspelling words to not match the rules, my system catches
that and makes its own rules. The tricks that spammers use not makes it easier
to catch them using this method.


I will post a link to a better explanation later when I write one. But wanted to
let you all know this wasn't just a tease from some crazy person.

So - here's what I want to see happen.

I'd like to see SA implement this. I will provide a license to include with it
giving most people a free license. sort of like how Spamhaus isn't free to
everyone, but it's in SA. Then the new method will take off and eventually I'll
get a little something for this.

This new method (I'm calling it the Evolution Spam Filter because the algorithm
mimics evolution.) it doesn't just block spammers, it decimates spammers. It's
not just a treatment - it's the cure. I hate spam and although I could have kept
this secret and made money having the best spam filter on the planet, I decided
I had a 

Re: I have developed a new method of blocking spam that's a game changer

2016-01-13 Thread jdow
Setup some accounts to receive LKML, Ubuntu, Fedora, and several other technical 
high volume mailing lists as well as normal email. Let us know how it works.


I'm reminded of a mantra of mine from some years back here, "One man's spam is 
another man's ham." You must also handle this phenomenon, too.


{^_^}

On 2016-01-13 17:11, Marc Perkel wrote:

OK - this might sound a little unbelievable but I'm not making this up. I want
to introduce this because I'm hoping to release this soon and I want to create
some buzz and anticipation. I'm not going to talk about the details yet but I
hope to soon.

I just filed a provisional method patent on the method and tomorrow I'm going to
be talking to some investor types about it. I'm also working on improving the
methods I'm using, but this new trick is so accurate that 1 month ago if someone
asked me if this level of accuracy was possible, I would have said - no way!

I'm calling it the Evolution Filter. The name is somewhat of a clue to how it
works.

I'm seeing levels of accuracy getting really close to 100%. And it's especially
good at actively detecting good email so false positives are almost not 
existent.

I've been filtering spam now for 15 years and been on this list for about that
long and I'm not the kind of guy to just make this stuff up.

My intent right now is to just get enough IP protection so I can get a license
fee from the big corps. I plane on giving it away free to the little guys. So
that if you have less that 10,000 email accounts it's free. Hoping to get like 1
cent per email account per year from the big guys.

Although this idea is very unique, it's actually rather simple to implement. I'm
using Redis and since SA is also using redis it should be trivial to add it to
SA. My programming skills are good but not great. So the developers here should
be able to do a significantly better job than me. It only took me an afternoon
to implement the concept and it was already impressive with just 3 hours of
learning.

This is not Bayesian or remotely similar to Bayesian. It does use a DB like
Bayesian does and there is learning involved. But it's probably 100x better at
detecting spam and 1000x better at detecting good email.

My plan is that this technique is going to be so good that everyone is going to
immediately implement it. And because of that the big boys will license it from 
me.

The accuracy is so good that it could put many spammers out of business. It can
recognize spam more accurately that I can by hand looking at someone elses 
email.

If someone on this list wants to verify that I'm not just smoking the wrong kind
of cigarettes I'm willing to let people test it on the condition that you report
back here and tell everyone what your experience is.

If anyone has some feedback about how I can make this available to everyone and
make a little something in licensing fees I'm definitely listening. I do want to
release this to you all soon because you'll probably make it better than I have.

I have a little more info on Dvorak's blog.

http://www.dvorak.org/blog/2016/01/12/i-invented-a-new-way-to-filter-spam-thinking-about-a-patent/




Re: A Plan to Stop Violence on Social Media

2015-12-16 Thread jdow

On 2015-12-16 14:15, Wrolf wrote:

Video/audio/stills are a problem.

How about crowd sourcing ISIS identification, with sufficient votes (of
sufficient reputation) leading to RBL style blocking by IP address, and
retroactive elimination of posts spread across all media?

BTW, I am aware that Facebook has programmers. They seem not to have been
engaged on this subject. I am looking for a technical discussion before I engage
in the political process. One US presidential candidate has already challenged
Silicon Valley to solve this.

Interested if anyone knows any other forums for this discussion.

Wrolf


One thing worth pointing out is if this CAN be done refusing to do it yourself 
is a shallow gesture. If it can be done somebody will do it. It is probably 
better to get it out there in the open rather than hidden behind NSA, KGB, MI-5, 
or other backs.


{^_^}


Re: command arguments for spamd on FreeBSD

2015-09-26 Thread jdow

On 2015-09-26 16:25, Mark Martinec wrote:

I recently updated SpamAssassin to version 3.4.1 on FreeBSD
8.4-release p36, running Postfix/Dovecot2.
My question is simple, how do I pass command arguments to spamd? (and
did this change since 3.3.x?)
I am quite sure that before upgrading the following lines in rc.conf
worked correctly to pass flags to spamd:
spamd_enable="YES"
spamd_flags="-s local5"
spamd_command_args="-d -A [2a03:6000:::xxx] -u spamd -x -q -r ${pidfile}"
But after the update the line "spamd_command_args" seems to be ignored.


Put all command line options for spamd in spamd_flags.

   Mark



Yup, I left that deduction as an exercise for the student.

{^_-}   (Been writing rules since something like 2.1.3something) give or take.)


Re: Rule Help

2015-09-26 Thread jdow

On 2015-09-26 07:12, RW wrote:

On Fri, 25 Sep 2015 10:28:42 -0400
Dianne Skoll wrote:


On Fri, 25 Sep 2015 14:21:50 +
Dave  wrote:


I am trying to create a rule that scores TLD's in received headers
if they are not certain TLD's. What I have so far:


Your logic is wrong.  And you can do it all with one regex:

header GC_TLD_COM Received !~/\.(?:com|net|org|edu|uk)\b/i

I won't comment on the advisability of such a rule; the policy is up
to you. Also beware that this will trigger on IPs with no reverse DNS.


There's usually a helo hostname even if there's no rDNS. The real
problem, as in the original rule, is that a single .com, .net etc
anywhere in the received headers causes it to fail.

Looking for any tlds that aren't on a list is fraught with problems -
particularly if you try to do it with received headers.


You mean something like, "badnetizen.borg.combeduck.foobar.yukky"?

{O.O}


Re: SA doesn't respect my user_prefs

2015-09-09 Thread jdow

On 2015-09-09 13:51, RW wrote:

On Wed, 9 Sep 2015 17:27:54 +0200
Marc Richter wrote:


Hi RW,


Do you mean that ww is a unix user? The normal way to do this is to
run spamd as root and run spamc as the unix user. Passing -u to
spamc is really intended for virtual users, I'm not sure whether it
works for unix users.  Are you sure it worked before?


ww is a unix user, yes. And it worked before, yes.


Supporting that sounds like a really bad idea. It would mean that any
user could make a spamd child run as any unix user they choose -
possibly even root. It's an unnecessary risk of privilege escalation.

It also gives users too much access to each other's databases. A
malicious user would be able to miss-train another user's Bayes or
manipulate reputations in TxRep or AWL. It would also be possible to
infer some of the contents of another users TxRep database from
suitable test emails.


Why don't you try to run spamc -u root as a common user and see what happens 
then talk about the results if it is warranted?


{o.o}


Re: SA doesn't respect my user_prefs

2015-09-09 Thread jdow

Is this line in your "local.cf" file? (And is it in the correct place?)

allow_user_rules 1

{^_^}

On 2015-09-09 04:47, Marc Richter wrote:

Hi jdow,
hi Matus,

thanks for your replies.

Regardless if it's necessary or not, I have done so. It also happens regularly
by cron (all 3 hours), along with other jobs like sa-learn, sa-update and
sa-compile.

 > On 09.09.2015 11:12 Matus wrote:
 >
 > have you tried running spamassassin -D ? maybe there's somethign
 > invalid in SA's configuration or your user_prefs

When I issue "spamassassin --test-mode -D" as the user the filter.sh - runs as,
I get this in the long output:

dbg: config: read file /var/lib/spamassassin/.spamassassin/user_prefs

So, it tries to read the user_prefs from the daemon's home, what is clear,
because it cannot know what user the file "belongs" to, in test-mode.
When I run that as the user (ww) the mail and desired user_prefs belongs to, it
works, so no use in that.

How can I make use of the "-D" cmdline option in the normal mail-flow in a way
it gets logged by journald? Can I simply add "-D" to the filter.sh script and it
get's caught in journald's database?

How else can I test this?

Sorry if I'm slow in understanding atm ...

Best regards,
Marc



Re: SA doesn't respect my user_prefs

2015-09-09 Thread jdow

I presume you restarted spamd, right?

{^_^}

On 2015-09-08 23:46, Marc Richter wrote:

Hi everyone,

I'm running SA 3.4.1 with Perl 5.22.0 .
It works quite well, but since a few weeks, it looks like my user_prefs isn't
taken into account by SA anymore. Let's show this by example:

There are *lots* of blacklist_from entries in there; one of them is:

blacklist_from  *@neuronation.*

Today, I got another mail with the following (relevant) headers:

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 tango012.marc-richter.info
X-Spam-Level: ***
X-Spam-Status: No, score=3.6 required=4.0 tests=BAYES_99,BAYES_999,DKIM_SIGNED,
  DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,
  RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS,URIBL_BLOCKED
 autolearn=no autolearn_force=no version=3.4.1
From: NeuroNation 
Date: Wed, 09 Sep 2015 06:05:02 + (UTC)

Thus, this mail should get +100 for matching my blacklist_from entry. But, as
you can see, it isn't.

When I'm running "spamassassin --test-mode < my_maildir_file", I get expected
results:

spamassassin --test-mode < .maildir/cur/msg.SbGC\:2\,S

[...]
Inhaltsanalyse im Detail:   (99.9 Punkte, 3.0 ben�tigt)

Pkte Regelname  Beschreibung
 -- --
  0.0 URIBL_BLOCKED  ADMINISTRATOR NOTICE: The query to URIBL was 
blocked.
 See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
  for more information.
 [URIs: neuronation.de]
-0.0 RCVD_IN_MSPIKE_H3  RBL: Good reputation (+3)
 [192.254.116.16 listed in wl.mailspike.net]
  100 USER_IN_BLACKLIST  From: address is in the user's black-list
  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
 domains are different
-0.0 SPF_PASS   SPF: Senderechner entspricht SPF-Datensatz
  0.0 RP_MATCHES_RCVDEnvelope sender domain matches handover relay 
domain
  0.0 HTML_MESSAGE   BODY: Nachricht enth�lt HTML
-0.1 DKIM_VALID_AU  Message has a valid DKIM or DK signature from 
author's
 domain
  0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily
valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.0 RCVD_IN_MSPIKE_WL  Mailspike good senders

SA is started by postfix; in the master.cf of postfix there are these lines:

smtp  inet  n-n--smtpd -o content_filter=spamassassin
spamassassin
 unix  -nn--pipe
 flags=Rq user=spamfilter argv=/home/spamfilter/filter.sh -oi -f ${sender}
${recipient}

/home/spamfilter/filter.sh contains:

#!/bin/sh
# filter.sh
#
# This script redirects mail flagged as spam to a separate account
# You must first create a user account named "spamvac" to hold the flagged mail
SENDMAIL="/usr/sbin/sendmail -i"
SPAMASSASSIN=/usr/bin/vendor_perl/spamc
COMMAND="$SENDMAIL $@"
USER=`echo $COMMAND | awk '{ print $NF }' | sed 's/@.*$//'`
NEW_COMMAND=`echo $COMMAND | awk '{ $6 = "spamfilter"; NF = 6; print }'`
# Exit codes from 
EX_TEMPFAIL=75
EX_UNAVAILABLE=69
umask 077
OUTPUT="`mktemp /tmp/mailfilter.XX`"
if [ "$?" != 0 ]; then
 /usr/bin/logger -s -p mail.warning -t filter "Unable to create
temporary file."
 exit $EX_TEMPFAIL
fi
# Clean up when done or when aborting.
trap "rm -f $OUTPUT" EXIT SIGTERM
$SPAMASSASSIN -x -E -u $USER > $OUTPUT
return="$?"
if [ "$return" == 1 ]; then
 $NEW_COMMAND < $OUTPUT
 exit $?
elif [ "$return" != 0 ]; then
 /usr/bin/logger -s -p mail.warning -t filter "Temporary SpamAssassin
failure (spamc return $return)"
 exit $EX_TEMPFAIL
fi
$SENDMAIL "$@" < $OUTPUT
exit $?

SA should have access to my user_prefs; these are the groups for the user
"spamfilter":
tango012 ~ # groups spamfilter
users spamd
tango012 ~ #

The full path-permission to my user_prefs are:
ww@tango012 ~ $ ls -ld /home /home/Whitewolf_Fox
/home/Whitewolf_Fox/.spamassassin /home/Whitewolf_Fox/.spamassassin/user_prefs
drwxr-xr-x 13 root root  4096 23. Jul 10:36 /home
drwxr-xr-x 27 ww   users 4096  9. Sep 08:32 /home/Whitewolf_Fox
drwxrwx---  2 ww   spamd 4096  9. Sep 08:32 /home/Whitewolf_Fox/.spamassassin
-rw-rw  1 ww   spamd 8622  4. Sep 15:15
/home/Whitewolf_Fox/.spamassassin/user_prefs
ww@tango012 ~ $

Standing here, I'm out of ideas, since this looks all good to me.

Can somebody imagine what's wrong here?

Best regards,
Marc



Re: Barracuda / EmailReg.org protection racket? (OT, but help?)

2015-06-29 Thread jdow
Ted, there is one ISP who insisted on blocking all emails sent from my system 
because the internal network is "odd". It's not "localhost.localdomain" or 
whatever it was they were looking for. And it appears on my email headers. They 
decided "wizardess.wiz" is an illegal domain so the email from it should not be 
allowed. Unfortunately one of my regular correspondents is on knology.net. So he 
complained enough and they fixed it. Every once and awhile it kicks in again. 
(Note that I do NOT run an MTA here. Email goes directly to dslextreme or 
earthlink from here. Both were blocked at the same time. The only thing in 
common with the two MTAs is the received from header from this machine I am on.)


There are any number of poorly thought out block lists. I rather carefully 
consider their use here. At one point I got into a somewhat heated email 
argument with Paul Vixie over his blocking my email addresses because of what we 
now call "Joe Jobs". I made some unfortunate conclusions about his being a total 
jerk despite his being one of the bind utility's chief daddies. He did good 
work. He just had a screwdriver and needed a hammer which was more than 20' out 
of his way so he banged on the problem with his Jolly Green Giant size 
screwdriver handle. (And I am jerk enough I'd still like to stick his 
screwdriver blade up his nose after subduing him with my rolling-pin stereotype.)


Fortunately or unfortunately it is impossible in the US to make it formally 
illegal to be a total jerk. So we will always have jerks to deal with. Block 
lists seem to be run by people who devolve into being total self-righteous jerks 
over time. Sadly we have to deal with whatever we face.


{^_^}   Joanne

On 2015-06-29 10:16, Ted Mittelstaedt wrote:


On 6/27/2015 4:02 AM, Noel Butler wrote:

Although what you describe is a "workaround", the key is to keep your
house in order so you don't get listed, especially if you have not
actually fixed up the problem,


Oh Noel, why are you giving me fish in a barrel to shoot?

OK, now that you put your foot in it, please elaborate on how a
"house is kept in order" that will protect it from idiots.  This is
going to be fun!

Oh and don't forget to define the difference between chronic offenders
and just regular people who get nailed for no reason.

  DNBSBL's are just like local sys admins,

they get tired of adding in /32's after /32's for the same @$#holes,
thats when the /32's get removed and /24's get added, it wont take too
long to end up blocking all of your ranges. In fact since you've made
public your stance, it is likely anyone blocking your IP range, and
discovering its your service, may decide to block all of your IP ranges
first off to avoid wack-a-mole games.



Did it ever, possibly, occur to you that my 'workaround' wouldn't work
if someone has a chronic problem?  Nor would it work if someone was just doing
it because they were too lazy to fix an open relay because
the backup IP would just instantly get RBLed again.

Why do you think I RECOMMENDED doing it?  Do you think that _I_ want to
get spammed by the OP if he doesn't know WTF he is doing?

The beauty of my suggestion is if the OP is just going to try doing
it because he doesn't want to clean up his setup, it won't work.

Get it, now?

That's precisely why anyone out there reading this who is running an RBL
is going to ignore "my stance" as you put it.

They know that if I can defeat their RBL by simply switching IP's then
their RBL has a problem.  Because, switching IPs is what snowshoe spammers do
every day and if they cannot block me switching an IP then
they cannot block them and their RBL isn't worth a bucket of hog slop.


Not many people I know have any faith in reputation services that try
"whitelist", but there are a tiny minority that apparently do, though
I've not known or in 25 years heard of, anyone getting blocked because
your using a new IP address on a system sending mail


Nor have I which is one of the primary reasons I thought that what
Reindl said about new IPs was a load of baloney.

  (why should we care

if its a new IP, or a 20yo IP - whats more of interest to us is how new
your "domain" is, who your registrar is, what your authoritative NS's
are, thats where we spam score you, backing off a bit as days and weeks
go by), I'd be more concerned for the users of such a wacky reputation
service than the fact they might block a new IP of mine or whosever.



Agreed.  Unfortunately, there ARE such wacky reputation service out there -
fortunately they are in the minority - and occasionally users will want to email
people who are using them and you have to know how
to get around those wacky services.

Ted


Given most medium and large networks use multiple servers for sending
customer mails, when the load balancers are showing the existing cluster
needs expanding, we add more into the cluster, so I cant see anyone
stupid enough to use a service blocking new IP's, if they do, they
deserve all th

Re: Macs/Yosemite can no longer send abuse reports

2015-06-29 Thread jdow

On 2015-06-29 08:37, Ben wrote:



I can't speak about the specifics of this particular change, but
anything that makes it harder to trivially forward a message,


Whilst I obviously can't argue with you in the context of making it easy to
report spam, there are a couple of things to point out.

First, Jo said "have removed all functionality", that is technically and
factually incorrect, which is why I posted the message I did.  Other methods
remain available and all that needs to be done is for Jo to update the
instructions to users.

Second, I'm becoming less and less of a buyer on the whole "report it to the
ISP" malarky.  Its starting to become a bit of a 1990's way of doing it.   I
increasingly find myself wondering whether ISPs actually bother to read abuse
mails or whether they get filtered straight to /dev/null.

Case in point on number two, for some months now I have been receving Spam
originating from a Verizon customer. The Verizon customer appears to be some
sort of marketing company that has a range on the Verizon network.

Every...single...time... I report the spam, full headers & all.  Have they done
anything about it ?  No.  Has the volume of spam reduced ? No.

I ended up blocking that IP in a custom RBL that I feed into SpamAssassin.

Sure, I guess for tweaking your internal SpamAssassin implementation, headers
could be useful.  But for external reporting, I think they've had their day.


It's an excellent tool for gathering active addresses. Then the spammer simply 
has to craft an email that makes it through the filters, likely sent from a 
completely different source.


Reporting to the ISPs is, except in unusual circumstances, seems to be an 
exceptionally counter-productive trick.


That said, it might pay to catch the mails in the MTA and drop them there. Then 
the naifs at the keyboard think they'd done something useful and you've actually 
made it useful by leaving that address a black hole. Eventually the addresses 
will fall from the live addresses lists and fall to the secondary "we're gonna 
keep trying forever" lists.


{^_^}


Re: CryptoWall experience?

2014-12-22 Thread jdow

On 2014-12-22 19:38, Noel Butler wrote:

On 23/12/2014 12:00, jdow wrote:


And ClamAV is better than nothing. Safe browsing is more pertinent. Dual AV 
programs also help, but slow the machine down dramatically. Some of the newer 
tools that use other levels of analysis from typical AV tools can also 
materially help.


I wouldn't say dramatically Jo, clamav is a resource hog though, some commercial
stuff like fprot are very snappy and no noticeable load increases.

Merry Xmas

PS - I upped the size of this msg font just for you :)


I appreciate that. Thanks.

{^_-}


Re: CryptoWall experience?

2014-12-22 Thread jdow
SA offers no protection whatsoever for CryptoWall or any other similar malware. 
ClamAV is the tool for that if you want "free". SA is only a classifier. The 
user's setup or that of the ISP using SA uses that classification to pigeonhole 
spam. To the extent that CryptoWall comes in a message that looks like spam 
there is some protection, depending on how SA is deployed with secondary tools. 
SA itself merely classifies spam.


If the machine has been hit by something like CryptoWall getting anything off of 
it is unlikely.


And ClamAV is better than nothing. Safe browsing is more pertinent. Dual AV 
programs also help, but slow the machine down dramatically. Some of the newer 
tools that use other levels of analysis from typical AV tools can also 
materially help.


This is probably the wrong venue for this question.

{^_^}   Joanne

On 2014-12-22 16:56, Alex Regan wrote:

Hi all,

I suspect at least one of my customers has been hit with CryptoWall 2.0, and
wondered if anyone had any experience with it, and understand the level of
protection the latest SA provides?

What can I look for either in the mail logs or actual email archives as an
indication of potential issues?

If you're infected, does it automatically mean your hard disk is encrypted and
otherwise useless, or does it affect a system to varying degrees?

Is this even more of a clamav issue? Do you have any knowledge about clamav
patterns?

Thanks,
Alex



Re: ancient perl versions

2014-12-05 Thread jdow
I'll break it down - it may be a little smaller in appearance. It's on the edge. 
The prior settings worked nicer.


This one declares a body style='font-size: 10pt'. Then for each paragraph it 
declares span style=3D"font-size: small;".


It sounds like Roundfile or whatever it was (can't remember - don't want to - 
web mail is an abomination - I am THAT old) and T'bird combined have some really 
peculiar rendering notions.


{o.o}

On 2014-12-05 19:07, Noel Butler wrote:



Since this appears recent, I wonder if its a rc 1.0.3 issue..

again, manually setting to this 12pt, yet looks same as what people see
as 10pt

On 06/12/2014 02:03, John Hardin wrote:


On Sat, 6 Dec 2014, Noel Butler wrote:


pffft I see no problem,




pffft






Re: ancient perl versions

2014-12-05 Thread jdow
Hm, it renders much more readable. I normally default reading to about 12 to 14 
point fonts. The 10 point was getting down to a size that some letters were 
becoming ambiguous, which seriously slows down reading.


Thanks for trying.

As a side note I see that the plain text of mine you quoted is rendered as about 
14. That's a not unusual mutation for MUAs it seems. There is no font size 
declaration so it may be a result of some of the things I did to T'bird trying 
to see if I could tame stuff. The humor this look revealed is that yuor messages 
is "font-size: x-large;". And about 12pt is what T'bird classifies as x-large it 
appears. Most humorous.


I hope you have a good one.

{^_^}

On 2014-12-05 19:04, Noel Butler wrote:



Ted is always impolite, but he's right that the current roundcube editor
is shocking, in many ways (but not teh way mentioned here) and a few
people have brought this up, I understand my gripes are fixed, I'll soon
know in a week or two. It is rare that I post in here anyway, I've
posted more in past couple days than most of the last 10 years combined
:)

BTW RC now tells me this is 12pt, yet looks no bigger than before.

On 06/12/2014 06:29, jdow wrote:


Ted was remarkably impolite the way he phrased it. BUT, I will say as a 
practical matter microprint emails do get rather short shrift from me when 
scanning through message threads. I seldom dig in here of late. But I do scan 
through the messages which look interesting and sometimes offer such advice as 
I can. (Usually on topics a simple Google search doesn't help with.) I'm sure 
my advice would be equivalent to much other advice you might get from people 
whose eyes are better than mine. And mine are far better than most of my 
contemporaries and some of my former co-workers at the time. But, on the very 
small chance that advice from me or someone with worse vision than even me 
might help, it might be a good idea to send emails that are more readable.

I am sure I am not the only person here who would appreciate it.

Thanks

{^_^}

On 2014-12-05 07:38, Noel Butler wrote:
pffft I see no problem, as like most developers if you cant reproduce it, then 
its nothing to bother about, after all this time 2 ppl dont like a font or 
whatever, your pissing up the wrong tree if you think I have a care factor 
about changing things when i cant reproduce it. time to move along ... On 
05/12/2014 19:46, Ted Mittelstaedt wrote: The problem is Roundcube. It does not 
insert soft line breaks as per the MIME Quoted-Printable encoding. There's a 
lot of MIME stuff that Roundcube doesn't do very well, it's just not a very 
good web mail interface. I'm always surprised at how vehemently people defend 
it.






Re: ancient perl versions

2014-12-05 Thread jdow

On 2014-12-05 12:32, jdow wrote:

On 2014-12-05 07:56, Reindl Harald wrote:


Am 05.12.2014 um 16:47 schrieb Mike Grau:

On 12/05/2014 09:38 AM, Noel Butler wrote:

pffft

I see no problem, as like most developers if you cant reproduce it, then
its nothing to bother about, after all this time 2 ppl dont like a font
or whatever, your pissing up the wrong tree if you think I have a care
factor about changing things when i cant reproduce it. time to move
along ...


You're reproducing it for me ... e-mails from you have a hard-to-read
small font here also. Not from anyone else - just you


be careful or you end attacked and blacklisted as we still are because i did not
accept the personal attack and "you have no right to ask anybody" while playing
manner cop

http://www.gossamer-threads.com/lists/apache/dev/435100#435100
http://www.gossamer-threads.com/lists/apache/dev/435104
http://www.gossamer-threads.com/lists/apache/dev/435162#435162


Personally I'd blacklist the charming Mr. Ted Mittlestaedt, first. Until
provoked Noel has been quite polite. I do respect that.


s/Mittlestaedt/Mittelstaedt/The spello was unintentional. {o.o}


{o.o}



Re: SOUGHT 2.0

2014-12-05 Thread jdow

On 2014-12-05 08:28, Axb wrote:

On 12/05/2014 05:20 PM, Kris Deugau wrote:

Axb wrote:

On 12/05/2014 01:15 AM, Ian Zimmerman wrote:

On Thu, 04 Dec 2014 22:41:13 +0100,
Axb  wrote:

Axb> To be able to create usable rules, several times/day I need feeds
Axb> to spit *at least* +150k/day. As I don't have the data

150k of what?  Bytes?  Emails?  Tokens?


Sorry, thought this was obvious...

SOUGHT type rule generation extracts txt strings from spams so it means
+150k spams/day


It seems to work reasonably well for me with ~2-3K each ham and spam,
and even provides a handful of subrules even with ~225 spam subtype
messages.  (I generate a number of sets of rules with different subtypes
of spam.)

It's probably not nearly as *effective* as it could be with larger
working sets.


Agreed.

... I use about 5-15k from the last 8 hrs (amount varies dramatically) per rule
gen run *for local* use, but that's hardly representative for global coverage.


Add LKML to your large batch of training email and I bet you get "interesting" 
results, at best.


And one must always remember that one person's spam is another person's ham.

{o.o}


Re: ancient perl versions

2014-12-05 Thread jdow

On 2014-12-05 07:56, Reindl Harald wrote:


Am 05.12.2014 um 16:47 schrieb Mike Grau:

On 12/05/2014 09:38 AM, Noel Butler wrote:

pffft

I see no problem, as like most developers if you cant reproduce it, then
its nothing to bother about, after all this time 2 ppl dont like a font
or whatever, your pissing up the wrong tree if you think I have a care
factor about changing things when i cant reproduce it. time to move
along ...


You're reproducing it for me ... e-mails from you have a hard-to-read
small font here also. Not from anyone else - just you


be careful or you end attacked and blacklisted as we still are because i did not
accept the personal attack and "you have no right to ask anybody" while playing
manner cop

http://www.gossamer-threads.com/lists/apache/dev/435100#435100
http://www.gossamer-threads.com/lists/apache/dev/435104
http://www.gossamer-threads.com/lists/apache/dev/435162#435162


Personally I'd blacklist the charming Mr. Ted Mittlestaedt, first. Until 
provoked Noel has been quite polite. I do respect that.


{o.o}


  1   2   3   4   5   6   7   8   9   10   >