Re: List of legit mass mailers

[Ruga]

Spamassassin is a perl regex parser for e-mails. Nothing more. Most of our 
filtering happens way before SA enters the stage. When SA gets the chance, our 
custom SA rules serve as proactive forensic evidence of a spammer's new trick. 
We do not give shit if SA is funded by advertisers. SA's own rules are useless, 
so much that we no longer waste bandwidth to download them. You could stop 
distributing your rules, and we would not even notice. So t hat's who we are 
and what you do.



Store X is not a mass mailer if it has your consent for the occasional or 
periodic advert on products that you have an interest on. Store X is also wise 
enough to send their own mail from their own well configured server.

Mass mailers hit you without your consent, and they do their very best to hide 
their tracks.

Sent from ProtonMail Mobile



On Wed, Mar 8, 2017 at 3:32 PM, Kevin A. McGrail <kmcgr...@pccc.com> wrote:
On 3/8/2017 9:23 AM, Ruga wrote:
> This is spamassassin...
> We are against mass mailers.
No, we're not and you don't speak for the project. Please do not do so.

In fact, I don't speak for the project but as a long-time project
contributor and chair emeritus, I have ALWAYS used the definition that
spam is about conSent not conTent. I believe it was Chris Santerre that
gave that concept years ago and I've extrapolated on it over the years
especially for clarity on mass mailers and capitalism.

The key point is if you consented to receive it, it is not spam. I
don't care if the content is the spammiest looking content in existence
today, that's a FP if it is blocked.

Legit mass marketers sending clear emails that have been conSented to
receive those messages are welcome and should be supported to the demise
of the illegitimate players.

Going further, as a capitalist, I have always extended concepts of
conSent to include:
- Requiring clear opt-in/opt-out checkboxes
- Requiring simply and quick unsubscribe mechanisms
- Implied consent for transactional information. I.e. I buy something
from Macy's, Macy's can email me the 1-time receipt. Follow-up surveys,
coupons, etc. would require clear conSent noting that while I do not
like it, consent boxes that are checked ON by default are not a reason
to block.

My $0.02,
KAM

Re: List of legit mass mailers

[Ruga]

This is spamassassin...
We are against mass mailers.

Sent from ProtonMail Mobile


On Mon, Mar 6, 2017 at 7:22 PM, Marc Perkel <'supp...@junkemailfilter.com'> 
wrote:
Just wondering if anyone has - or in interested in - a list of legit
mass mailing sources?

There are many domains that remail/deliver for other domains that are
95%+ good email. And they are not perfect and sometimes they get scammed
but are mostly good.

Just wondering if anyone has a list - or is interested in me producing
such a list?

--
Marc Perkel - Sales/Support
supp...@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400

Re: do we still need moderators here ?

[Ruga]

+1 :-(


On Tue, Feb 14, 2017 at 4:35 PM, Benny Pedersen <'m...@junc.eu'> wrote:
:(

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

RFC-822 is the e-mail standard, without "group addresses". What we do complies 
with the standard.

Sent from ProtonMail Mobile


On Thu, Feb 9, 2017 at 2:19 PM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Thu, 09 Feb 2017 03:44:24 -0500
Ruga <r...@protonmail.com> wrote:

> Proper snail mail and e-mail have addresses. Those who do not, are
> quickly archived in the trashcan. This is what we do, and it works.

We get it.

I'm overcome with delight that you are implementing the mail policy
that you like. It warms my heart... you have no idea.

But please don't claim you're doing it in the name of RFC compliance.

Regards,

Dianne.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Remind me to tell you when I use the iPhone.



On Thu, Feb 9, 2017 at 1:13 PM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On February 9, 2017 3:41:32 AM EST, Ruga <r...@protonmail.com> wrote:

>Let see who can read amon us.

You spelled "among" incorrectly.

>What is your highest level of formal education?

Um? None of your business?

Master's degree, if you must know.

-- Dianne

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Speaking of personal attacks against me, how old are you?


On Thu, Feb 9, 2017 at 10:13 AM, Reindl Harald <'h.rei...@thelounge.net'> wrote:


Am 09.02.2017 um 09:28 schrieb Ruga:
>> A large class of wanted email comes with the "undisclosed recipients" 
>> header. A large class of wanted email comes from domains that lack SPF.
>
> Our security policy demands rejection of both types. They do not hit SA.
> They are denied as soon as their strings are received. The IP of
> repeated offenders is then dropped by firewall.


your childish posts are funny but slowly becoming annoying

you live in your own small world where you can do what you want if the
people which are owning the mailbox suck it - but don't pretend that
this works in the real world out there if you want to be taken serious

> On Thu, Feb 9, 2017 at 12:55 AM, Joe Quinn
> <'headprogrammingc...@gmail.com'> wrote:
>> On 2/8/2017 1:36 PM, Philip Prindeville wrote:
>>> Having been through the process of authoring 2 RFC’s, perhaps I can shed 
>>> some light on the process for you.
>>>
>>> All proposed standards started life as draft RFC’s (this was before the 
>>> days of IDEA’s but after the days of IEN’s).
>>>
>>> If it were validated by the working group and passed up to the IAB and they 
>>> concurred (they usually deferred to the WG except on editorial matters), 
>>> then the proposed draft was issued officially as an RFC and given a number.
>>>
>>> Later, after it accepted wide enough adoption in the Internet community, an 
>>> existing RFC might be promoted to "standard" from "experimental", etc.
>>>
>>> Occasionally, if a WG (working group) did enough reference implementations 
>>> and proved them at one or more interoperability meetings (the so-called 
>>> "bake-offs"), then the WG could petition for immediate labeling as a 
>>> "standard" when the RFC was approved by the IAB.
>>>
>>> It’s even possible for a standard (like RFC-1035) to have both "standard" 
>>> parts (like A RR’s) and "experimental" parts (like MB RR’s).
>>>
>>>
>>>> On Feb 8, 2017, at 7:04 AM, Ruga <r...@protonmail.com> wrote:
>>>>
>>>> Read the headers of RFCs; some o them are explicitly labeled as standard. 
>>>> Most of them are request for comments.
>>>>
>>>>
>>>> On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'kmcgr...@pccc.com'> 
>>>> wrote:
>>>>> On 2/8/2017 8:52 AM, Ruga wrote:
>>>>>> Not all RFCs are standards.
>>>>>> Educate yourself.
>>>>> The personal attacks aren't necessary. These RFCs are the basis for
>>>>> effectively 100% of the email on the planet for decades. If that's not
>>>>> a standard, what is?
>>
>> This bears some emphasis, actually. Going from experimental to
>> standard comes /after/ the implementations are used in practice and
>> proven to be useful. Beyond that, SA is not a standards checker or an
>> RFC checker or an IEEE checker. All it does is classify email as
>> wanted or not wanted. A large class of wanted email comes with the
>> "undisclosed recipients" header. A large class of wanted email comes
>> from domains that lack SPF. A smaller class of wanted email comes from
>> the actual manufacturer of Viagra. Some mail servers disregard some
>> standards entirely. You just have to deal with it.
>>
>> As Dianne points out, the "undisclosed recipients" to header is valid
>> under RFC822, which has been itself expanded on in multiple subsequent
>> RFCs. As multiple other people here have mentioned, the "undisclosed
>> recipients" to header is used in wanted email. I am right now two
>> clicks away from adding it to this email with my mail client. It is an
>> implementation detail of BCC, and unambiguously is not spam indicator
>> on its own.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Proper snail mail and e-mail have addresses. Those who do not, are quickly 
archived in the trashcan. This is what we do, and it works.


On Wed, Feb 8, 2017 at 3:13 PM, David Jones <'djo...@ena.com'> wrote:

>From: Ruga <r...@protonmail.com>
>Sent: Wednesday, February 8, 2017 8:01 AM

>How odd, in a mailing list of spam fighters someone really
>wants me to accept junk mail.

>In the snail mail box, we put in the trashcan everything that
>does not carry a recipient address. Guess what? We do the
>same with e-mail. And we are happy about it.

Snail mail doesn't support the concept of BCC and email
does. BCC'ing is legit and it's tough to block spam that is
sent this way but it's doable, just not based on the To:
header.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

> You really don't know how to read, do you?

Now this is a personal attack from you.

Let see who can read amon us.
What is your highest level of formal education?



On Wed, Feb 8, 2017 at 3:24 PM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Wed, 08 Feb 2017 09:01:35 -0500
Ruga <r...@protonmail.com> wrote:

> How odd, in a mailing list of spam fighters someone really wants me
> to accept junk mail.

Wow. You really don't know how to read, do you? What was unclear
about my statement:

Hey, you do you. You can do whatever you want with your mail, but
claiming it's in the name of RFC compliance is alternatively factual.

> In the snail mail box, we put in the trashcan everything that does
> not carry a recipient address. Guess what? We do the same with
> e-mail. And we are happy about it.

You can do whatever you want. But don't spread misinformation about
standards. We have to deal with enough crappy noncompliant software.
We don't need Internet vigilantes on a witch-hunt against software
that actually *does* comply with standards.

Regards,

Dianne.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Stop that. I did not attack anyone.


On Wed, Feb 8, 2017 at 4:30 PM, Kevin A. McGrail <'kmcgr...@pccc.com'> wrote:
On 2/8/2017 9:04 AM, Ruga wrote:
> Read the headers of RFCs; some o them are explicitly labeled as
> standard. Most of them are request for comments.
I'm well aware of the standards and don't appreciate being told to read
them. That's a personal attack and you are also attacking others who
are some of the best email people I've ever met.

Standards evolve organically and there is just "how it's done" as well
as the RFCs.

If these people are telling you it's "standard", don't start arguing the
definition of "standard". Take it on face value that you should do it
or risk losing important email.

To attack them and say they are forcing you to accept spam is nothing
but an argument fallacy because everyone is here to stop bastard spammers.

Regards,
KAM

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

> A large class of wanted email comes with the "undisclosed recipients" header. 
> A large class of wanted email comes from domains that lack SPF.

Our security policy demands rejection of both types. They do not hit SA. They 
are denied as soon as their strings are received. The IP of repeated offenders 
is then dropped by firewall.


On Thu, Feb 9, 2017 at 12:55 AM, Joe Quinn <'headprogrammingc...@gmail.com'> 
wrote:

On 2/8/2017 1:36 PM, Philip Prindeville wrote:
Having been through the process of authoring 2 RFC’s, perhaps I can shed some 
light on the process for you. All proposed standards started life as draft 
RFC’s (this was before the days of IDEA’s but after the days of IEN’s). If it 
were validated by the working group and passed up to the IAB and they concurred 
(they usually deferred to the WG except on editorial matters), then the 
proposed draft was issued officially as an RFC and given a number. Later, after 
it accepted wide enough adoption in the Internet community, an existing RFC 
might be promoted to "standard" from "experimental", etc. Occasionally, if a WG 
(working group) did enough reference implementations and proved them at one or 
more interoperability meetings (the so-called "bake-offs"), then the WG could 
petition for immediate labeling as a "standard" when the RFC was approved by 
the IAB. It’s even possible for a standard (like RFC-1035) to have both 
"standard" parts (like A RR’s) and "experimental" parts (like MB RR’s).   On 
Feb 8, 2017, at 7:04 AM, Ruga 
[<r...@protonmail.com>](mailto:r...@protonmail.com) wrote: Read the headers of 
RFCs; some o them are explicitly labeled as standard. Most of them are request 
for comments. On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail 
[<'kmcgr...@pccc.com'>](mailto:'kmcgr...@pccc.com') wrote:   On 2/8/2017 8:52 
AM, Ruga wrote:   Not all RFCs are standards. Educate yourself.   The personal 
attacks aren't necessary. These RFCs are the basis for effectively 100% of the 
email on the planet for decades. If that's not a standard, what is?
This bears some emphasis, actually. Going from experimental to standard comes 
after the implementations are used in practice and proven to be useful. Beyond 
that, SA is not a standards checker or an RFC checker or an IEEE checker. All 
it does is classify email as wanted or not wanted. A large class of wanted 
email comes with the "undisclosed recipients" header. A large class of wanted 
email comes from domains that lack SPF. A smaller class of wanted email comes 
from the actual manufacturer of Viagra. Some mail servers disregard some 
standards entirely. You just have to deal with it.

As Dianne points out, the "undisclosed recipients" to header is valid under 
RFC822, which has been itself expanded on in multiple subsequent RFCs. As 
multiple other people here have mentioned, the "undisclosed recipients" to 
header is used in wanted email. I am right now two clicks away from adding it 
to this email with my mail client. It is an implementation detail of BCC, and 
unambiguously is not spam indicator on its own.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Read the headers of RFCs; some o them are explicitly labeled as standard. Most 
of them are request for comments.


On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'kmcgr...@pccc.com'> wrote:
On 2/8/2017 8:52 AM, Ruga wrote:
> Not all RFCs are standards.
> Educate yourself.
The personal attacks aren't necessary. These RFCs are the basis for
effectively 100% of the email on the planet for decades. If that's not
a standard, what is?

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

How odd, in a mailing list of spam fighters someone really wants me to accept 
junk mail.

In the snail mail box, we put in the trashcan everything that does not carry a 
recipient address. Guess what? We do the same with e-mail. And we are happy 
about it.



On Wed, Feb 8, 2017 at 2:43 PM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Tue, 07 Feb 2017 18:33:49 -0500
Ruga <r...@protonmail.com> wrote:

> I follow the actual RFC standard, not the proposed revisions.

No you don't. You follow your misunderstanding of the actual standard.
RFC822 permits group syntax. It's right in the ABNF. Learn to read
carefully.

Here's a hint, taken directly from https://www.ietf.org/rfc/rfc0822.txt

address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"

> The To From and Cc fields are defined by a grammar AND a natural
> language description. Such fields MUST hold addresses,

Wrong.

> Bear in mind the state of corruption we live in.

I know. It's awful that would-be pedants don't even read properly.

> On the subject length, although the RFC standard did not foresee the
> abuse, it did speak about the intended purpose of the field. If it
> does not fit the one line of 78 (ASCII) characters, it bounches back
> to the sender.

Well, you know, for someone who only follows STANDARDS, you're making stuff
up. There's no mention whatsoever of line length limits in the STANDARD
RFC 822. Those are only in the proposed revisions, which you disdain.
Or are you selective about picking and choosing from proposed revisions?

Oh and by the way, I certainly hope your mail server does not speak
ESMTP. That's not a standard, you know.

> I understand that sloppy e-mail software allows
> spammers to send the library of congress inside a subject field, but
> rest assured that I such abuses do not survive my filters, even if
> Trump himself will allow for it with a presidential decree.

Hey, you do you. You can do whatever you want with your mail, but claiming
it's in the name of RFC compliance is alternatively factual.

Regards,

Dianne.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

Not all RFCs are standards.
Educate yourself.

Sent from ProtonMail Mobile


On Wed, Feb 8, 2017 at 1:38 PM, Matus UHLAR - fantomas <'uh...@fantomas.sk'> 
wrote:
On 07.02.17 18:33, Ruga wrote:
>I follow the actual RFC standard, not the proposed revisions.

what are you talking about?
822, 2822 and 5322 all define group address form as allowed.

> If the sender hides the recipients, why should I care delivering its junk
> to my valued accounts?

you can create a rule for yourself that will score those headers.
However others will probably not use it, since it's quite common for some
companies to send mass mail to addresses not known to recipients
(so they won't abuse those addresses).


>Bear in mind the state of corruption we live in. Spam is also a business,
> and the RFC proposed revisions are adapting to such business, to allow for
> it instead of impeding it.

so why don't you follow those proposed revisions as you have stated above?

>On the subject length, although the RFC standard did not foresee the abuse,
> it did speak about the intended purpose of the field. If it does not fit
> the one line of 78 (ASCII) characters, it bounches back to the sender. I
> understand that sloppy e-mail software allows spammers to send the library
> of congress inside a subject field, but rest assured that I such abuses do
> not survive my filters, even if Trump himself will allow for it with a
> presidential decree.

...and now you even want to ignore them at all...


simply try defining rules for long subjects and score them properly.
This should be just enough:

header SUBJECT_OVER_78 Subject =~ /^.{79}/
header SUBJECT_OVER_100 Subject =~ /^.{101}/

--
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.
"Where do you want to go to die?" [Microsoft]

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

> you can do that for your *personal* mailserver but most admins on that
> planet are also repsonsible for other peoles mailbox and you can't apply
> such interpretation of rules their because your primary job is *to
> receive and deliver emails* and not to reject them and educate the world

> if i could i would enable a lof of filters which in combination would
> eliminate the remaining 1% of junk but as long as people have more
> damage with 1 false positive than 10 slipped junk mails it's just not possible

It is precisely because I am responsible for other persons that I make such 
rules
based upon the RFC standard, with bounce messages to educate the senders.
Domains that send e-mail to us are domains that we care for.

Take gmail, for example. They improve their policies, and everybody goes along 
with it.
Last month, they decided to reject JavaScript attachments upfront. There is no 
RFC
that says "you MUST reject JavaScript attachments", and yet, they do it, and 
for a very good reason.

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

> So, Ruga, if you just want to BCC a bunch of people, what do you propose
> [we] should be put into the To: header?

I would use this or similar:

To: no-re...@your.domain.com

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

A mailing list does not need to hide the recipients.
This mailing list, for example, uses a good policy.









 Original Message 
Subject: Re: RFC compliance pedantry (was Re: New type of monstrosity)
Local Time: 8 February 2017 3:04 AM
UTC Time: 8 February 2017 02:04
From: i...@primate.net
To: users@spamassassin.apache.org

On 2017-02-07 18:33, Ruga wrote:

> I follow the actual RFC standard, not the proposed revisions. The To
> From and Cc fields are defined by a grammar AND a natural language
> description. Such fields MUST hold addresses, were an address is a
> username the "@" symbol and a domain name. The string "undisclosed
> recipients: ;" does not parse the grammar, and it does not pass the
> natural language requirement for an address. If the sender hides the
> recipients, why should I care delivering its junk to my valued
> accounts?

FWIW, I regularly get completely legitimate non-commercial messages with
headers of this form. People use it to conceal from each recipient the
addresses of other recipients - just like a list or an alias, but (I'm
guessing) done entirely in the senders MUA.

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: RFC compliance pedantry (was Re: New type of monstrosity)

[Ruga]

I follow the actual RFC standard, not the proposed revisions. The To From and 
Cc fields are defined by a grammar AND a natural language description. Such 
fields MUST hold addresses, were an address is a username the "@" symbol and a 
domain name. The string "undisclosed recipients: ;" does not parse the grammar, 
and it does not pass the natural language requirement for an address. If the 
sender hides the recipients, why should I care delivering its junk to my valued 
accounts?

Bear in mind the state of corruption we live in. Spam is also a business, and 
the RFC proposed revisions are adapting to such business, to allow for it 
instead of impeding it.

On the subject length, although the RFC standard did not foresee the abuse, it 
did speak about the intended purpose of the field. If it does not fit the one 
line of 78 (ASCII) characters, it bounches back to the sender. I understand 
that sloppy e-mail software allows spammers to send the library of congress 
inside a subject field, but rest assured that I such abuses do not survive my 
filters, even if Trump himself will allow for it with a presidential decree.


On Tue, Feb 7, 2017 at 5:28 PM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Tue, 07 Feb 2017 02:57:06 -0500
Ruga <r...@protonmail.com> wrote:

> > To: undisclosed recipients: ;

> The To header is not RFC compliant.

Yes it is. RFC 5322 even gives the header Cc: undisclosed recipients: ;
as an example in Appendix A.1.3, Group Addresses.

> The Subject header exceeds the
> maximum line length, being another RFC constraints.

Nope. It's around 720 characters, less than the 998 maximum. And
while it's true that it's not wrapped at 78 characters, that's a SHOULD
requirement, not a MUST requirement.

Anyway, we see a few of these every so often. Bayes usually disposes
of them quite handily.

Regards,

Dianne.

Re: New type of monstrosity

[Ruga]

The spample would never make it to our SA. It would be rejected upstream for at 
least two reasons:

> To: undisclosed recipients: ;


The To header is not RFC compliant.The Subject header exceeds the maximum line 
length, being another RFC constraints. It is easy to catch spam this way.
On Tue, Feb 7, 2017 at 3:46 AM, Ian Zimmerman <'i...@primate.net'> wrote:
On 2017-02-06 20:06, Kevin A. McGrail wrote:

> > Last couple of weeks I saw some messages whose entire contents is in
> > the Subject.

> never seen such a monster. likely killed by some other piece in the
> puzzle. Throw it up on pastebin?

http://pastebin.com/PYaMcZa7

(I was wrong, the subject is actually one enormous line, it was my MUA
that folded it.)

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: Off-topic - IRS.gov Postmaster

[Ruga]

postmas...@irs.gov


On Wed, Feb 1, 2017 at 10:02 PM, Kevin A. McGrail <'kmcgr...@pccc.com'> wrote:
All:

I've got some email deliverability issues I'm trying to work through.
Anyone have a contact for a postmaster for IRS.gov? Likely a 10 minute
issue.

Regards,

KAM

Re: Ignore third-party SA headers

[Ruga]

500.000 bytes: spamc's default max-size
512.000 bytes: spamc's local default max-size
005.155 bytes: size of the specific spam









 Original Message 
Subject: Re: Ignore third-party SA headers
Local Time: 26 January 2017 2:03 AM
UTC Time: 26 January 2017 01:03
From: rwmailli...@googlemail.com
To: users@spamassassin.apache.org

On Wed, 25 Jan 2017 10:48:29 -0500
Ruga wrote:

> SA runs as follows.
>
> master.cf, last line of section smtp:
> > -o content_filter=spamcheck
>
> spamcheck unix - n n - 10 pipe
> flags=Rq
> user=spamd
> argv=/usr[/sbin/spamc](http://org.OpenServer/share/spamd/bin/spamc)
> --dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
> --headers
> --pipe-to /usr[/sbin/sendmail](http://org.OpenServer/port-465/sbin/sendmail)
> -G -i -f ${sender} -- ${recipient}
>
>
>
> Why SA accepts the third-party X-Spam header instead of producing its
> own?



Probably what's happening is that these are emails over 500 kB which by
default are just passed through by spamc without sending them to spamd.
If they don't get sent to spamd the existing SA headers don't get
stripped.

You can to set the -s parameter on spamc to something larger that the
largest spam you want to filter.

Re: Ignore third-party SA headers

[Ruga]

SA runs as follows.

master.cf, last line of section smtp:
> -o content_filter=spamcheck

spamcheck unix - n n - 10 pipe
flags=Rq
user=spamd
argv=/usr[/sbin/spamc](http://org.OpenServer/share/spamd/bin/spamc)
--dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
--headers
--pipe-to /usr[/sbin/sendmail](http://org.OpenServer/port-465/sbin/sendmail) -G 
-i -f ${sender} -- ${recipient}









spam that already includes SA headers is getting through without local SA 
filtering. Is it posible to tell the local SA to always add its own headers, 
possibly taking note of the existence of former SA headers while rewriting them 
out of the way?

The spam contains the following header, generated by a third-party relay:

X-Spam-Flag: YES X-Spam-Score: 15.015 X-Spam-Level: *** 
X-Spam-Status: Yes, score=15.015 tagged_above=- required=7 
tests=[DKIM_SIGNED=-0.1, DKIM_VALID=-0.01, DKIM_VERIFIED=-0.01, 
INVALUEMENT_SIP=4, RCVD_IN_BL=0.01, RCVD_IN_MANY_BL=2, RCVD_IN_SORBS_SPAM=0.5, 
RCVD_IN_TWO_BL=1, RCVD_IN_UCEPROTECT1=1, RCVD_IN_UCEPROTECT2=1, 
RCVD_IN_UCEPROTECT3=1, RCVD_IN_UNSUBSCORE=2, SUBJ_ALL_CAPS=1.625, 
TO_NO_BRKTS_NOTLIST=1] autolearn=disabled


Why SA accepts the third-party X-Spam header instead of producing its own?

Ignore third-party SA headers

[Ruga]

spam that already includes SA headers is getting through without local SA 
filtering. Is it posible to tell the local SA to always add its own headers, 
possibly taking note of the existence of former SA headers while rewriting them 
out of the way?

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

Yes, you can prefix a quoted string to the actual address. No, the quoted 
string is not part of the address.

There are two approaches here: one is to defend the spammer's abuse of the 
standard (intended to trick the average Joe into believing they have received 
mail from someone else), and the other is to read the standard


On Tue, Oct 18, 2016 at 4:02 AM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Mon, 17 Oct 2016 19:11:29 -0400
Ruga <r...@protonmail.com> wrote:

> rfc 822 (the actual standard):

Which as I mentioned is obsolete, but I'll play with you...

> authentic = "From" ":" mailbox ; Single author / ...
> mailbox = addr-spec ; simple address / phrase route-addr
> addr-spec = local-part "@" domain

And you left out the BNF of "phrase", didn't you? Tsk tsk!

You can't pick and choose pieces of RFCs, you know. They come as a package
deal.

TL;DR, the header:

From: "Dianne Skoll <d...@roaringpenguin.com>" <some...@spammer.org>

is absolutely compliant with RFC-822 and its successors, RFC-2822 and
RFC-5322.

Regards,

Dianne.

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

RFC 2822 and 5322 are in the "Standards Track".
RFC 822 is still the standard.


On Tue, Oct 18, 2016 at 2:52 AM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On October 17, 2016 7:11:29 PM EDT, Ruga <r...@protonmail.com> wrote:
>rfc 822 (the actual standard):

Are you serious? RFC 822 is decades obsolete, long since superseded by 2822 and 
then by 5322.

Regards,

Dianne.

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

<>


On Tue, Oct 18, 2016 at 1:25 AM, Paul Stead <'paul.st...@zeninternet.co.uk'> 
wrote:




On 17/10/16 23:52, Ruga wrote:

https://tools.ietf.org/html/rfc5322#section-3.6.2
from = "From:" mailbox-list CRLF ... 
https://tools.ietf.org/html/rfc5322#section-3.4 ... ---8<--- mailbox = 
name-addr / addr-spec name-addr = [display-name] angle-addr display-name = 
phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list Normally, a 
mailbox is composed of two parts: (1) an optional display name that indicates 
the name of the recipient (which can be a person or a system) that could be 
displayed to the user of a mail application, and (2) an addr-spec address 
enclosed in angle brackets ("<" and ">"). There is an alternate simple form of 
a mailbox where the addr-spec address appears alone, without the recipient's 
name or the angle brackets. The Internet addr-spec address is described in 
[section 3.4.1](https://tools.ietf.org/html/rfc5322#section-3.4.1).
--
Paul Stead
Systems Engineer
Zen Internet

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

rfc 822 (the actual standard):

authentic = "From" ":" mailbox ; Single author / ...
mailbox = addr-spec ; simple address  / phrase route-addr
addr-spec = local-part "@" domain



On Tue, Oct 18, 2016 at 12:52 AM, Ruga <'r...@protonmail.com'> wrote:

https://tools.ietf.org/html/rfc5322#section-3.6.2




On Mon, Oct 17, 2016 at 2:18 AM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Sun, 16 Oct 2016 18:08:20 -0400
Ruga <r...@protonmail.com> wrote:

> In my servers, the above string is not RFC compliant,
> and therefore the whole mail is automatically
> rejected as SPAM.

Your servers fail in RFC comprehension. The message header:

From: "Dianne Skoll <d...@roaringpenguin.com>" <unrela...@spammer.org>

is absolutely 100% RFC-compliant.

If you feel it is not, please cite the RFC that's violated, including
the specific section being violated.

Regards,

Dianne.

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

https://tools.ietf.org/html/rfc5322#section-3.6.2




On Mon, Oct 17, 2016 at 2:18 AM, Dianne Skoll <'d...@roaringpenguin.com'> wrote:
On Sun, 16 Oct 2016 18:08:20 -0400
Ruga <r...@protonmail.com> wrote:

> In my servers, the above string is not RFC compliant,
> and therefore the whole mail is automatically
> rejected as SPAM.

Your servers fail in RFC comprehension. The message header:

From: "Dianne Skoll <d...@roaringpenguin.com>" <unrela...@spammer.org>

is absolutely 100% RFC-compliant.

If you feel it is not, please cite the RFC that's violated, including
the specific section being violated.

Regards,

Dianne.

Re: The real spoofing issue (was Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless)

[Ruga]

> From: "Dianne Skoll " 


In my servers, the above string is not RFC compliant,
and therefore the whole mail is automatically
rejected as SPAM.

Re: freemail

[Ruga]

send evidence to protonmail admin:
they will close the account

Sent from ProtonMail Mobile


On Tue, Sep 27, 2016 at 6:11 PM, Axb <'axb.li...@gmail.com'> wrote:
On 09/27/2016 06:05 PM, Benny Pedersen wrote:
>
> got spam from it
>
> protonmail.com
> protonmail.ch
>
> is missing in spamassassin
>
> i can provide sample to rule maintainers on request

20_freemail_domains.cf

Committed revision 1762511.

Re: Spoofed Domain

[Ruga]

thank you for teasing us...

Sent from ProtonMail Mobile


On Wed, Aug 10, 2016 at 3:36 PM, Larry Starr <'lar...@fullcompass.com'> wrote:

That is what I'm doing here.

Rather than attempting that with SA, I wrote a MimeDefang routine to 
interrogate the "Magic" number of any office document, blocking all macro 
enabled documents, and any document that was renamed so that the Magic number 
does not match the extension ( I don't care if these are Macro enabled or not, 
there is no legitimate reason to rename them ).

On Wednesday, August 10, 2016 09:31:21 Joe Quinn wrote:




That's a very good warning indeed! Perhaps blocking .doc files with a zip-like 
file structure is in order? I can't think of a legitimate reason to use the old 
extension on the new file format.

On 8/10/2016 9:28 AM, Larry Starr wrote:






On Tuesday, August 09, 2016 18:01:57 Rob McEwen wrote:

> On 8/9/2016 5:56 PM, Anthony Hoppe wrote:

> > Here are the headers as an example:

> > http://pastebin.com/bnU0npLR

> > This particular email has a macro-enabled Word document attached, but I

> > don't want to assume this will be the case every time.

> > Any tips/tricks/suggestions would be greatly appreciated!

>

> I think there is a trend now... towards blocking ALL .docm files (if

> not, there should be!). I think it is EXTREMELY rare for normal human

> beings to send Word documents in that particularly dangerous format.

> Most would be send in .doc or .docx format.

>

> I'm not sure if there is already a SA rule for scoring against .docm

> files attachments? Perhaps someone else could help you with that.



Just a short warning, although word will not open a .docm that is renamed to 
.docx, it will open a .docm renamed to .doc.



I found this the hard way!



It is necessary, if you wish to be safe from macro enabled documents to verify 
that the file is what the attachment's extension claims to be.



--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com








--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com

Re: Paragraph Length Limit (new rule)

[Ruga]

New tests lead me to the following rule. It works
and is now deployed on production servers.

full B_PLL /(?:(?!<\/p>).){2000}/msi
describe B_PLL Paragraph Length Limit
score B_PLL 1.5

rawbody has a hidden bug: it breaks the above rule too.
I am re-writing all local rules to "full" until "rawbody" is fixed.

2000 is an arbitrary number that fits the local corpus at this time.
The long paragraph in the original spam had 10797 characters,
and was 192 lines long.

The score is now 1.5/5.0. The original spam scored 1.6/5.0.
An additional rule scores 1.0 for any uri to a php page,
and a third rule scores 1.0 when the From addr contains numbers.
The resulting score for the original spam is now 5.0/5.0

Please catch the bug in rawbody.

Re: Paragraph Length Limit (new rule)

[Ruga]

>Looks like a SA bug to me.
At last...

> rawbody __B_PLL /(?:(?!).){999}/msi
Well done.

>> tflags __B_PLL multiple maxhits=1

>Pointless. Why set the "multiple" flag if you're going to set "maxhits=1"??

To really stop at the first match.

> simply having a paragraph longer than 999 characters isn't inherently or 
> heuristically spammy.

We receive spam with long paragraphs of nonsensical garbage, possibly to poison 
the corpus and results of automated learning. They are now sending headlines 
from the news, instead of random words and broken grammar. By rejecting such 
junk upront, we keep the system healthy.

Also, when you see such spam on screen, that single long paragraph that fills 
pages and pages with junk, it would be pointless to keep you as a postmaster...

Re: Paragraph Length Limit (new rule)

[Ruga]

I cannot post the original spam message.
Protonmail checks the outgoing messages:
if they are spammy, then the sender is banned.
I managed to send you a stripped version of
the original without loosing my account.
Be happy with it, because it is as close as you will ever get to the ugliness 
of the original.

Sent from ProtonMail Mobile


On Wed, Aug 3, 2016 at 6:59 PM, Matus UHLAR - fantomas <'uh...@fantomas.sk'> 
wrote:
On 03.08.16 12:42, Ruga wrote:
>This is the stripped test. The number of characters is reduced to 72
>from the original 999: make your own choice. The attached e-mail
>triggers the rule *if* I remove at least one "example" string.
>
>Perl: 5.22.2
>SA: 3.4.1
>
>rawbody B_PLL m|(?:(?!).){72,}|msi
>describe B_PLL Paragraph Length Limit
>score B_PLL 1.0

again. post the real sample of the spam

We can't help you if you only post the rule - we don't know what you expect
it to match.

--
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.
Nothing is fool-proof to a talented fool.

Re: Paragraph Length Limit (new rule)

[Ruga]

Sent from ProtonMail Mobile


On Wed, Aug 3, 2016 at 6:59 PM, Matus UHLAR - fantomas <'uh...@fantomas.sk'> 
wrote:
On 03.08.16 12:42, Ruga wrote:
>This is the stripped test. The number of characters is reduced to 72
>from the original 999: make your own choice. The attached e-mail
>triggers the rule *if* I remove at least one "example" string.
>
>Perl: 5.22.2
>SA: 3.4.1
>
>rawbody B_PLL m|(?:(?!).){72,}|msi
>describe B_PLL Paragraph Length Limit
>score B_PLL 1.0

again. post the real sample of the spam

We can't help you if you only post the rule - we don't know what you expect
it to match.

--
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.
Nothing is fool-proof to a talented fool.

Re: Paragraph Length Limit (new rule)

[Ruga]

> Use a 'full' not 'rawbody' rule.
I do not need to parse the header.

>Why are you doing a "tflags __B_PLL multiple maxhits=1" ?
>If you have "maxhits=1" what's the point of "multiple" at all?
To limit the number of possible matches to a single one.

Re: Paragraph Length Limit (new rule)

[Ruga]

OK

Sent from ProtonMail Mobile


On Wed, Aug 3, 2016 at 12:58 PM, Ryan Coleman <'ryan.cole...@cwis.biz'> wrote:
Keep in mind we do not know that. It is better to not reply and wait a few 
hours than get Reindl worked up. :)


> On Aug 3, 2016, at 5:55 AM, Ruga <r...@protonmail.com> wrote:
>
> I am AWAY for my office.
> Real spam truly unnecessary.
>
> Sent from ProtonMail Mobile
>
>
> On Wed, Aug 3, 2016 at 12:51 PM, Reindl Harald <'h.rei...@thelounge.net'> 
> wrote:
>>
>> Am 03.08.2016 um 12:49 schrieb Ruga:
>> > echo "$( cat /dev/urandom | env LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold
>> > -w 999 | head -n 1 )" >example.txt
>> >
>> > spamassassin -t -D B_LLL.rule >
>> you where asked for a real *mail* example instead some generic stuff
>>
>> > On Wed, Aug 3, 2016 at 12:15 PM, Axb <'axb.li...@gmail.com'> wrote
>> >> please pastebin a sample msg
>>

Re: Paragraph Length Limit (new rule)

[Ruga]

I am AWAY for my office.
Real spam truly unnecessary.

Sent from ProtonMail Mobile


On Wed, Aug 3, 2016 at 12:51 PM, Reindl Harald <'h.rei...@thelounge.net'> wrote:

Am 03.08.2016 um 12:49 schrieb Ruga:
> echo "$( cat /dev/urandom | env LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold
> -w 999 | head -n 1 )" >example.txt
>
> spamassassin -t -D B_LLL.rule  On Wed, Aug 3, 2016 at 12:15 PM, Axb <'axb.li...@gmail.com'> wrote
>> please pastebin a sample msg

Re: Paragraph Length Limit (new rule)

[Ruga]

echo "$( cat /dev/urandom | env LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold -w 999 
| head -n 1 )" >example.txt

spamassassin -t -D B_LLL.rule  wrote
please pastebin a sample msg

Re: Paragraph Length Limit (new rule)

[Ruga]

>I would be most grateful if you could spot the but in the above rule.

The *bug*, sorry.

Paragraph Length Limit (new rule)

[Ruga]

Hello,

We received a new type of spam, twice, and we are not willing to give them a 
third chance.
The body includes a long html paragraph (...) of headlines from the news.

The following works at the command line:
perl -p0e 's/((?:(?!<\/p>).){999,}<\/p>)/-->$1<--/msig' example.eml
perl -n0e '/((?:(?!<\/p>).){999,}<\/p>)/msig and print "--->$1<---"' 
example.eml

The following SA rule, however, does not work at all:

rawbody __B_PLL /(?:(?!<\/p>).){999,}<\/p>/msi
tflags __B_PLL multiple maxhits=1
meta B_PLL __B_PLL
describe B_PLL Body: Paragraph Length Limit
score B_PLL 1.0

I would be most grateful if you could spot the but in the above rule.