You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by David Jones <dj...@ena.com> on 2018/02/05 14:09:55 UTC
Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Heads up! This RBL has been removed from the core SA ruleset. In 36 to
48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after it
has gone through the masscheck and rule promotion process.
Details can be found here:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417
To add this rule back manually, you should register here:
http://barracudacentral.org/account/register
and add this to your local.cf:
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_BRBL eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags __RCVD_IN_BRBL net
header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
'127.0.0.2')
meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
describe RCVD_IN_BRBL Received is listed in Barracuda RBL
bb.barracudacentral.org
score RCVD_IN_BRBL 1.2
tflags RCVD_IN_BRBL net
header RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
describe RCVD_IN_BRBL_LASTEXT Last external is listed in
Barracuda RBL bb.barracudacentral.org
score RCVD_IN_BRBL_LASTEXT 2.2
tflags RCVD_IN_BRBL_LASTEXT net
endif
NOTE: recent masscheck processing shows RCVD_IN_BRBL_LASTEXT as the most
effective non-zero scoring rule to hit spam (43%) so it's probably worth
adding back to your local.cf on Wednesday or Thursday.
http://ruleqa.spamassassin.org/20180203-r1823022-n/RCVD_IN_BRBL_LASTEXT/detail
--
David Jones
Re: Email filtering theory and the definition of spam
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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.
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
> good news is if non spammers begin to use pgp signed/encrypted mails, it
would not be spam anymore
If they send spam from an identifiable server within our legal reach, we turn it to our local authority who exerts judiciary power to either shut down the server, in case they are pure spammers, or obtain monetary compensation otherwise. We reject unidentifiable servers, and anything from out-of-legal-reach.
We are serious about spam. 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. Fuck the RFC loopholes.
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
I am not protonmail.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 03:12, Benny Pedersen <me...@junc.eu> wrote:
> Rupert Gallagher skrev den 2018-02-10 23:18: > pay their clients for each spam message they deliver, they would be > all bankrupt, except us. if protonmail worked, spamasassin could not scan spam :=) oh well, pgp is cool, but as its implented on protonmail it does not matter at all i think this is very sad if custommers on protonmail find that info, apps seems to be secure, webmail seems to be secure, but servers makes the local pgp crypt, so it on sarvers in safe state, it just not secure where the copys are that was why i dropped it, its good, but not perfekt, i am not perfekt either, loosed my crupt password :=) good news is if non spammers begin to use pgp signed/encrypted mails, it would not be spam anymore
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
Said the blind person...
Sent from ProtonMail Mobile
On Tue, Feb 13, 2018 at 21:03, @lbutlr <kr...@kreme.com> wrote:
> On 13 Feb 2018, at 06:57, Rupert Gallagher wrote: > Not sure why you guys are still discussing RFCs, though, Because one person keeps insisting that RFC822 is the relevant active standard despite being shown multiple times that it’s been obsoleted. Twice. -- If you [Carrot] were dice, you'd always roll sixes. And the dice don't roll themselves. If it wasn't against everything he wanted to be true about the world, Vimes might just then have believed in destiny controlling people. And gods help the other people who were around when a big destiny was alive in the world, bending every poor bugger around itself... @protonmail.com>
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 13 Feb 2018, at 06:57, Rupert Gallagher <ru...@protonmail.com> wrote:
> Not sure why you guys are still discussing RFCs, though,
Because one person keeps insisting that RFC822 is the relevant active standard despite being shown multiple times that it’s been obsoleted. Twice.
--
If you [Carrot] were dice, you'd always roll sixes. And the dice don't
roll themselves. If it wasn't against everything he wanted to be true
about the world, Vimes might just then have believed in destiny
controlling people. And gods help the other people who were around when
a big destiny was alive in the world, bending every poor bugger around
itself...
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
Humans tend to confuse Science and Engineering, including professional journalists: their mistake does not change the facts, but certainly confuses the weaker minds.
Sent from ProtonMail Mobile
On Mon, Feb 12, 2018 at 08:49, Groach <gr...@yahoo.com> wrote:
> 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 (see
> [Section 6 of RFC 2026](https://tools.ietf.org/html/rfc2026#section-6)
> ). 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
Posted by Groach <gr...@yahoo.com>.
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 <https://tools.ietf.org/html/rfc2026#section-6>). 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
Posted by Rupert Gallagher <ru...@protonmail.com>.
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 <An...@spamassassin.open.source.it> 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
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@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
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
You are wrong. Read again.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 22:51, @lbutlr <kr...@kreme.com> 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
Posted by Rupert Gallagher <ru...@protonmail.com>.
You confuse the press with the author.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 19:23, Reindl Harald <h....@thelounge.net> 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: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-11 (11:15 MST), Rupert Gallagher <ru...@protonmail.com> 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: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
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 <kr...@kreme.com> 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>
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-11 (00:13 MST), Rupert Gallagher <ru...@protonmail.com> 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: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
Interesting to kreme.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 03:14, Benny Pedersen <me...@junc.eu> wrote:
> Rupert Gallagher skrev den 2018-02-10 23:26: > Interesting... how ? > > Final-Recipient: rfc822; kremels@kreme.com > Original-Recipient: rfc822;kremels@kreme.com > Action: failed > Status: 5.7.1 > Remote-MTA: dns; mail.covisp.net > Diagnostic-Code: smtp; 550 5.7.1 : Helo command > rejected: > Mail for this TLD is not allowed > ---------------------------------------------- > message/rfc822 i am to tired of thinking what happended here
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
I read the RFC as anybody else, and get as close as possible to cite it when rejecting. The fact that the RFC has loopholes is not my fault.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 01:17, Reindl Harald <h....@thelounge.net> wrote:
> Am 10.02.2018 um 23:18 schrieb Rupert Gallagher: > We do not serve freemail or large ISPs, so our use case is different > than yours. We serve businesses who own their email by law. When an > employee sends or receives an email, their employer owns the email, by > law. We can, and we do reject spam: the recipient will never see it, by > contract. Possibly-spam gets redirected for manual inspection. Last > january we scored a perfect zero spam on end-users mailbox, and about 10 > manual inspections with zero false positives. If providers would pay > their clients for each spam message they deliver, they would be all > bankrupt, except us that is all fine for you but you pretend all the time that what you are doing is required by this and that RFC which is most of the time proven to be a lie or at best lack of understanding on your side there is a difference between reject spam and pretend whatever action is mandated by a RFC
Re: Email filtering theory and the definition of spam
Posted by Benny Pedersen <me...@junc.eu>.
Rupert Gallagher skrev den 2018-02-10 23:26:
> Interesting...
how ?
>
> Final-Recipient: rfc822; kremels@kreme.com
> Original-Recipient: rfc822;kremels@kreme.com
> Action: failed
> Status: 5.7.1
> Remote-MTA: dns; mail.covisp.net
> Diagnostic-Code: smtp; 550 5.7.1 <mail3.protonmail.ch>: Helo command
> rejected:
> Mail for this TLD is not allowed
> ----------------------------------------------
> message/rfc822
i am to tired of thinking what happended here
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-10 (15:26 MST), Rupert Gallagher <ru...@protonmail.com> wrote:
>
> Interesting...
>
>
> Final-Recipient: rfc822; kremels@kreme.com
> Original-Recipient: rfc822;kremels@kreme.com
> Action: failed
> Status: 5.7.1
> Remote-MTA: dns; mail.covisp.net
> Diagnostic-Code: smtp; 550 5.7.1 <mail3.protonmail.ch>: Helo command rejected:
> Mail for this TLD is not allowed
Your point?
--
...but the senator, while insisting he was not intoxicated, could not
explain his nudity.
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
Interesting...
Final-Recipient: rfc822; kremels@kreme.com
Original-Recipient: rfc822;kremels@kreme.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.covisp.net
Diagnostic-Code: smtp; 550 5.7.1 <mail3.protonmail.ch>: Helo command rejected:
Mail for this TLD is not allowed
----------------------------------------------
message/rfc822
...
>
Re: Email filtering theory and the definition of spam
Posted by Benny Pedersen <me...@junc.eu>.
Rupert Gallagher skrev den 2018-02-10 23:18:
> pay their clients for each spam message they deliver, they would be
> all bankrupt, except us.
if protonmail worked, spamasassin could not scan spam :=)
oh well, pgp is cool, but as its implented on protonmail it does not
matter at all
i think this is very sad if custommers on protonmail find that info,
apps seems to be secure, webmail seems to be secure, but servers makes
the local pgp crypt, so it on sarvers in safe state, it just not secure
where the copys are
that was why i dropped it, its good, but not perfekt, i am not perfekt
either, loosed my crupt password :=)
good news is if non spammers begin to use pgp signed/encrypted mails, it
would not be spam anymore
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
We do not serve freemail or large ISPs, so our use case is different than yours. We serve businesses who own their email by law. When an employee sends or receives an email, their employer owns the email, by law. We can, and we do reject spam: the recipient will never see it, by contract. Possibly-spam gets redirected for manual inspection. Last january we scored a perfect zero spam on end-users mailbox, and about 10 manual inspections with zero false positives. If providers would pay their clients for each spam message they deliver, they would be all bankrupt, except us.
Sent from ProtonMail Mobile
On Sat, Feb 10, 2018 at 18:04, @lbutlr <kr...@kreme.com> wrote:
> On 2018-02-10 (00:01 MST), Rupert Gallagher wrote: > > The RFC should be amended. If not, we still reject on common sense. Our mail, our rules. My rule is that I do everything I can to reject mail. I look at the IPs, headers, Subject, and content. I look for suspicious attachments, dangerous attachment types, and scan for the millions of Windows viruses. I compare the message to other messages and if at all possible I do not accept the mail. In fact, my main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% rejection rate now. However, once I accept the mail, it is delivered to the recipient, no matter what. Now, it might be delivered to a "Probably spam" folder, and that folder may expire mail after a week or so, but it is *delivered* and the recipient has the opportunity to reclassify that mail as being "ham". -- I mistook thee for thy better Hamlet Act III scene 4 @protonmail.com>
Re: Email filtering theory and the definition of spam
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 10 Feb 2018, at 16:00 (-0500), Alex wrote:
> Can we really trust end-users to properly classify email and not
> infect themselves with something or follow a phish without knowing?
Nope. However, we need to act like we do to some degree while doing the
best we can to make it difficult for them to do dumb things.
--
Bill Cole
bill@scconsult.com or billcole@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
Posted by Alex <my...@gmail.com>.
Hi,
On Sat, Feb 10, 2018 at 12:04 PM, @lbutlr <kr...@kreme.com> wrote:
> On 2018-02-10 (00:01 MST), Rupert Gallagher <ru...@protonmail.com> wrote:
>>
>> The RFC should be amended. If not, we still reject on common sense. Our mail, our rules.
>
> My rule is that I do everything I can to reject mail. I look at the IPs, headers, Subject, and content. I look for suspicious attachments, dangerous attachment types, and scan for the millions of Windows viruses. I compare the message to other messages and if at all possible I do not accept the mail. In fact, my main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% rejection rate now.
>
> However, once I accept the mail, it is delivered to the recipient, no matter what.
>
> Now, it might be delivered to a "Probably spam" folder, and that folder may expire mail after a week or so, but it is *delivered* and the recipient has the opportunity to reclassify that mail as being "ham".
Can we really trust end-users to properly classify email and not
infect themselves with something or follow a phish without knowing?
Many of our customers have additional services such as those from
Wombat to train users on what to do with suspicious emails and yet
they *continually* fall for both these fake test phish emails and the
real ones, many times resulting in more than one system compromise.
At the same time, withholding emails from users results in a lack of
confidence that their emails aren't being redirected to the ether...
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-10 (00:01 MST), Rupert Gallagher <ru...@protonmail.com> wrote:
>
> The RFC should be amended. If not, we still reject on common sense. Our mail, our rules.
My rule is that I do everything I can to reject mail. I look at the IPs, headers, Subject, and content. I look for suspicious attachments, dangerous attachment types, and scan for the millions of Windows viruses. I compare the message to other messages and if at all possible I do not accept the mail. In fact, my main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% rejection rate now.
However, once I accept the mail, it is delivered to the recipient, no matter what.
Now, it might be delivered to a "Probably spam" folder, and that folder may expire mail after a week or so, but it is *delivered* and the recipient has the opportunity to reclassify that mail as being "ham".
--
I mistook thee for thy better Hamlet Act III scene 4
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
If you pick up the snail mail equivalent, you either have spam without address or a mail with someone else's address. We put the spam where it belongs, and return the other unopened.
We make no exception to e-mail, because they are mail after all.
The RFC should be amended. If not, we still reject on common sense. Our mail, our rules.
R
On Fri, Feb 9, 2018 at 22:26, Joseph Brennan <br...@columbia.edu> wrote:
> Objection. RFC 822, section A.3.1 "Minimum required" shows two alternatives of the minimum. The one on the left has Date and From and Bcc, and the Bcc has no address in it. The other one on the right has Date and From and a To field with an address in it.
>
> Now read it again:
>
> C.3.4. DESTINATION
>
> A message must contain at least one destination address field.
> "To" and "CC" are required to contain at least one address.
> A.3.1 clarifies that the minimum required is either Bcc or To, both of which are destination fields, and that if the destination field is To, then To must contain an address.
> In section 4.5.3 it states that Bcc contents are not included in copies sent, which leaves a transmitted message with just Date and From, the state which the plaintiff claims is not compliant.
> -- Joseph Brennan
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
If you agreed to receive news from X, and receive them via mass-mailer Y, be prepared to also receive from Z via Y, where Z is third party on behalf of X or Y. Morale: when you agree to X, remember to opt out to their third parties.
Sent from ProtonMail Mobile
On Thu, Feb 8, 2018 at 16:23, David Jones <dj...@ena.com> 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. -- David Jones
Re: Email filtering theory and the definition of spam
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2018-02-08 at 09:23 -0600, 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.
>
You can't, but that should not matter because the recipient can sign in
and cancel the opt-in.
If this doesn't work then, in the UK, you can report them to the ICO
which should get the company reprimanded and, for a repeat offender,
may get them a fine. Under the new privacy rules, which apply from
May, non-compliance may get them a fairly heavy smack round the chops,
so I think its likely that legit companys will clean up their act.
OTOH waking up the ICO may not work if, like the automated cold
callers, the spamming company dodges the fine by declaring bankruptcy
before reappearing under another name and going on spamming.
There's another related point which may not have sunk in yet: because
of the way the new privacy regime will work, you must be able to tell
any company where you have an account, that you no longer need it and
that they must cancel the account and delete your details as soon as
any outstanding activities, bills, etc. have been completed. I notice
that there are still a lot of websites that do not provide any way of
cancelling an account, so this is something they'll have to provide
sooner rather than later.
Martin
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-08 (08:23 MST), David Jones <dj...@ena.com> wrote:
>
> 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.
That wasn't the question you asked. Is it spam and how do you mark it as spam are entirely different question and different issues.
--
Gehm's Corollary to Clarke's law: Any technology distinguishable from
magic is insufficiently advanced.
Re: Email filtering theory and the definition of spam
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Hi All,
dkimwl.org is a site owned and run by myself.
A little bit of work is required to get the TOU sorted - I'd floated the idea some time ago but not much interest was seen so I stopped work on the front end services. The backend and classification/voting system is in place and should work without too much hassle.
If people are looking at this as a wanted service I can definitely spend some time updating and cleaning up the last bits that need fixing.
Thanks for the heads up re: SSL
Please feel free to get in touch if you want to share ideas / help
Paul
On 08/02/2018, 16:09, "Tom Hendrikx" <to...@whyscream.net> wrote:
On 08-02-18 16:33, Giovanni Bechis wrote:
> On 02/08/18 16: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.
>>
> dkimwl.org looks promising, but tell them their https cert has expired.
> Giovanni
>
Also, they refer to the TOU for acceptable usage, but both /terms and
/license have a 404.
Kind regards,
Tom
--
Paul Stead
Senior Engineer (Tools & Technology)
Zen Internet
Direct: 01706 902018
Web: zen.co.uk
Winner of 'Services Company of the Year' at the UK IT Industry Awards
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: Email filtering theory and the definition of spam
Posted by Tom Hendrikx <to...@whyscream.net>.
On 08-02-18 16:33, Giovanni Bechis wrote:
> On 02/08/18 16: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.
>>
> dkimwl.org looks promising, but tell them their https cert has expired.
> Giovanni
>
Also, they refer to the TOU for acceptable usage, but both /terms and
/license have a 404.
Kind regards,
Tom
Re: Email filtering theory and the definition of spam
Posted by Giovanni Bechis <gi...@paclan.it>.
On 02/08/18 16: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.
>
dkimwl.org looks promising, but tell them their https cert has expired.
Giovanni
Re: Email filtering theory and the definition of spam
Posted by jdow <jd...@earthlink.net>.
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
Posted by jdow <jd...@earthlink.net>.
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
Posted by David Jones <dj...@ena.com>.
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.
--
David Jones
Re: Email filtering theory and the definition of spam
Posted by Dave Warren <dw...@thedave.ca>.
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.
Re: Email filtering theory and the definition of spam
Posted by Martin Gregorie <ma...@gregorie.org>.
> 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'.
Martin
Re: Email filtering theory and the definition of spam
Posted by LuKreme <kr...@kreme.com>.
On Feb 7, 2018, at 06:17, David Jones <dj...@ena.com> wrote:
>
> Hypothetical question: If you signed up for a new account on a website and they had a small checkbox that was enabled to receive emails from them and you didn't see it to uncheck it, when you get an email from them a month later, is that spam?
Yes, because i didn't ask for it. Now, will I blackhole all such emails? Eh, probably not. When I bought a t-shirt and the company sent me marketing emails, I went in and un subbed because, frankly, that was the simplest laziest thing I could do.
Now, if I un sub and they send more mail, or tell me it will take 30 days to remove my email, THEN I nuke them.
But if it's commercial mail i didn't specifically ask to receive, it's spam.
--
This is my signature. There are many like it, but this one is mine.
Re: Email filtering theory and the definition of spam
Posted by David Jones <dj...@ena.com>.
On 02/06/2018 07:43 PM, jdow wrote:
> 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."
>
Hypothetical question: If you signed up for a new account on a website
and they had a small checkbox that was enabled to receive emails from
them and you didn't see it to uncheck it, when you get an email from
them a month later, is that spam?
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.
Users often sign up for things and then a few months or years later they
no longer want it so they call it spam. That is unwanted ham and not
spam by my definition.
--
David Jones
Re: Email filtering theory and the definition of spam
Posted by jdow <jd...@earthlink.net>.
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: Email filtering theory and the definition of spam
Posted by Miles Fidelman <mf...@meetinghouse.net>.
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
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-10 (12:07 MST), Joseph Brennan <br...@columbia.edu> wrote:
>
> --On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr" <kr...@kreme.com> wrote:
>> RFC 822 hasn't been valid for nearly two decades.
>
> Yes of course. My point was that even decades ago, To and Cc headers were not required by RFC 822, so our contributor should not say that he is blocking for violating RFC 822.
But even if they were required in RFC 822, RFC 822 has been obsoleted not just once, but twice.
So, someone claiming to be blocking based on RFC 822 in 2018 is showing their total ignorance of RFCs since it matters not at all what RFC 822 says. and hasn't since 2822 was accepted (and that has been obsoleted in turn, so it is also not valid).
> He can say he is blocking because he wants mail to have a To header. He can block because a subject line contains the letter Z if he wants to. That is a different line of argument than calling an RFC violation.
Sure, but calling an RFC violation is also different from calling an RFC violation for an INVALID RFC.
--
NOBODY LIKES SUNBURN SLAPPERS Bart chalkboard Ep. 7F23
Re: Email filtering theory and the definition of spam
Posted by Joseph Brennan <br...@columbia.edu>.
--On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr" <kr...@kreme.com>
wrote:
> RFC 822 hasn't been valid for nearly two decades.
Yes of course. My point was that even decades ago, To and Cc headers were
not required by RFC 822, so our contributor should not say that he is
blocking for violating RFC 822.
He can say he is blocking because he wants mail to have a To header. He can
block because a subject line contains the letter Z if he wants to. That is
a different line of argument than calling an RFC violation.
-- Joseph Brennan
Re: Email filtering theory and the definition of spam
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-09 (14:26 MST), Joseph Brennan <br...@columbia.edu> wrote:
>
> RFC 822,
RFC 822 hasn't been valid for nearly two decades.
The current RFC is 5322.
"The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional."
--
'Witches just aren't like that,' said Magrat. 'We live in harmony with
the great cycles of Nature, and do no harm to anyone, and it's wicked of
them to say we don't. We ought to fill their bones with hot lead.'
Re: Email filtering theory and the definition of spam
Posted by Joseph Brennan <br...@columbia.edu>.
Objection. RFC 822, section A.3.1 "Minimum required" shows two alternatives
of the minimum. The one on the left has Date and From and Bcc, and the Bcc
has no address in it. The other one on the right has Date and From and a To
field with an address in it.
Now read it again:
C.3.4. DESTINATION
A message must contain at least one destination address field.
"To" and "CC" are required to contain at least one address.
A.3.1 clarifies that the minimum required is either Bcc or To, both of
which are destination fields, and that if the destination field is To, then
To must contain an address.
In section 4.5.3 it states that Bcc contents are not included in copies
sent, which leaves a transmitted message with just Date and From, the state
which the plaintiff claims is not compliant.
-- Joseph Brennan
Re: Email filtering theory and the definition of spam
Posted by Rupert Gallagher <ru...@protonmail.com>.
Case study...
Well-known MTAs and SA itself allow (do not reject, do not flag) e-mails with absent or empty "To" header.
If I receive one such snail mail, I know it is not for me, and I know it is unwanted commercial advertisement that fills the mailbox and litters the floor.
RFC 822, page 42, section C.3.4:
<< A message must contain at least one destination address field. "To" and "CC" are required to contain at least one address.>>
The similar constraint does not seem to occur in RFC 5321 and RFC 5322.
We reject e-mail with a missing recipient, based upon common sense and RFC 822.
Sent from ProtonMail Mobile
On Tue, Feb 6, 2018 at 22:47, Anne P. Mitchell Esq. <am...@isipp.com> 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. Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop
Re: Email filtering theory and the definition of spam
Posted by "Anne P. Mitchell Esq." <am...@isipp.com>.
>
> 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.
Anne
Anne P. Mitchell,
Attorney at Law
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
CEO/President, Institute for Social Internet Public Policy
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, Cal. Bar Cyberspace Law Committee
Member, Colorado Cyber Committee
Member, Elevations Credit Union Member Council
Member, Board of Directors, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop
Email filtering theory and the definition of spam
Posted by David Jones <dj...@ena.com>.
I know the definition of spam is very subjective and dependent on your
particular the mail flow along with the expectations of the recipients.
On 02/06/2018 02:06 PM, David B Funk wrote:
> On Tue, 6 Feb 2018, Kris Deugau wrote:
>
>> Alex wrote:
>>> These phishes we've received were all from otherwise trusted sources
>>> like salesforce, amazonses and sendgrid. These are examples that I
>>> believe were previously whitelisted because of having received a phish
>>> through these systems but have no been disabled.
>>>
>>> whitelist_auth *@bounce.mail.salesforce.com
>>> whitelist_auth *@sendgrid.net
>>> whitelist_auth *@*.mcdlv.net
>>
>> I've seen enough spam sent through all three - both by way of whole
>> apparently spammer-owned accounts and cracked-but-otherwise-legitimate
>> accounts - that I would never blanket-whitelist whole bulk email
>> providers.
>>
>> Legitimate mail sent through them generally gets through anyway IME.
>
> An alternative is to use "def_whitelist_auth" instead of "whitelist_auth"
> That gives a -7.5 point bump to usually good sources which may
> occasionally get abused.
>
> That way if one of their accounts gets p0wned your anti-phish rules have
> a chance of pulling the junk into the spam-tagged range.
>
>
Good point. One could also set the score for whitelist_auth-based
scores to something similar like -7.5 or -5.0 if the default score of
-100 is to far left for their comfort.
score USER_IN_DKIM_WHITELIST -7.5
score USER_IN_SPF_WHITELIST -7.5
Email filtering is really more than just 2 classifications: ham and
spam. If you break it down into a few more sub categories, then it's
easier/less risky to detect/block the bad stuff from compromised
accounts and zero-hour spam.
- Ham
- Trusted Mailing lists
- Trusted Bulk Senders (system generated)
- Good senders (human generated)
- Unwanted - valid/non-harvesting opt-out
- UCE from address being bought/sold on lists
- Something opted into accidentally (didn't uncheck a box)
- Spam
- BAD: Junk never opted into
- BAD: Questionable marketing of goods/pills
- VERY BAD: Spoofing/Phishing/Click-for-Malware-Infection
- VERY BAD: Malicious attachments/macros/scripting/etc
Most people on this list will probably combine the unwanted into the
spam category but 1) how can you objectively and consistently determine
that for your end users and 2) we can't trust end users to know the
difference between the two. From my experience, end users will flag
everything as spam and complain about it either way so the most
important thing to block is the malicious/spoofing/phishing/malware that
can do real damage.
My goal is to block all of the spam and none of the ham and unwanted. I
have an automated way to determine the ham and unwanted to create
whitelist_auth entries primarily of subdomains that do not have human
mailboxes that can be compromised.
The way we determine the categories above is by:
- Reputation: RBLs, DBLs, URIBLs, whitelist_*, blacklist_*, etc.
- Content: BAYES, words, phrases, regex rules, etc.
If I whitelist_auth in a safe way based on reputation since they mostly
score very low anyway, then I have a smaller subset to focus on with
content rules and meta rules to bump up the sensitivity on the content side.
As SPF, DKIM, and DMARC are deployed on subdomains delegated to trusted
third-party senders, then this tactic rewards those who use good SPF,
DKIM, and DMARC on a subdomain thus promoting itself. This makes sense
to me and has worked well for years now. Rspamd seems to be following a
similar approach in it's dmarc_whitelist.inc file.
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Posted by Alex <my...@gmail.com>.
Hi,
>>> whitelist_auth *@bounce.mail.salesforce.com
>>> whitelist_auth *@sendgrid.net
>>> whitelist_auth *@*.mcdlv.net
>>
>>
>> I've seen enough spam sent through all three - both by way of whole
>> apparently spammer-owned accounts and cracked-but-otherwise-legitimate
>> accounts - that I would never blanket-whitelist whole bulk email providers.
>>
>> Legitimate mail sent through them generally gets through anyway IME.
>
> An alternative is to use "def_whitelist_auth" instead of "whitelist_auth"
> That gives a -7.5 point bump to usually good sources which may occasionally
> get abused.
>
> That way if one of their accounts gets p0wned your anti-phish rules have a
> chance of pulling the junk into the spam-tagged range.
Phishing is a significant concern for us. Whether or not the phish
came through the customer of one of these senders or through the
senders themselves, whitelisting these senders only facilitates more
phishes. There was a period when it was about one being reported by a
particularly large customer per day. Telling my customers that we've
contacted the provider and reported the spam just isn't good enough.
We also received a phish through freshdesk.com which is on the
def_whitelist. It's also on the DKIMWL_WL, subtracting another -3.5
points. It was also listed in RCVD_IN_HOSTKARMA_W, but also in
LASHBACK_LASTEXT and invaluement, but not enough to compensate for the
negative points.
I suspect it was a compromised freshdesk trial account that was
managed by amazonaws and sendgrid before passing through
smtp.freshdesk.com, both of which weren't whitelisted at the time.
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 6 Feb 2018, Kris Deugau wrote:
> Alex wrote:
>> These phishes we've received were all from otherwise trusted sources
>> like salesforce, amazonses and sendgrid. These are examples that I
>> believe were previously whitelisted because of having received a phish
>> through these systems but have no been disabled.
>>
>> whitelist_auth *@bounce.mail.salesforce.com
>> whitelist_auth *@sendgrid.net
>> whitelist_auth *@*.mcdlv.net
>
> I've seen enough spam sent through all three - both by way of whole
> apparently spammer-owned accounts and cracked-but-otherwise-legitimate
> accounts - that I would never blanket-whitelist whole bulk email providers.
>
> Legitimate mail sent through them generally gets through anyway IME.
An alternative is to use "def_whitelist_auth" instead of "whitelist_auth"
That gives a -7.5 point bump to usually good sources which may occasionally get
abused.
That way if one of their accounts gets p0wned your anti-phish rules have a
chance of pulling the junk into the spam-tagged range.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Kris Deugau <kd...@vianet.ca>.
Alex wrote:
> These phishes we've received were all from otherwise trusted sources
> like salesforce, amazonses and sendgrid. These are examples that I
> believe were previously whitelisted because of having received a phish
> through these systems but have no been disabled.
>
> whitelist_auth *@bounce.mail.salesforce.com
> whitelist_auth *@sendgrid.net
> whitelist_auth *@*.mcdlv.net
I've seen enough spam sent through all three - both by way of whole
apparently spammer-owned accounts and cracked-but-otherwise-legitimate
accounts - that I would never blanket-whitelist whole bulk email providers.
Legitimate mail sent through them generally gets through anyway IME.
-kgd
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David Jones <dj...@ena.com>.
On 02/06/2018 01:28 PM, Alex wrote:
> Hi,
>
>>>>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>>>>
>>>>>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>>>>> 'bb.barracudacentral.org')
>>>>>> tflags __RCVD_IN_BRBL net
>>>>>>
>>>>>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>>>>> '127.0.0.2')
>>>>>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
>>>>>> !RCVD_IN_BRBL_LASTEXT
>>>>>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>>>>> bb.barracudacentral.org
>>>>>> score RCVD_IN_BRBL 1.2
>>>>>> tflags RCVD_IN_BRBL net
>>>>>>
>>>>>> header RCVD_IN_BRBL_LASTEXT
>>>>>> eval:check_rbl('brbl-lastexternal',
>>>>>> 'bb.barracudacentral.org')
>>>>>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>>>>> Barracuda
>>>>>> RBL bb.barracudacentral.org
>>>>>> score RCVD_IN_BRBL_LASTEXT 2.2
>>>>>> tflags RCVD_IN_BRBL_LASTEXT net
>>>>>>
>>>>>> endif
>>>>>
>>>>>
>>>>>
>>>>> You don't think these scores are a bit high for a normal installation?
>>>>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>>>>> RCVD_IN_BRBL doesn't otherwise exist.
>>>>>
>>>>> Also, does someone have a recommended score for the lashback RBL? I've
>>>>> had it in testing for quite some time and would like to put it into
>>>>> production with reasonable values...
>>>>>
>>>>
>>>> Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged so
>>>> I
>>>> have learned my lesson. :) This works in my highly customized SA
>>>> platform
>>>> where I have to do outbound mail filtering so deep Received header
>>>> checking
>>>> is valuable to block spam from my customer's compromised accounts.
>>>>
>>>> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
>>>> score to 1.4 to keep things the same.
>>>
>>>
>>> I didn't mean to imply I don't agree or otherwise support your
>>> approach. It was just unclear that this was in conjunction with that
>>> approach of using higher spam rule scores to offset lower ham rule
>>> scores or if it was recommended for everyone.
>>>
>>> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
>>> and while I've implemented much of your approach, I can't implement
>>> all of it. My users raise holy hell when they receive even one phish
>>> from an otherwise trustworthy source that's been whitelisted. It hits
>>> on a ton of email at both ends of the spectrum - most are either very
>>> low scoring or are already spam.
>>>
>>
>> First let me say that my method for many whitelist_auth entries does not
>> allow for any phishing emails so if I find any of those, they do not get a
>> whitelist_auth entry. With a properly tuned MTA in front of SA, the only
>> phishing or blatant spam should be coming from compromised accounts or
>> zero-hour spam which are going to be difficult to block anyway.
>
> Yes, I should have mentioned that as well. We're not whitelisting any
> end-user level accounts.
>
> These phishes we've received were all from otherwise trusted sources
> like salesforce, amazonses and sendgrid. These are examples that I
> believe were previously whitelisted because of having received a phish
> through these systems but have no been disabled.
>
> whitelist_auth *@bounce.mail.salesforce.com
> whitelist_auth *@sendgrid.net
> whitelist_auth *@*.mcdlv.net
>
I have never received phishing emails from trusted senders like those.
If I did, then they would not be considered a trusted sender. We have
received unsolicited junk emails from customers of theirs after someone
sold our email addresses to some so-called "double opt-in" email lists
that we never opted into. I have been reporting this abuse and those
rogue customers are immediately locked/blocked/disabled/etc. which helps
all of us. I have never received a malicious/infected/spoofing email
from those, just harmless junk email.
>> My method should only be whitelist_auth'ing system-generated/bulk emails
>> from reputable senders that handle abuse reports quickly and shouldn't match
>> compromised accounts and "freemail" domains. It will also match commonly
>> spoofed domains like fedex.com, ups.com, and banks to help block those
>> phishing emails.
>
> This also requires supporting rules that add significant points based
> on their name most simply, or other more complicated rules to catch
> more sophisticated phish attempts. Spammers hitting our systems are
> far more sophisticated than just using "UPS" in the subject or
> pretending to be from ups.com.
>
Sure. What I have found effective is to train your Bayes with all
spoofing emails so high BAYES rule hits will add points. The authentic
emails will score very low from the whitelist_auth entry. Add in some
custom regex rules in the subject and body for variations of
misspellings of the spoofed brand or new zero-hour findings and this is
the best protection I have been able to come up with for new
spoofing/spam campaigns.
>>> Can I also ask again about reasonable RCVD_IN_LASHBACK and
>>> RCVD_IN_LASHBACK_LASTEXT scores?
>>>
>>
>> It really depends on how much customization you have done to SA and how much
>> your mail flow can handle bumping up scores. If you do some log analysis
>> and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
>> accurate for your mail flow, then you can bump it up like I have to 2.2 and
>> 4.2 respectively.
>>
>> DISCLAIMER: I am not recommending this for everyone so no flaming. Set
>> these scores low and test for a few weeks or months to see how your mail
>> logs line up with real spam then increase the scores as you see fit. Again,
>> I do outbound mail filtering for my customers so the deep Received header
>> inspection is helpful to determine compromised accounts and keep my mail
>> servers off of RBLs.
>
> Are there any numbers available from anyone's masschecks?
>
> Thank you as always for your support.
>
The normal nightly masschecks for rule promotions are run against stock
SA and sandbox rules so they won't include local customized rules like
these.
Just grep your mail logs for hits on these rules and pull out the
scores. You can use perl or awk to get the average score. Another
option I have used is to find the emails that scored just below your
threshold by a point or two to see what would have been impacted/blocked
if you bumped up a particular score by a point or two.
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Posted by Alex <my...@gmail.com>.
Hi,
>>>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>>>
>>>>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>>>> 'bb.barracudacentral.org')
>>>>> tflags __RCVD_IN_BRBL net
>>>>>
>>>>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>>>> '127.0.0.2')
>>>>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
>>>>> !RCVD_IN_BRBL_LASTEXT
>>>>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>>>> bb.barracudacentral.org
>>>>> score RCVD_IN_BRBL 1.2
>>>>> tflags RCVD_IN_BRBL net
>>>>>
>>>>> header RCVD_IN_BRBL_LASTEXT
>>>>> eval:check_rbl('brbl-lastexternal',
>>>>> 'bb.barracudacentral.org')
>>>>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>>>> Barracuda
>>>>> RBL bb.barracudacentral.org
>>>>> score RCVD_IN_BRBL_LASTEXT 2.2
>>>>> tflags RCVD_IN_BRBL_LASTEXT net
>>>>>
>>>>> endif
>>>>
>>>>
>>>>
>>>> You don't think these scores are a bit high for a normal installation?
>>>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>>>> RCVD_IN_BRBL doesn't otherwise exist.
>>>>
>>>> Also, does someone have a recommended score for the lashback RBL? I've
>>>> had it in testing for quite some time and would like to put it into
>>>> production with reasonable values...
>>>>
>>>
>>> Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged so
>>> I
>>> have learned my lesson. :) This works in my highly customized SA
>>> platform
>>> where I have to do outbound mail filtering so deep Received header
>>> checking
>>> is valuable to block spam from my customer's compromised accounts.
>>>
>>> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
>>> score to 1.4 to keep things the same.
>>
>>
>> I didn't mean to imply I don't agree or otherwise support your
>> approach. It was just unclear that this was in conjunction with that
>> approach of using higher spam rule scores to offset lower ham rule
>> scores or if it was recommended for everyone.
>>
>> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
>> and while I've implemented much of your approach, I can't implement
>> all of it. My users raise holy hell when they receive even one phish
>> from an otherwise trustworthy source that's been whitelisted. It hits
>> on a ton of email at both ends of the spectrum - most are either very
>> low scoring or are already spam.
>>
>
> First let me say that my method for many whitelist_auth entries does not
> allow for any phishing emails so if I find any of those, they do not get a
> whitelist_auth entry. With a properly tuned MTA in front of SA, the only
> phishing or blatant spam should be coming from compromised accounts or
> zero-hour spam which are going to be difficult to block anyway.
Yes, I should have mentioned that as well. We're not whitelisting any
end-user level accounts.
These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.
whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net
> My method should only be whitelist_auth'ing system-generated/bulk emails
> from reputable senders that handle abuse reports quickly and shouldn't match
> compromised accounts and "freemail" domains. It will also match commonly
> spoofed domains like fedex.com, ups.com, and banks to help block those
> phishing emails.
This also requires supporting rules that add significant points based
on their name most simply, or other more complicated rules to catch
more sophisticated phish attempts. Spammers hitting our systems are
far more sophisticated than just using "UPS" in the subject or
pretending to be from ups.com.
>> Can I also ask again about reasonable RCVD_IN_LASHBACK and
>> RCVD_IN_LASHBACK_LASTEXT scores?
>>
>
> It really depends on how much customization you have done to SA and how much
> your mail flow can handle bumping up scores. If you do some log analysis
> and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
> accurate for your mail flow, then you can bump it up like I have to 2.2 and
> 4.2 respectively.
>
> DISCLAIMER: I am not recommending this for everyone so no flaming. Set
> these scores low and test for a few weeks or months to see how your mail
> logs line up with real spam then increase the scores as you see fit. Again,
> I do outbound mail filtering for my customers so the deep Received header
> inspection is helpful to determine compromised accounts and keep my mail
> servers off of RBLs.
Are there any numbers available from anyone's masschecks?
Thank you as always for your support.
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David Jones <dj...@ena.com>.
On 02/06/2018 10:38 AM, Alex wrote:
> Hi,
>
> On Tue, Feb 6, 2018 at 8:44 AM, David Jones <dj...@ena.com> wrote:
>> On 02/05/2018 09:07 PM, Alex wrote:
>>>
>>> Hi,
>>>
>>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>>
>>>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>>> 'bb.barracudacentral.org')
>>>> tflags __RCVD_IN_BRBL net
>>>>
>>>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>>> '127.0.0.2')
>>>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>>>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>>> bb.barracudacentral.org
>>>> score RCVD_IN_BRBL 1.2
>>>> tflags RCVD_IN_BRBL net
>>>>
>>>> header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
>>>> 'bb.barracudacentral.org')
>>>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>>> Barracuda
>>>> RBL bb.barracudacentral.org
>>>> score RCVD_IN_BRBL_LASTEXT 2.2
>>>> tflags RCVD_IN_BRBL_LASTEXT net
>>>>
>>>> endif
>>>
>>>
>>> You don't think these scores are a bit high for a normal installation?
>>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>>> RCVD_IN_BRBL doesn't otherwise exist.
>>>
>>> Also, does someone have a recommended score for the lashback RBL? I've
>>> had it in testing for quite some time and would like to put it into
>>> production with reasonable values...
>>>
>>
>> Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged so I
>> have learned my lesson. :) This works in my highly customized SA platform
>> where I have to do outbound mail filtering so deep Received header checking
>> is valuable to block spam from my customer's compromised accounts.
>>
>> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
>> score to 1.4 to keep things the same.
>
> I didn't mean to imply I don't agree or otherwise support your
> approach. It was just unclear that this was in conjunction with that
> approach of using higher spam rule scores to offset lower ham rule
> scores or if it was recommended for everyone.
>
> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
> and while I've implemented much of your approach, I can't implement
> all of it. My users raise holy hell when they receive even one phish
> from an otherwise trustworthy source that's been whitelisted. It hits
> on a ton of email at both ends of the spectrum - most are either very
> low scoring or are already spam.
>
First let me say that my method for many whitelist_auth entries does not
allow for any phishing emails so if I find any of those, they do not get
a whitelist_auth entry. With a properly tuned MTA in front of SA, the
only phishing or blatant spam should be coming from compromised accounts
or zero-hour spam which are going to be difficult to block anyway.
My method should only be whitelist_auth'ing system-generated/bulk emails
from reputable senders that handle abuse reports quickly and shouldn't
match compromised accounts and "freemail" domains. It will also match
commonly spoofed domains like fedex.com, ups.com, and banks to help
block those phishing emails.
> Can I also ask again about reasonable RCVD_IN_LASHBACK and
> RCVD_IN_LASHBACK_LASTEXT scores?
>
It really depends on how much customization you have done to SA and how
much your mail flow can handle bumping up scores. If you do some log
analysis and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are
pretty accurate for your mail flow, then you can bump it up like I have
to 2.2 and 4.2 respectively.
DISCLAIMER: I am not recommending this for everyone so no flaming. Set
these scores low and test for a few weeks or months to see how your mail
logs line up with real spam then increase the scores as you see fit.
Again, I do outbound mail filtering for my customers so the deep
Received header inspection is helpful to determine compromised accounts
and keep my mail servers off of RBLs.
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_LASHBACK eval:check_rbl('lashback', 'ubl.unsubscore.com.')
describe __RCVD_IN_LASHBACK Received is listed in Lashback
ubl.unsubscore.com
tflags __RCVD_IN_LASHBACK net
header __RCVD_IN_LASHBACK_2 eval:check_rbl_sub('lashback', '127.0.0.2')
meta RCVD_IN_LASHBACK __RCVD_IN_LASHBACK_2 && !RCVD_IN_LASHBACK_LASTEXT
describe RCVD_IN_LASHBACK Received is listed in Lashback ubl.unsubscore.com
score RCVD_IN_LASHBACK 2.2
tflags RCVD_IN_LASHBACK net
header RCVD_IN_LASHBACK_LASTEXT eval:check_rbl('lashback-lastexternal',
'ubl.unsubscore.com.')
describe RCVD_IN_LASHBACK_LASTEXT Last external is listed in Lashback
ubl.unsubscore.com
score RCVD_IN_LASHBACK_LASTEXT 4.2
tflags RCVD_IN_LASHBACK_LASTEXT net
endif
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by RW <rw...@googlemail.com>.
On Tue, 6 Feb 2018 11:38:42 -0500
Alex wrote:
> On Tue, Feb 6, 2018 at 8:44 AM, David Jones <dj...@ena.com> wrote:
ustomer's compromised accounts.
> >
> > Leave out the RCVD_IN_BRBL rule above and change the
> > RCVD_IN_BRBL_LASTEXT score to 1.4 to keep things the same.
>
> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
> and while I've implemented much of your approach, I can't implement
> all of it.
I've been doing deep XBL checks for years (they come free with the zen
look-ups). Initially I found that they did have a low FP rate, but
that's changed as more of my mail comes through mobile (cellular)
networks that use NAT to support millions of users on thousands of IPv4
addresses. I'm seeing about 10% of ham submitted from these networks
hitting my deep XBL rule.
> Can I also ask again about reasonable RCVD_IN_LASHBACK and
> RCVD_IN_LASHBACK_LASTEXT scores?
If you're going to create deep versions of more than one list it doesn't
make sense to score them individually. The dominant cause of FPs on such
rules is dynamic IP address reuse, being in more than one list
doesn't say anything about that. Allowing a large score to build-up
from multiple deep rules is reckless.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Posted by Alex <my...@gmail.com>.
Hi,
On Tue, Feb 6, 2018 at 8:44 AM, David Jones <dj...@ena.com> wrote:
> On 02/05/2018 09:07 PM, Alex wrote:
>>
>> Hi,
>>
>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>
>>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>> 'bb.barracudacentral.org')
>>> tflags __RCVD_IN_BRBL net
>>>
>>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>> '127.0.0.2')
>>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>> bb.barracudacentral.org
>>> score RCVD_IN_BRBL 1.2
>>> tflags RCVD_IN_BRBL net
>>>
>>> header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
>>> 'bb.barracudacentral.org')
>>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>> Barracuda
>>> RBL bb.barracudacentral.org
>>> score RCVD_IN_BRBL_LASTEXT 2.2
>>> tflags RCVD_IN_BRBL_LASTEXT net
>>>
>>> endif
>>
>>
>> You don't think these scores are a bit high for a normal installation?
>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>> RCVD_IN_BRBL doesn't otherwise exist.
>>
>> Also, does someone have a recommended score for the lashback RBL? I've
>> had it in testing for quite some time and would like to put it into
>> production with reasonable values...
>>
>
> Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged so I
> have learned my lesson. :) This works in my highly customized SA platform
> where I have to do outbound mail filtering so deep Received header checking
> is valuable to block spam from my customer's compromised accounts.
>
> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
> score to 1.4 to keep things the same.
I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.
If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.
Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David Jones <dj...@ena.com>.
On 02/05/2018 09:07 PM, Alex wrote:
> Hi,
>
>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>
>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>> 'bb.barracudacentral.org')
>> tflags __RCVD_IN_BRBL net
>>
>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>> '127.0.0.2')
>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>> bb.barracudacentral.org
>> score RCVD_IN_BRBL 1.2
>> tflags RCVD_IN_BRBL net
>>
>> header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
>> 'bb.barracudacentral.org')
>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in Barracuda
>> RBL bb.barracudacentral.org
>> score RCVD_IN_BRBL_LASTEXT 2.2
>> tflags RCVD_IN_BRBL_LASTEXT net
>>
>> endif
>
> You don't think these scores are a bit high for a normal installation?
> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
> RCVD_IN_BRBL doesn't otherwise exist.
>
> Also, does someone have a recommended score for the lashback RBL? I've
> had it in testing for quite some time and would like to put it into
> production with reasonable values...
>
Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged
so I have learned my lesson. :) This works in my highly customized SA
platform where I have to do outbound mail filtering so deep Received
header checking is valuable to block spam from my customer's compromised
accounts.
Leave out the RCVD_IN_BRBL rule above and change the
RCVD_IN_BRBL_LASTEXT score to 1.4 to keep things the same.
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Posted by Alex <my...@gmail.com>.
Hi,
> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>
> header __RCVD_IN_BRBL eval:check_rbl('brbl',
> 'bb.barracudacentral.org')
> tflags __RCVD_IN_BRBL net
>
> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
> '127.0.0.2')
> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
> bb.barracudacentral.org
> score RCVD_IN_BRBL 1.2
> tflags RCVD_IN_BRBL net
>
> header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
> 'bb.barracudacentral.org')
> describe RCVD_IN_BRBL_LASTEXT Last external is listed in Barracuda
> RBL bb.barracudacentral.org
> score RCVD_IN_BRBL_LASTEXT 2.2
> tflags RCVD_IN_BRBL_LASTEXT net
>
> endif
You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.
Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Benny Pedersen <me...@junc.eu>.
David Jones skrev den 2018-02-05 16:36:
> If you are running a local DNS cache like this list and the SA
> documention recommends, does this really matter? My MTA should have
> already queried this before SA does it so it should be in the local
> DNS cache and not require a full recursive lookup from the SA rule
> above.
yes it matters with low ttl, non datafeeds have low ttl, so it does not
cache much on dns servers, sadly, this can be avoided in spamassassin
without 2 dns querys
it have always just be low priotet since we all assume datafedds where
is does not matter
> This shouldn't be the case with a local DNS cache with the
> /etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to
> 127.0.0.1.
already done here
>> can lastexternal be solved to only use one query ?
>> as is i think spamassassin should be changed so it can if not already
on top of that bb. is for spamassassin, while b. was for mta stage, so
200% more querys to non datafeeds :/
it should have being one dns zone
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by RW <rw...@googlemail.com>.
On Mon, 05 Feb 2018 17:12:08 +0100
Benny Pedersen wrote:
> Kevin A. McGrail skrev den 2018-02-05 16:53:
>
> > I don't think that will apply will it because it will be looking up
> > something like 1.2.3.4.bb.barracuda.blah which isn't cached.
>
> the first qurry can make a qurry with very low ttl, so it would not
> be cached, that means number 2 query still mkae dns query to that
> zone :(
SA sends its DNS requests out early in rapid succession. The chances
are that the local DNS cache would see the second request as a
duplicate of a pending look-up. In that case caching is not needed.
> > Anyway, we're debating a rule that's removed :)
> lastexternal is still a mistake imho :=)
lastexternal is correct, that's what RCVD_IN_BRBL_LASTEXT does. Making
use of deep checks on lists containing dynamic addresses is risky, and
likely to vary a lot between different mail flows.
David's rules are not appropriate as a general replacement for
RCVD_IN_BRBL_LASTEXT IMO.
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Benny Pedersen <me...@junc.eu>.
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: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Dave Warren <dw...@thedave.ca>.
On 2018-02-05 09:12, Benny Pedersen wrote:
> Kevin A. McGrail skrev den 2018-02-05 16:53:
>
>> I don't think that will apply will it because it will be looking up
>> something like 1.2.3.4.bb.barracuda.blah which isn't cached.
>
> the first qurry can make a qurry with very low ttl, so it would not be
> cached, that means number 2 query still mkae dns query to that zone :(
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).
;; ANSWER SECTION:
2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2
Maybe the TTLs are different for other records?
I am also noticing very intermittent response times, sometimes taking
over a second to get a response, other times taking under 50ms.
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Benny Pedersen <me...@junc.eu>.
Kevin A. McGrail skrev den 2018-02-05 16:53:
> I don't think that will apply will it because it will be looking up
> something like 1.2.3.4.bb.barracuda.blah which isn't cached.
the first qurry can make a qurry with very low ttl, so it would not be
cached, that means number 2 query still mkae dns query to that zone :(
> Anyway, we're debating a rule that's removed :)
lastexternal is still a mistake imho :=)
gosh i hate bind9 not have minimal ttl, good thing is that low ttl
strikes back to badly configured dns zones :=)
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 2/5/2018 10:36 AM, David Jones wrote:
> If you are running a local DNS cache like this list and the SA
> documention recommends, does this really matter? My MTA should have
> already queried this before SA does it so it should be in the local
> DNS cache and not require a full recursive lookup from the SA rule above.
I don't think that will apply will it because it will be looking up
something like 1.2.3.4.bb.barracuda.blah which isn't cached.
Anyway, we're debating a rule that's removed :)
Regards,
KAM
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David Jones <dj...@ena.com>.
On 02/05/2018 09:44 AM, Reindl Harald wrote:
>
> Am 05.02.2018 um 16:36 schrieb David Jones:
>> On 02/05/2018 09:26 AM, Benny Pedersen wrote:
>>> David Jones skrev den 2018-02-05 15:09:
>>>
>>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>>
>>>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>>> 'bb.barracudacentral.org')
>>>> tflags __RCVD_IN_BRBL net
>>>>
>>>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>>> '127.0.0.2')
>>>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
>>>> !RCVD_IN_BRBL_LASTEXT
>>>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>>> bb.barracudacentral.org
>>>> score RCVD_IN_BRBL 1.2
>>>> tflags RCVD_IN_BRBL net
>>>>
>>>> header RCVD_IN_BRBL_LASTEXT
>>>> eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
>>>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>>> Barracuda RBL bb.barracudacentral.org
>>>> score RCVD_IN_BRBL_LASTEXT 2.2
>>>> tflags RCVD_IN_BRBL_LASTEXT net
>>>>
>>>> endif
>>>
>>> this rule makes 2 dns querys, waste of cpu performance, i would
>>> suggest to drop the lastextnal, so its only if ip is listed yes or
>>> no, 50% dns querys saved, and still same hits on listed ips, why do
>>> we need to help spammers ?
>>
>> If you are running a local DNS cache like this list and the SA
>> documention recommends, does this really matter? My MTA should have
>> already queried this before SA does it so it should be in the local
>> DNS cache and not require a full recursive lookup from the SA rule above
>
> 1.2 poitns just because the IP of the previous hop is listet is pure
> nonsense and it was even nosense as Barracuda Networks started with that
> bullshit called "deep header inspection"
>
> Barracuda and many other RBL's list here a ton of innocent IP's which
> are nothing else than the endusers range which never should tocu an
> inbound MX itself
>
> so what the hell is the point that you give me 1.2 points because i use
> as i should our MTA from my home-ip to send an ordianry mail?
It can be a sign of a compromised account. I just saw a compromised
account coming from Nigeria listed on BRBL through Office 365. Now that
O365 is finally adding the "x-originating-ip" header, we can detect
botnets sending via infected home computers.
Legit emails should have other rules subtracting points so a 1.2 should
not be a major factor in the score. My mail platform is scoring real
spam greater than 18 and usually in the 20's. I could leave this rule
out and be fine but most default SA instances would benefit from it. If
they want to lower the scores, then make them 0.2 and 1.2 then and use
them in meta rules.
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by David Jones <dj...@ena.com>.
On 02/05/2018 09:26 AM, Benny Pedersen wrote:
> David Jones skrev den 2018-02-05 15:09:
>
>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>
>> header __RCVD_IN_BRBL eval:check_rbl('brbl',
>> 'bb.barracudacentral.org')
>> tflags __RCVD_IN_BRBL net
>>
>> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>> '127.0.0.2')
>> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>> bb.barracudacentral.org
>> score RCVD_IN_BRBL 1.2
>> tflags RCVD_IN_BRBL net
>>
>> header RCVD_IN_BRBL_LASTEXT
>> eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
>> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>> Barracuda RBL bb.barracudacentral.org
>> score RCVD_IN_BRBL_LASTEXT 2.2
>> tflags RCVD_IN_BRBL_LASTEXT net
>>
>> endif
>
> this rule makes 2 dns querys, waste of cpu performance, i would suggest
> to drop the lastextnal, so its only if ip is listed yes or no, 50% dns
> querys saved, and still same hits on listed ips, why do we need to help
> spammers ?
>
If you are running a local DNS cache like this list and the SA
documention recommends, does this really matter? My MTA should have
already queried this before SA does it so it should be in the local DNS
cache and not require a full recursive lookup from the SA rule above.
> anyway i dont use it, above rule is only optimized for datafeeds, it
> will drain non datafeed clients into hell
>
This shouldn't be the case with a local DNS cache with the
/etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to 127.0.0.1.
> can lastexternal be solved to only use one query ?
>
> as is i think spamassassin should be changed so it can if not already
--
David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>David Jones skrev den 2018-02-05 15:09:
>
>>ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>
>>header __RCVD_IN_BRBL eval:check_rbl('brbl',
>>'bb.barracudacentral.org')
>>tflags __RCVD_IN_BRBL net
>>
>>header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
>>'127.0.0.2')
>>meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
>>!RCVD_IN_BRBL_LASTEXT
>>describe RCVD_IN_BRBL Received is listed in Barracuda RBL
>>bb.barracudacentral.org
>>score RCVD_IN_BRBL 1.2
>>tflags RCVD_IN_BRBL net
>>
>>header RCVD_IN_BRBL_LASTEXT
>>eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
>>describe RCVD_IN_BRBL_LASTEXT Last external is listed in
>>Barracuda RBL bb.barracudacentral.org
>>score RCVD_IN_BRBL_LASTEXT 2.2
>>tflags RCVD_IN_BRBL_LASTEXT net
>>
>>endif
On 05.02.18 16:26, Benny Pedersen wrote:
>this rule makes 2 dns querys, waste of cpu performance, i would
>suggest to drop the lastextnal,
this rule checks all untrusted IPs, while lastexternal uses only one (often
the most important - IP that sent mail to your systems).
also, because of caching, brbl-lastexternal result will be cached.
b.barracudacentral.org uses ttl of 300, which should be cached during the
mail processing.
if you want to spare DNS queries, leave only lastexternal.
> so its only if ip is listed yes or
>no, 50% dns querys saved, and still same hits on listed ips, why do
>we need to help spammers ?
network checks including DNS lookups help much in spam processing, after
bayes they are second best mechanism to detect spam.
NOT using them is helping spammers.
--
Matus UHLAR - fantomas, uhlar@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.
Atheism is a non-prophet organization.
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by Benny Pedersen <me...@junc.eu>.
David Jones skrev den 2018-02-05 15:09:
> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>
> header __RCVD_IN_BRBL eval:check_rbl('brbl',
> 'bb.barracudacentral.org')
> tflags __RCVD_IN_BRBL net
>
> header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
> '127.0.0.2')
> meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
> !RCVD_IN_BRBL_LASTEXT
> describe RCVD_IN_BRBL Received is listed in Barracuda RBL
> bb.barracudacentral.org
> score RCVD_IN_BRBL 1.2
> tflags RCVD_IN_BRBL net
>
> header RCVD_IN_BRBL_LASTEXT
> eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
> describe RCVD_IN_BRBL_LASTEXT Last external is listed in
> Barracuda RBL bb.barracudacentral.org
> score RCVD_IN_BRBL_LASTEXT 2.2
> tflags RCVD_IN_BRBL_LASTEXT net
>
> endif
this rule makes 2 dns querys, waste of cpu performance, i would suggest
to drop the lastextnal, so its only if ip is listed yes or no, 50% dns
querys saved, and still same hits on listed ips, why do we need to help
spammers ?
anyway i dont use it, above rule is only optimized for datafeeds, it
will drain non datafeed clients into hell
can lastexternal be solved to only use one query ?
as is i think spamassassin should be changed so it can if not already
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 2/5/2018 11:32 AM, RW wrote:
> Just to clarify, there is no legal or moral obligation to do this, the
> 'bb' subdomain was created specifically so SA users wouldn't need to
> register. Anything you may read on the Barracuda site applies to the
> 'b' version. Barracuda has given no indication that anything has
> changed.
I've been trying to reach Barracuda pretty doggedly about the issue for
months about the issues with bb requiring registration hence the
removal. If you have a contact, get in touch with them and we can
relight the rule. I was hoping some discussion on list might get their
attention.
Regards,
KAM
Re: Barracuda Reputation Block List (BRBL) removal from the SA
ruleset
Posted by RW <rw...@googlemail.com>.
On Mon, 5 Feb 2018 08:09:55 -0600
David Jones wrote:
> Heads up! This RBL has been removed from the core SA ruleset. In 36
> to 48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after
> it has gone through the masscheck and rule promotion process.
>
> Details can be found here:
>
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417
>
> To add this rule back manually, you should register here:
>
> http://barracudacentral.org/account/register
Just to clarify, there is no legal or moral obligation to do this, the
'bb' subdomain was created specifically so SA users wouldn't need to
register. Anything you may read on the Barracuda site applies to the
'b' version. Barracuda has given no indication that anything has
changed.
The issue is that some users have seen look-ups fail and attributed it
to possible rate limiting on non-registered IP addresses.
You should register if you use the 'b' list directly from an MTA. If
you only run the 'bb' version from SA and use fixed IP addresses it
*may* help with reliability if you register. If you run SA client side
on a dynamic address there's no point in registering.
> and add this to your local.cf:
I would suggest people just copy the existing rule as it is. This list
contains dynamic IP addresses so shouldn't be used for deep look-ups.
> NOTE: recent masscheck processing shows RCVD_IN_BRBL_LASTEXT as the
> most effective non-zero scoring rule to hit spam (43%) so it's
> probably worth adding back to your local.cf on Wednesday or Thursday.
If you don't rename the rule there's no need to wait.
Note that once it's removed the scores for other rules will adjust to
compensate for its absence, and this *may* lead to more FP's if it's
left at its current score.