Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

Said the blind person...

Sent from ProtonMail Mobile

On Tue, Feb 13, 2018 at 21:03, @lbutlr  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

[@lbutlr]

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...

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

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  
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

[Groach]

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


Sent from ProtonMail Mobile




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


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

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



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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

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

Sent from ProtonMail Mobile

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

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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

You are wrong. Read again.

Sent from ProtonMail Mobile

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

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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

You confuse the press with the author.

Sent from ProtonMail Mobile

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

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

Re: Email filtering theory and the definition of spam

[Antony Stone]

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

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

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

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


Antony.

-- 
This sentence contains exacly three erors.

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

Re: Email filtering theory and the definition of spam

[Bill Cole]

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

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

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


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


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

Re: Email filtering theory and the definition of spam

[@lbutlr]

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

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

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


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

Category: Standards Track

-- 
Penny! *Everything* is better with BlueTooth

Re: Email filtering theory and the definition of spam

[Antony Stone]

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

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

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

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

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

> Rfc 2822, *proposed standard*: usa

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

> Rfc 5321, *draft standard*: usa

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

> Rfc 5322, *draft standard*: usa

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

> ...
> 
> The list goes on.

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

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

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


Antony.

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

 - Douglas Noel Adams

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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

Who is the ignorant here?

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

The list goes on.

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

Sent from ProtonMail Mobile

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

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

Re: Email filtering theory and the definition of spam

[@lbutlr]

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

Not actually interesting to me, no.

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

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

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

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

Re: Email filtering theory and the definition of spam

[Antony Stone]

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

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

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

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


Antony.

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

The tin opener was not invented until 1858.

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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

> 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

[Rupert Gallagher]

Interesting to kreme.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 03:14, Benny Pedersen  wrote:

> Rupert Gallagher skrev den 2018-02-10 23:26: > Interesting... how ? > > 
> Final-Recipient: rfc822; krem...@kreme.com > Original-Recipient: 
> rfc822;krem...@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

[Rupert Gallagher]

I am not protonmail.

Sent from ProtonMail Mobile

On Sun, Feb 11, 2018 at 03:12, Benny Pedersen  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

[Rupert Gallagher]

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  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

[@lbutlr]

On 2018-02-10 (15:26 MST), Rupert Gallagher  wrote:
> 
> Interesting... 
> 
> 
> Final-Recipient: rfc822; krem...@kreme.com
> Original-Recipient: rfc822;krem...@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

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

[@lbutlr]

On 2018-02-10 (12:07 MST), Joseph Brennan  wrote:
> 
> --On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr"  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

[Benny Pedersen]

Rupert Gallagher skrev den 2018-02-10 23:26:

Interesting...


how ?



Final-Recipient: rfc822; krem...@kreme.com
Original-Recipient: rfc822;krem...@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

[Benny Pedersen]

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

[Rupert Gallagher]

Interesting...

Final-Recipient: rfc822; krem...@kreme.com
Original-Recipient: rfc822;krem...@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

...

>

Re: Email filtering theory and the definition of spam

[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.

Sent from ProtonMail Mobile

On Sat, Feb 10, 2018 at 18:04, @lbutlr  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

[Bill Cole]

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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Email filtering theory and the definition of spam

[Alex]

Hi,

On Sat, Feb 10, 2018 at 12:04 PM, @lbutlr  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".

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

[Joseph Brennan]

--On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr"  
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

[@lbutlr]

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

Re: Email filtering theory and the definition of spam

[Rupert Gallagher]

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  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

[@lbutlr]

On 2018-02-09 (14:26 MST), Joseph Brennan  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

[Joseph Brennan]

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

[@lbutlr]

On 2018-02-08 (08:23 MST), David Jones  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

[Rupert Gallagher]

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  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

[jdow]

On 20180208 23:24, Reindl Harald wrote:



Am 09.02.2018 um 01:20 schrieb jdow:

On 20180208 07:23, David Jones wrote:

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

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

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


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


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


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


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


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


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


*lol* who supervises the companies?


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


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


{^_^}

Re: Email filtering theory and the definition of spam

[jdow]

On 20180208 07:23, David Jones wrote:

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

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

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


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


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



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


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


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


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


{^_^}

Re: Email filtering theory and the definition of spam

[Martin Gregorie]

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

[Paul Stead]

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"  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

[Tom Hendrikx]

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



signature.asc
Description: OpenPGP digital signature

Re: Email filtering theory and the definition of spam

[Giovanni Bechis]

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

[David Jones]

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

[LuKreme]

On Feb 7, 2018, at 06:17, David Jones  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

[Dave Warren]

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

[Martin Gregorie]

> 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

[David Jones]

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

[Rupert Gallagher]

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.  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

[jdow]

On 20180206 16:56, Miles Fidelman wrote:



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


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


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

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

I think that it still holds up.



Not bad at all.  Actually, quite good!

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


Miles Fidelman


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

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


{^_-}   Joanne

Re: Email filtering theory and the definition of spam

[Miles Fidelman]

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

[Anne P. Mitchell Esq.]

 
> 
> 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

[David Jones]

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