Re: Email filtering theory and the definition of spam

[Groach]

On 12/02/2018 06:54, Rupert Gallagher wrote:
A "standard" "obsoleted" by a "proposed standard" or a "draft 
standard" is nonsense. A standard is obsoleted by a new standard, not 
a draft or a proposal. RFC 821-822 are still the standard, until their 
obsoleting drafts and proposals become the new standard, and 
are clearly identified as such.


Sent from ProtonMail Mobile




As ever, though, whilst technically correct by definition, things are 
not so black and white (humans tend to wander off the binary path that 
logic tends to define and takes a short cut until a new path appears):


https://tools.ietf.org/html/rfc7127#page-2

   Initially it was intended that most IETF technical specifications
   would progress through a series of maturity stages starting with
   Proposed Standard, then progressing to Draft Standard, then finally
   to Internet Standard (seeSection 6 of RFC 2026 
).  For a number of
   reasons this progression is not common.  Many Proposed Standards are
   actually deployed on the Internet and used extensively, as stable
   protocols.  This proves the point that the community often deems it
   unnecessary to upgrade a specification to Internet Standard.  Actual
   practice has been that full progression through the sequence of
   standards levels is typically quite rare, and most popular IETF
   protocols remain at Proposed Standard.



(Not sure why you guys are still discussing RFCs, though, my definition 
of Spam (as in the thread title) is what I choose to define it for my 
business or personal likes - I dont need any RFC telling me what I find 
annoying or unwanted or will be binned/filtered).

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

A "standard" "obsoleted" by a "proposed standard" or a "draft standard" is 
nonsense. A standard is obsoleted by a new standard, not a draft or a proposal. 
RFC 821-822 are still the standard, until their obsoleting drafts and proposals 
become the new standard, and are clearly identified as such.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 23:13, Antony Stone 
 wrote:

> On Sunday 11 February 2018 at 23:04:52, Bill Cole wrote: > On 11 Feb 2018, at 
> 16:20 (-0500), Antony Stone wrote: > > Strange that I can't find SMTP under > 
> > www.rfc-editor.org/rfc/std/std-index.txt > > ‎though, other than STD0060 
> and STD0071, which are both extensions. > > STD10 is SMTP (RFC821), STD11 is 
> message format(RFC822). Ah, thank you. Stupid of me not to search for the 
> expansion of the abbreviation :) However, it's good to see confirmed that 
> STD0010 is "Obsoleted by RFC2821" and that STD0011 is "Obsoleted by RFC2822" 
> (and we already know that those have in turn been subsequently obsoleted), so 
> anyone still using RFC822 as the standard is just not recognising the reality 
> of how RFCs and Internet Standards work Antony. -- This sentence contains 
> exacly three erors. Please reply to the list; please *don't* CC me.

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

You are wrong. Read again.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 22:51, @lbutlr  wrote:

> On 2018-02-11 (11:15 MST), Rupert Gallagher wrote: > > To you, and those like 
> you, who claim better knowledge, read twice yourself, because the actual 
> standard is still rfc 822. This statement is entirely false, irresponsibly 
> so. RFC 822 was obsoleted by RFC 2822 and RFC 2822 was obsoleted by RFC 5322, 
> which is the current standard (along with some updates in 6854). You are 
> wrong. RFC 2822 Obsoleted by: 5322 Updated by: 5335, 5336 Obsoletes: 822 RFC 
> 5322: Updated by: 6854 Obsoletes: 2822 Updates: 4021 Category: Standards 
> Track -- Penny! *Everything* is better with BlueTooth @protonmail.com>

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

You confuse the press with the author.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 19:23, Reindl Harald  wrote:

> Am 11.02.2018 um 19:15 schrieb Rupert Gallagher: > Who is the ignorant here? 
> > > Rfc 822, standard: usa > Rfc 2822, *proposed standard*: usa not USA, IETF 
> https://www.ietf.org/rfc/rfc2822.txt Obsoletes: 822 > Rfc 5321, *draft 
> standard*: usa not USA, IETF https://tools.ietf.org/html/rfc5321 Obsoletes: 
> 2821 Updates: 1123 > Rfc 5322, *draft standard*: usa not USA, IETF 
> https://tools.ietf.org/html/rfc5322 Obsoletes: 2822 Updates: 4021 October 
> 2008 > The list goes on. bad for you because you don't undertand how RFC's 
> work > To you, and those like you, who claim better knowledge, read twice > 
> yourself, because the actual standard is still rfc 822. obsoleted 10 years 
> ago, draft or not you have proven *multiple times* that you even are not 
> capable to understand a specific RFC while violate it and prtend what you say 
> is mandatet by it everything you talk about can be summarized "i do it that 
> way because i can and don't bother about left and right" which disqualifies 
> you to work as mailadmin why in the world do you use protonmail instead your 
> holy domain? because you crap setup likely would block list-mails when that 
> is the case it proves again: you ar enot capable to play admin > On Sun, Feb 
> 11, 2018 at 18:52, @lbutlr > wrote: >> On 2018-02-11 (00:13 MST), Rupert 
> Gallagher wrote: > > Interesting to >> kreme. Not actually interesting to me, 
> no. > We are not in USA, where >> RFC loopholes are written to allow the NSA 
> to send anonymous email >> with spyware, or companies to profit from massmail 
> marketing. Spam >> assassins we are for real. RFC's have nothing to do with 
> the USA, and >> are written by (and contributed to by) anyone with expertise 
> who cares >> to work on them. Your delusions about them are concerning as 
> they >> expose deep faults in your knowledge. Any mail admin who thinks s/he 
> >> can ignore RFC because "they're Americans" is likely going to cause >> 
> problems, not just for themselves and their unfortunate users, but for >> 
> other servers as well. -- "I don't care if Bill Gates is the world's >> 
> biggest philanthropist. The pain he has inflicted on the world in the >> past 
> 20 years through lousy products easily outweighs any good he has >> done 
> Apple is as arrogant as Microsoft but at least its stuff >> works as 
> advertised" - Graem Philipson @kreme.com> @kreme.com>

Re: smtp.centurylink.net 206.152.134.66

[Rob McEwen]

On 2/11/2018 2:37 PM, David Jones wrote:
This mail server has legit email for centurylink.net and 
embarqmail.com plus a lot of other spam coming out of it.
It's listed on a number of RBLs making this very hard to allow ham 
through and block spam.

http://multirbl.valli.org/lookup/206.152.134.66.html

https://pastebin.com/YidWCqp8


I've downgraded the whitelisting entry for this IP at invaluement. It 
still won't get blacklisted due to the large amount of collateral damage 
that such a listing would cause. (And others lists having this 
blacklisted is probably a GOOD thing! I'm not disputing their decision 
for their list. Different lists serve different purposes, etc.) But with 
this downgrade at invaluement, future spam that comes from this IP will  
be examined with greater scrutiny by invaluement, in order to possibly 
blacklist other domains and IPs related to the spam.


Also, the spam sample shows a Google shortner being used as the payload 
link. I've seen many of those lately - and I think Google needs to work 
on improving their ability to prevent these, or at least get the 
shortner terminated faster. At the moment, this one is still "live". I 
reported this particular one as spam to their shortner abuse form. So, 
it will be interesting to see how long it persists from this point forward?


btw - if anyone ever wants to learn more about one of these google 
shortners without actually visiting the link (which can be dangerous... 
for example, some of the more malicious links arrive at a page that 
tries to install a virus), add ".info" to the end of the google shortner 
URL and you can then see more info about the shortner, including its 
intended destination. For example, for this one:


https://goo.gl/s7XxhD.info

--
Rob McEwen
https://www.invaluement.com

Re: smtp.centurylink.net 206.152.134.66

[Charles Sprickman]

> On Feb 11, 2018, at 7:13 PM, David Jones  wrote:
> 
> On 02/11/2018 03:56 PM, @lbutlr wrote:
>> On 2018-02-11 (12:37 MST), David Jones  wrote:
>>> 
>>> Anyone on this list that knows the mail admins/contacts for centurylink.net 
>>> and embarqmail.com?  This mail server has legit email for centurylink.net 
>>> and embarqmail.com plus a lot of other spam coming out of it.
>> As a customer of CenturyLink (we have symmetric Gigabit through them) I can 
>> say that their support personal are less than worthless.
>> They still have a very "Bell telephone" attitude where everything they do is 
>> automatically correct because they are the telephone company, so any problem 
>> issue, or misconfiguration is someone else's fault.
>> Whatever solutions you need, you'll have to manage them on your own and do 
>> your best to work around their incompetence.
> 
> Centurylink recently purchased Level 3 which has/had excellent support. 
> Hopefully Level 3 tech support wasn't laid off to keep the status quo.

The bellheads always win in these acquisitions. :(

> -- 
> David Jones

Re: smtp.centurylink.net 206.152.134.66

[David Jones]

On 02/11/2018 03:56 PM, @lbutlr wrote:

On 2018-02-11 (12:37 MST), David Jones  wrote:


Anyone on this list that knows the mail admins/contacts for centurylink.net and 
embarqmail.com?  This mail server has legit email for centurylink.net and 
embarqmail.com plus a lot of other spam coming out of it.



As a customer of CenturyLink (we have symmetric Gigabit through them) I can say 
that their support personal are less than worthless.

They still have a very "Bell telephone" attitude where everything they do is 
automatically correct because they are the telephone company, so any problem issue, or 
misconfiguration is someone else's fault.

Whatever solutions you need, you'll have to manage them on your own and do your 
best to work around their incompetence.



Centurylink recently purchased Level 3 which has/had excellent support. 
Hopefully Level 3 tech support wasn't laid off to keep the status quo.


--
David Jones

Re: Email filtering theory and the definition of spam

[Antony Stone]

On Sunday 11 February 2018 at 23:04:52, Bill Cole wrote:

> On 11 Feb 2018, at 16:20 (-0500), Antony Stone wrote:
> > Strange that I can't find SMTP under
> > www.rfc-editor.org/rfc/std/std-index.txt
> > ‎though, other than STD0060 and STD0071, which are both extensions.
> 
> STD10 is SMTP (RFC821), STD11 is message format(RFC822).

Ah, thank you.  Stupid of me not to search for the expansion of the 
abbreviation :)

However, it's good to see confirmed that STD0010 is "Obsoleted by RFC2821" and 
that STD0011 is "Obsoleted by RFC2822" (and we already know that those have in 
turn been subsequently obsoleted), so anyone still using RFC822 as the 
standard is just not recognising the reality of how RFCs and Internet 
Standards work


Antony.

-- 
This sentence contains exacly three erors.

   Please reply to the list;
 please *don't* CC me.

Re: Email filtering theory and the definition of spam

[Bill Cole]

On 11 Feb 2018, at 16:20 (-0500), Antony Stone wrote:

Strange that I can't find SMTP under 
www.rfc-editor.org/rfc/std/std-index.txt

‎though, other than STD0060 and STD0071, which are both extensions.


STD10 is SMTP (RFC821), STD11 is message format(RFC822).


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: smtp.centurylink.net 206.152.134.66

[@lbutlr]

On 2018-02-11 (12:37 MST), David Jones  wrote:
> 
> Anyone on this list that knows the mail admins/contacts for centurylink.net 
> and embarqmail.com?  This mail server has legit email for centurylink.net and 
> embarqmail.com plus a lot of other spam coming out of it.


As a customer of CenturyLink (we have symmetric Gigabit through them) I can say 
that their support personal are less than worthless.

They still have a very "Bell telephone" attitude where everything they do is 
automatically correct because they are the telephone company, so any problem 
issue, or misconfiguration is someone else's fault.

Whatever solutions you need, you'll have to manage them on your own and do your 
best to work around their incompetence.

-- 
'Today Is A Good Day For Someone Else To Die!' --Feet of Clay

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Bill Cole]

On 11 Feb 2018, at 9:54 (-0500), Benny Pedersen wrote:

first query would be valid for 300 secs, but that is imho still not 
free, problem is that keeping low ttls does not change how dns works, 
any auth dns servers will upate on soa serial anyway, the crime comes 
in when sa using remote dns servers that ignore soa serial updates


in that case ttls would keep spammers listed for 300 secs only


That's not how DNS TTLs work.

When a record's TTL elapses in the local name cache, it is dropped. The 
next query for that name and record type causes the resolver to make 
another query to the authoritative nameservers, which will return the 
same record whose TTL expired unless it has been removed from the zone. 
No standards-conforming DNS resolver returns NXDOMAIN based on the lack 
of a non-expired record in its cache and an unchanged SOA serial above 
the name. That would make no sense at all and require many more SOA 
queries than actually happen.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Email filtering theory and the definition of spam

[@lbutlr]

On 2018-02-11 (11:15 MST), Rupert Gallagher  wrote:
> 
> To you, and those like you, who claim better knowledge, read twice yourself, 
> because the actual standard is still rfc 822.  

This statement is entirely false, irresponsibly so. RFC 822 was obsoleted by 
RFC 2822 and RFC 2822 was obsoleted by RFC 5322, which is the current standard 
(along with some updates in 6854). You are wrong.

RFC 2822
Obsoleted by: 5322 Updated by: 5335, 5336
Obsoletes: 822


RFC 5322:
Updated by: 6854 
Obsoletes: 2822
Updates: 
4021

Category: Standards Track

-- 
Penny! *Everything* is better with BlueTooth

Re: smtp.centurylink.net 206.152.134.66

[Chris]

On Sun, 2018-02-11 at 13:37 -0600, David Jones wrote:
> Anyone on this list that knows the mail admins/contacts for 
> centurylink.net and embarqmail.com?  This mail server has legit
> email 
> for centurylink.net and embarqmail.com plus a lot of other spam
> coming 
> out of it.
> 
David, as you can see I use embarqmail (centurylink as my ISP). I got
this email address off of DSLreports.com - talkt...@centurylink.com as
the name of the CenturyLink tech who posts there so you might give them
a try. I've found that their Tech Support is pretty lame especially
when it comes to problems I've had before in regards to anything
dealing with Linux or mailer issues. They're also on Twitter
- @CenturyLinkHelp and I've sent them DMs before and pretty much get a
quick reply however they've never been helpful except to shake their
virtual heads and tell me to go into chat (which was useless also) or
call. You might try them though. 

Sorry I couldn't be of more help.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
15:31:38 up 9 days, 23:04, 1 user, load average: 0.94, 0.83, 0.74
Description:Ubuntu 16.04.3 LTS, kernel 4.13.0-32-generic


signature.asc
Description: This is a digitally signed message part

Re: Email filtering theory and the definition of spam

[Antony Stone]

On Sunday 11 February 2018 at 19:15:59, Rupert Gallagher wrote:

> Who is the ignorant here?
> 
> Rfc 822, standard: usa

https://tools.ietf.org/html/rfc822 "Obsoleted by: 2822"

What do you mean by "Standard: USA"?  I know what an IETF Standard is, and 
it's quite different from an RFC, which we were discussing.  What does "USA" 
mean in the context you used it above?

Strange that I can't find SMTP under www.rfc-editor.org/rfc/std/std-index.txt
‎though, other than STD0060 and STD0071, which are both extensions.

> Rfc 2822, *proposed standard*: usa

https://tools.ietf.org/html/rfc2822 "Obsoleted by: 5322"

> Rfc 5321, *draft standard*: usa

https://tools.ietf.org/html/rfc5321 "Updated by: 7504"

> Rfc 5322, *draft standard*: usa

https://tools.ietf.org/html/rfc5322 "Updated by: 6854"

> ...
> 
> The list goes on.

It does indeed, because RFCs get revised, modified, updated, replaced and 
obsoleted.

> To you, and those like you, who claim better knowledge, read twice
> yourself, because the actual standard is still rfc 822.

Use it if you want, but don't expect the rest of the Internet to be compatible 
with you.  It's not the way things work.


Antony.

-- 
I love deadlines.   I love the whooshing noise they make as they go by.

 - Douglas Noel Adams

   Please reply to the list;
 please *don't* CC me.

Re: sa-learn

[RW]

On Sun, 11 Feb 2018 19:09:32 +0100
Hendrik Haddorp wrote:

> Hi,
> 
> I have a maildir with about 2 mails. In the past this does not
> seem to have been a problem. But since a few weeks my sa-learn
> process dies with an OOM now. My server has only 1GB of memory with
> another GB for swap. sa-learn is eating up pretty much the complete
> memory for the run and is only able to finish when I stop everything
> else. Why is sa-learn using more and more memory even when it learned
> all those messages already in the past? 

I don't know, it sounds like a bug.

This is a bit of a long shot, but try tuning-off autoexpiry if you are
using it. 

smtp.centurylink.net 206.152.134.66

[David Jones]

Anyone on this list that knows the mail admins/contacts for 
centurylink.net and embarqmail.com?  This mail server has legit email 
for centurylink.net and embarqmail.com plus a lot of other spam coming 
out of it.


It's listed on a number of RBLs making this very hard to allow ham 
through and block spam.


http://multirbl.valli.org/lookup/206.152.134.66.html

The PTR and A records for this IP are mail.onyx.syn-alias.com which is 
also a bit odd since the SMTP HELO is smtp.centurylink.net.  These don't 
have to match but it's best if they did to help prove ownership and 
trustworthiness.


https://pastebin.com/YidWCqp8

I have had a customer of ours request whitelisting of centurylink.net 
and embarqmail.com email based on this problem and it's causing 
problems.  It can't be whitelisted due to a lot of junk coming from it 
so I had to make some custom local rules to do this.


It would be best if the centurylink.net and embarqmail.com mail didn't 
egress onto the Internet from an IP that was listed on so many RBLs.


SOLUTION: Setup a new mail relay with FCrDNS and the SMTP HELO matching 
and get SPF and DKIM working properly for centurylink.net and 
embarqmail.com so the rest of the Internet can properly filter/allow 
this email.


--
David Jones

Re: sa-learn

[Hendrik Haddorp]

thanks, I'll give that a try

On 11.02.2018 20:15, Reindl Harald wrote:



Am 11.02.2018 um 20:10 schrieb Hendrik Haddorp:
so far I was always letting it run once a week over my inbox in --ham 
mode and over my spam folder in --spam mode. all tutorials I saw did 
it the same way. this also worked for years but likely with less mail 
files. I was under the impression that sa-learn would skip messages 
that it already learned. the debug log also indicated that it 
recognized those.


but to recognize it needs to read them

man find
man xargs

find "$SA_MILTER_HOME/training/spam/" -type f -mtime -$TRAIN_DAYS | 
xargs -r sa-learn --max-size=0 --no-sync --spam
find "$SA_MILTER_HOME/training/ham/" -type f -mtime -$TRAIN_DAYS | 
xargs -r sa-learn --max-size=0 --no-sync --ham



On 11.02.2018 19:44, Matus UHLAR - fantomas wrote:

On 11.02.18 19:09, Hendrik Haddorp wrote:
I have a maildir with about 2 mails. In the past this does not 
seem to have been a problem. But since a few weeks my sa-learn 
process dies with an OOM now.


do you run sa-learn over whole maildir all the time?
why?

My server has only 1GB of memory with another GB for swap. sa-learn 
is eating up pretty much the complete memory for the run and is 
only able to finish when I stop everything else. Why is sa-learn 
using more and more memory even when it learned all those messages 
already in the past? Is there a way to limit the memory usage 
except from making the set of messages smaller?


you are not supposed to repeatedly call sa-learn over huge maildir.

calling over new mail (or, better, false-positives and 
false-negatives) is

faster and won't eat all your memory

Re: sa-learn

[Hendrik Haddorp]

so far I was always letting it run once a week over my inbox in --ham 
mode and over my spam folder in --spam mode. all tutorials I saw did it 
the same way. this also worked for years but likely with less mail 
files. I was under the impression that sa-learn would skip messages that 
it already learned. the debug log also indicated that it recognized those.


On 11.02.2018 19:44, Matus UHLAR - fantomas wrote:

On 11.02.18 19:09, Hendrik Haddorp wrote:
I have a maildir with about 2 mails. In the past this does not 
seem to have been a problem. But since a few weeks my sa-learn 
process dies with an OOM now.


do you run sa-learn over whole maildir all the time?
why?

My server has only 1GB of memory with another GB for swap. sa-learn 
is eating up pretty much the complete memory for the run and is only 
able to finish when I stop everything else. Why is sa-learn using 
more and more memory even when it learned all those messages already 
in the past? Is there a way to limit the memory usage except from 
making the set of messages smaller?


you are not supposed to repeatedly call sa-learn over huge maildir.

calling over new mail (or, better, false-positives and 
false-negatives) is

faster and won't eat all your memory.

Re: sa-learn

[Matus UHLAR - fantomas]

On 11.02.18 19:09, Hendrik Haddorp wrote:
I have a maildir with about 2 mails. In the past this does not 
seem to have been a problem. But since a few weeks my sa-learn 
process dies with an OOM now.


do you run sa-learn over whole maildir all the time?
why?

My server has only 1GB of memory with 
another GB for swap. sa-learn is eating up pretty much the complete 
memory for the run and is only able to finish when I stop everything 
else. Why is sa-learn using more and more memory even when it learned 
all those messages already in the past? Is there a way to limit the 
memory usage except from making the set of messages smaller?


you are not supposed to repeatedly call sa-learn over huge maildir.

calling over new mail (or, better, false-positives and false-negatives) is
faster and won't eat all your memory.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
We are but packets in the Internet of life (userfriendly.org)

Re: sa-learn

[Hendrik Haddorp]

it's a small hosted VM running fine for years.

On 11.02.2018 19:35, Reindl Harald wrote:



Am 11.02.2018 um 19:09 schrieb Hendrik Haddorp:
I have a maildir with about 2 mails. In the past this does not 
seem to have been a problem. But since a few weeks my sa-learn 
process dies with an OOM now. My server has only 1GB of memory with 
another GB for swap. sa-learn is eating up pretty much the complete 
memory for the run and is only able to finish when I stop everything 
else. Why is sa-learn using more and more memory even when it learned 
all those messages already in the past? Is there a way to limit the 
memory usage except from making the set of messages smaller?


from where did you get a machine with 1 GB in the last decade?
below 1.5 GB i don't even deploy a golden-master VM

My problem sounds somewhat like 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5141
probably - but my coropus is 150 mails large, two bayes 
(sa-builtin and bogofilter) with 425 MB living in tmpfs and so in 
memory rsyned at boot/shutdown to a persistent location


clamav needs some hundret MB
dns-cache needs some memory

sorry, but 1 GB is not suitebale in 2018

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

Who is the ignorant here?

Rfc 822, standard: usa
Rfc 2822, *proposed standard*: usa
Rfc 5321, *draft standard*: usa
Rfc 5322, *draft standard*: usa
...

The list goes on.

To you, and those like you, who claim better knowledge, read twice yourself, 
because the actual standard is still rfc 822.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 18:52, @lbutlr  wrote:

> On 2018-02-11 (00:13 MST), Rupert Gallagher wrote: > > Interesting to kreme. 
> Not actually interesting to me, no. > We are not in USA, where RFC loopholes 
> are written to allow the NSA to send anonymous email with spyware, or 
> companies to profit from massmail marketing. Spam assassins we are for real. 
> RFC's have nothing to do with the USA, and are written by (and contributed to 
> by) anyone with expertise who cares to work on them. Your delusions about 
> them are concerning as they expose deep faults in your knowledge. Any mail 
> admin who thinks s/he can ignore RFC because "they're Americans" is likely 
> going to cause problems, not just for themselves and their unfortunate users, 
> but for other servers as well. -- "I don't care if Bill Gates is the world's 
> biggest philanthropist. The pain he has inflicted on the world in the past 20 
> years through lousy products easily outweighs any good he has done Apple 
> is as arrogant as Microsoft but at least its stuff works as advertised" - 
> Graem Philipson @protonmail.com>

sa-learn

[Hendrik Haddorp]

Hi,

I have a maildir with about 2 mails. In the past this does not seem 
to have been a problem. But since a few weeks my sa-learn process dies 
with an OOM now. My server has only 1GB of memory with another GB for 
swap. sa-learn is eating up pretty much the complete memory for the run 
and is only able to finish when I stop everything else. Why is sa-learn 
using more and more memory even when it learned all those messages 
already in the past? Is there a way to limit the memory usage except 
from making the set of messages smaller?
My problem sounds somewhat like 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5141


regards,
Hendrik

Re: Email filtering theory and the definition of spam

[@lbutlr]

On 2018-02-11 (00:13 MST), Rupert Gallagher  wrote:
> 
> Interesting to kreme. 

Not actually interesting to me, no.

> We are not in USA, where RFC loopholes are written to allow the NSA to send 
> anonymous email with spyware, or companies to profit from massmail marketing. 
> Spam assassins we are for real.

RFC's have nothing to do with the USA, and are written by (and contributed to 
by) anyone with expertise who cares to work on them. Your delusions about them 
are concerning as they expose deep faults in your knowledge.

Any mail admin who thinks s/he can ignore RFC because "they're Americans" is 
likely going to cause problems, not just for themselves and their unfortunate 
users, but for other servers as well.

-- 
"I don't care if Bill Gates is the world's biggest philanthropist. The
pain he has inflicted on the world in the past 20 years through lousy
products easily outweighs any good he has done Apple is as arrogant
as Microsoft but at least its stuff works as advertised" - Graem Philipson

Re: bug 7549 and 7550

[Kevin A. McGrail]

On 2/11/2018 12:04 PM, David Jones wrote:

On 02/11/2018 10:12 AM, Benny Pedersen wrote:
i would like to see them in corpus score testing, hope some with cla 
will add it for testing


I would be glad to if I knew how.  Is this a sandbox rule?  Do I 
simply follow this? https://wiki.apache.org/spamassassin/RuleSandboxes


That is a great start. Create a sandbox directory for you, name the 
rules starting with T_ and reference the bug #'s.


Regards,

KAM

Re: bug 7549 and 7550

[David Jones]

On 02/11/2018 10:12 AM, Benny Pedersen wrote:
i would like to see them in corpus score testing, hope some with cla 
will add it for testing


I would be glad to if I knew how.  Is this a sandbox rule?  Do I simply 
follow this?  https://wiki.apache.org/spamassassin/RuleSandboxes


--
David Jones

bug 7549 and 7550

[Benny Pedersen]

i would like to see them in corpus score testing, hope some with cla 
will add it for testing

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Benny Pedersen]

Dave Warren skrev den 2018-02-06 20:39:


How low are the TTLs? I'm seeing 300 seconds on 127.0.0.2 which is
more than sufficient time for a single message to finish processing,
such that multiple queries from one message would absolutely be cached
(or more likely, the first would still be pending and the second would
get the same answer as the first).


first query would be valid for 300 secs, but that is imho still not 
free, problem is that keeping low ttls does not change how dns works, 
any auth dns servers will upate on soa serial anyway, the crime comes in 
when sa using remote dns servers that ignore soa serial updates


in that case ttls would keep spammers listed for 300 secs only

and thats why i say 300 secs helps spammers


;; ANSWER SECTION:
2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2

Maybe the TTLs are different for other records?


300 is imho to low to anything thats called free

i would like to accept free if it was 3600


I am also noticing very intermittent response times, sometimes taking
over a second to get a response, other times taking under 50ms.


rndc querylog is my friend

i just like to start a debate on why 300 is accepted as free, it does 
matter for non datafeeds users, but for datafeeds it does not matter at 
all

Re: Email filtering theory and the definition of spam

[Antony Stone]

On Sunday 11 February 2018 at 08:35:42, Rupert Gallagher wrote:

> We are not in USA, where RFC loopholes are written

Er, RFCs are written by IETF Working Groups, which are open to *anyone* to 
contribute to, have members from many different countries and companies around 
the world, and are not run by any government organisation.

RFCs are not a product of America, whether you are paranoid about American 
products or not.


Antony.

-- 
Tinned food was developed for the British Navy in 1813.

The tin opener was not invented until 1858.

   Please reply to the list;
 please *don't* CC me.