Re: [mailop] Junk filtering as a tool for unfair competition

[Brandon Long via mailop]

On Thu, Oct 24, 2019 at 3:22 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 24.10.2019 o godz. 15:03:25 Jay Hennigan via mailop pisze:
> >
> > If a message contains malware, it is almost certainly also spam.
>
> Yes, but it's better to have two separate tools - one specialized in
> detecting malware, that does it with high accuracy, and the other a
> general-purpose spam filter (which can pass through some spam) - than try
> to
> fit everything in one tool.
>
> That's why you usually have both antivirus/anti-malware scanners AND
> generic spam filters on a mail host. Even if a spam filter happens to pass
> the message containing malware, AV scanner usually catches it, as it is
> specialized to do that particular task only.
>
> If the malware is not attached directly to email, but needs to be
> downloaded
> from a link included in the message, then we have an UTM on the way which
> should block the download attempt.
>
> And if everything else fails, there is anti-malware software running
> directly on end-users computer.
>
> Antispam filter isn't supposed to do everything... :)
>

There have been constantly mutating viruses in the wild for years now where
almost every copy is
unique (ish) involving bad payloads in overly permissive file formats
(office, pdf, etc), not to mention
various spear phishing payloads for the same.  Getting ahead of those
involves combining more typical
spam features with content features and then doing something ridiculously
expensive like opening the
document on a virtual windows box.  Combining those features allows you to
do this and take the processing/delay
hit only on the most likely messages.

Also, you may have noticed that spear phishing messages helped change the
outcome of the last US Presidential
election, not to mention wiping every Windows computer/server in various
organizations across the world,
industrial espionage theft on a massive scale, etc.

I mean, sure, we invest more resources in protecting enterprise accounts
than consumer ones, but your assumptions
of the risk environment or how these modern systems work is woefully naive.

Yahoo went p=reject on yahoo.com because phishing messages had caused their
customer support operations to handle
an increased load to the tune of at least tens of millions of dollars in
support costs.  Heck, Google started the internal precursor to DMARC
due to fraudulent AdWords activity costing our customers at least that much
money a quarter.  And that's not even counting
the money that people have lost mistakenly falling for various "mugged in
London" type scams or the current favorite of
DoSing a user's inbox so they don't notice the real notification messages
of money stolen from their Paypal or whatever
account.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jaroslaw Rafa via mailop]

Dnia 24.10.2019 o godz. 15:03:25 Jay Hennigan via mailop pisze:
> 
> If a message contains malware, it is almost certainly also spam.

Yes, but it's better to have two separate tools - one specialized in
detecting malware, that does it with high accuracy, and the other a
general-purpose spam filter (which can pass through some spam) - than try to
fit everything in one tool.

That's why you usually have both antivirus/anti-malware scanners AND
generic spam filters on a mail host. Even if a spam filter happens to pass
the message containing malware, AV scanner usually catches it, as it is
specialized to do that particular task only.

If the malware is not attached directly to email, but needs to be downloaded
from a link included in the message, then we have an UTM on the way which
should block the download attempt.

And if everything else fails, there is anti-malware software running
directly on end-users computer.

Antispam filter isn't supposed to do everything... :)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Scott Southard via mailop]

>
> And what does the user install if it's not a file?
>

I think the idea here is that a phishing attack is just as straightforward
a path to installing malware as an email containing malware. Which I
completely agree with. Spam filtering has to work in tandem with AV, and
suggesting that there's a simple solution for any of these is reckless and
scary.

On Thu, Oct 24, 2019 at 5:08 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 24.10.2019 o godz. 16:51:41 Michael Rathbun via mailop pisze:
> >
> > What file would that have been?   "Causes to install" does not require a
> file
>
> And what does the user install if it's not a file?
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jay Hennigan via mailop]

On 10/24/19 14:22, Jaroslaw Rafa via mailop wrote:


Protecting against malware is not a spam filter's job; it's a UTM's
(firewall's, web proxy's or whatever you use to protect your network) job.


Email messages containing malware are unsolicited. They are bulk in most 
every case, and by definition they are email.


A spam filter's job is to filter out bulk, unsolicited email. Therefore, 
it is indeed a spam filter's job to filter out email messages containing 
malware. Are you making the claim that email containing malware is 
"legitimate"?


Malware delivered by malicious websites, on USB sticks, etc. is indeed a 
different problem.



Antispam filter is not a tool to protect against malware; there are another
tools to do that, that are able to identify mailicious content pretty well.
It is possible to determine whether a message contains actual malware with
much larger certainty than whether it is "spam" and there are basically no
problems with messages being mis-classified in this aspect. AV software is
pretty reliable.


If a message contains malware, it is almost certainly also spam. Not 
only is it spam, it is often sent from a compromised host to every 
string that looks like an email address on that host. This makes it 
trickier for the spam filter because the targets of the malware are 
likely to have the sender's email and/or IP address whitelisted.


It's not uncommon to have more than one lock on a door, and it's not 
uncommon to have more than one defense against malware. Spam filters are 
one such defense. It is far better to block the malware before it's 
sitting in a user's inbox on the target host than afterward.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jaroslaw Rafa via mailop]

Dnia 24.10.2019 o godz. 16:51:41 Michael Rathbun via mailop pisze:
> 
> What file would that have been?   "Causes to install" does not require a file

And what does the user install if it's not a file?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Michael Rathbun via mailop]

On Thu, 24 Oct 2019 23:48:30 +0200, Jaroslaw Rafa  wrote:

>I understand it was a 0-day and AV software didn't know it? Of course I
>don't know what that particular kind of malware was, but maybe heuristic
>tools like DeepInstinct, that try to analyze what a file *actually does*
>before allowing it to run, might have caught it.

What file would that have been?   "Causes to install" does not require a file

mdr
-- 
I regret that I have but one * for my country.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jaroslaw Rafa via mailop]

Dnia 24.10.2019 o godz. 16:35:50 Michael Rathbun via mailop pisze:
> 
> No anti-malware facility yet devised would have protected my Brazilian client
> from one particular attack, because there was absolutely no indication of any
> sort that a compromise was intended by a particular message, which looked for
> all the world like the stuff the finance department received every day.  Some
> rather nerdy and introspective anti-spam rules nabbed it.

I understand it was a 0-day and AV software didn't know it? Of course I
don't know what that particular kind of malware was, but maybe heuristic
tools like DeepInstinct, that try to analyze what a file *actually does*
before allowing it to run, might have caught it.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Michael Rathbun via mailop]

On Thu, 24 Oct 2019 23:22:59 +0200, Jaroslaw Rafa via mailop
 wrote:

>Dnia 24.10.2019 o godz. 15:11:23 Kelly Molloy via mailop pisze:
>> 
>> Yes, it certainly can be. If an email causes a user to install
>> ransomware on a corporate network, then it is an enormous and
>> expensive problem; it's put companies out of business. If a phishing
>> message means that an company gets infected with malware, the
>> remediation is hugely expensive.
>
>Protecting against malware is not a spam filter's job...


You may have failed to notice Kelly's wording:  "causes a user to install".

No anti-malware facility yet devised would have protected my Brazilian client
from one particular attack, because there was absolutely no indication of any
sort that a compromise was intended by a particular message, which looked for
all the world like the stuff the finance department received every day.  Some
rather nerdy and introspective anti-spam rules nabbed it.

mdr
-- 
  The world was almost won by such an ape!
The nations put him where his kind belong.
  But do not rejoice too soon at your escape.
The womb he crawled from is still going strong.
-- Bertold Brecht,"The Resistible Rise of Arturo UI"


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Barracuda RBL delisting form broken?

[Sadiq Saif via mailop]

Hi all,

The Barracuda RBL delisting form appears to be broken, I have been trying to 
delist an IP for $WORK for a week or so now and I don't get any confirmation 
e-mail from them. We have tried multiple addresses, no luck. Normally, we get a 
confirmation e-mail from them shortly after we submit the form.

Is anyone else having trouble with getting IPs delisted from Barracuda or am I 
missing something here?

-- 
Sadiq Saif
https://sadiqsaif.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jaroslaw Rafa via mailop]

Dnia 24.10.2019 o godz. 15:11:23 Kelly Molloy via mailop pisze:
> 
> Yes, it certainly can be. If an email causes a user to install
> ransomware on a corporate network, then it is an enormous and
> expensive problem; it's put companies out of business. If a phishing
> message means that an company gets infected with malware, the
> remediation is hugely expensive.

Protecting against malware is not a spam filter's job; it's a UTM's
(firewall's, web proxy's or whatever you use to protect your network) job.
Malware is best blocked at download; of course, if some links are identified
as pointing to malware, you may block emails containing links to it (URIBLs
do pretty good job at it, without the need to wild-guess), but it's a second
line of defense, just for convenience. The UTM should block the download of
a mailicious file anyway.

Antispam filter is not a tool to protect against malware; there are another
tools to do that, that are able to identify mailicious content pretty well.
It is possible to determine whether a message contains actual malware with
much larger certainty than whether it is "spam" and there are basically no
problems with messages being mis-classified in this aspect. AV software is
pretty reliable.

Additionally, a corporate environment is quite different from
general-purpose email service. Corporate email accounts are generally for
internal use; you could put much stronger restrictions on them as on a
generic email account. You could basically even block all senders from
outside the company except the ones you are regularly cooperating with. 
Only a handful of recipients (especially the employees who are handling
inquiries from potential new customers) woluld be able to receive mail from
"any" sender. All this does not apply for an "ordinary" user.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Kelly Molloy via mailop]

On Thu, Oct 24, 2019 at 6:22 AM Jaroslaw Rafa via mailop
 wrote:

> But even if one such message goes through, is this really a problem?

Yes, it certainly can be. If an email causes a user to install
ransomware on a corporate network, then it is an enormous and
expensive problem; it's put companies out of business. If a phishing
message means that an company gets infected with malware, the
remediation is hugely expensive. A neighbor of mine just missed a
paycheck when the small business he works for got an email giving the
payroll clerk a new routing number. It looked just like the legit
emails she gets from the processor, so she transferred the money to
some guy in Indonesia. They filed a report with the FBI, but they
won't get that money back. The level of education needed to prevent
these incidents is not feasible for the casual user; I just got email
from "Expedia" telling me to log in because my trip had changed, and I
had to look very carefully and check headers against an email I knew
to be legit to determine it was a phish, and I've been doing this for
20 years.

It's really a problem.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Bill Cole via mailop]

On 24 Oct 2019, at 6:15, Jaroslaw Rafa via mailop wrote:

Don't try to be too perfect at spam filtering. Just be good enough. 
That's

enough :).


Everyone has a different idea of "good enough" and it even varies by 
address for individuals...


I have a dozen distinct email accounts including test accounts on most 
big freemail providers, professional accounts in domains owned by 
clients/employers, and personal accounts on my own systems. Some of 
these also have aliases or are on the receiving end of external 
forwarding. Most days, no spam of any sort is delivered to any of these 
accounts, even to the "spam folders" imposed by some mailbox providers. 
It's a bad month when I see a dozen spams across all of my mail 
accounts, and I look at all of my spam folders because I don't trust the 
providers who use them.


I'm still working to make my spam filtering "good enough."

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Benoit Panizzon via mailop]

> On 24/10/2019 14:12, Benoit Panizzon via mailop wrote:
> > I also considered hacking together a small 'relay' MTA which would
> > receive the email but not reply OK to the final DATA command (RFC
> > states you can take up to 60 seconds to reply to the DATA command)  
> 
> 60 seconds? I thought the timeout there SHOULD be at least 10 minutes
> 
> https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6

Yeah, sorry you're right of course. But still, if you wait that long,
you will find many submitters which disconnect and reconnect causing
email duplication.

Yes, I know 'SHOULD' not 'MUST'.

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Paul Smith via mailop]

On 24/10/2019 14:12, Benoit Panizzon via mailop wrote:

I also considered hacking together a small 'relay' MTA which would
receive the email but not reply OK to the final DATA command (RFC
states you can take up to 60 seconds to reply to the DATA command)


60 seconds? I thought the timeout there SHOULD be at least 10 minutes

https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6

I'm not saying anyone sticks to that - but that's what the RFC says, so 
you have a reasonable excuse for observing that. In fact the RFC doesn't 
have any suggested timeouts being as low as 1 minute.



Because the biggest problem in this scenario is backscatter, the other 
option is not to bounce messages, but use a spam folder instead at the 
destination server.


Even if you pass through, you have to decide what to do if the remote 
server isn't responding for some reason - do you queue the message (in 
which case you have to handle backscatter anyway) or reject it (in which 
case, you may have to do duplicated work, and your customer may prefer 
that you queued the message to prevent the risk of them losing it)




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Jeremy Harris via mailop]

On 24/10/2019 14:12, Benoit Panizzon via mailop wrote:
> And I must admit, I have no real solution if you use some out of the
> stock MTA like postfix or sendmail which work on store and forward
> basis.

Exim can operate in cutthrough mode.
-- 
Cheers,
  Jeremy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Benoit Panizzon via mailop]

Hi Stefan

> So the reject generates bounces at our spamfilters. Howto handle this?

Yes, I do know this issue, as we offer a similar service.

And I must admit, I have no real solution if you use some out of the
stock MTA like postfix or sendmail which work on store and forward
basis.

I also considered hacking together a small 'relay' MTA which would
receive the email but not reply OK to the final DATA command (RFC
states you can take up to 60 seconds to reply to the DATA command)

The relay MTA would perform virus / spamfiltering and then forward the
email to the destination MX.

When the Destination MX replies with OK to the DATA phase, and only
then, it would reply back, possibly forwarding the same OK messages it
received from upstream, to the sending side.

Pitfalls:

* 60 second according RFC, not every MSA respects this. Our Spamfilter
  sometimes takes a couple of seconds to scan the content after DATA. If
  it's too long, some MTA start re-sending the email multiple times.

* You have to possibly hold many connections open.

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Francois Petillon via mailop]

On 10/24/19 2:19 PM, Stefan Bauer via mailop wrote:
> Sometimes, customers feel clever and have another local mailfilter on
> site, that rejects mails, after we already have accepted them at
> spamfilter level.
> So the reject generates bounces at our spamfilters. Howto handle this?

_If_ your clients manage their own servers, your spamfilters may act as
proxies (you just need to store the EHLO/MAIL FROM and delay the DATA to
analyse the mail before sending it, all other commands may be proxified
directly). The main issue with this kind of setup is to manage multiple
recipients on different servers (ie when a mail is accepted for some
recipients and rejected for others).

By managing their own servers, I mean they have a way to setup their
servers to put special rules about your IPs (such as accept xforward,
avoid blacklists on your IP, etc.).

François

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Jeremy Harris via mailop]

On 24/10/2019 13:19, Stefan Bauer via mailop wrote:
> We are doing MX-spamfilter service for some customers and forward "clean" 
> mails to customer mailservers.
> 
> We are doing recipient-checks before accepting mails.
> 
> 
> 
> Sometimes, customers feel clever and have another local mailfilter on site, 
> that rejects mails, after we already have accepted them at spamfilter level.
> 
> 
> 
> So the reject generates bounces at our spamfilters. Howto handle this?

There is nothing you can do and still operate in store-and-forward mode.

If you do your scan-and-forward in cutthrough mode, you can pass the
remote reject back to the source as an SMTP reject, avoiding a bounce
generation by your site.
-- 
Cheers,
  Jeremy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Stefan Bauer via mailop]

Hi,



here is a thing, that we do not see a real solution to it and would be happy, 
to get some ideas from other mailops.



We are doing MX-spamfilter service for some customers and forward "clean" mails 
to customer mailservers.

We are doing recipient-checks before accepting mails.



Sometimes, customers feel clever and have another local mailfilter on site, 
that rejects mails, after we already have accepted them at spamfilter level.



So the reject generates bounces at our spamfilters. Howto handle this?




Stefan
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Graeme Fowler via mailop]

On 24 Oct 2019, at 11:15, Jaroslaw Rafa via mailop  wrote:
> The goal of spam filtering is - in my opinion - filter the majority of spam
> messages, so that they don't clutter the user's mailbox and don't prevent
> him/her from normally using e-mail. If one or two (or even five) spam
> messages go through, it's not a tragedy - the user can delete them manually.

I'd love to have your user base. 1 or 2 potential junk/spam/phish messages in 
inboxes across ours makes for multiple calls to our service desk that the "spam 
filter has failed". It's like the delete key doesn't exist (or has been mapped 
to a "raise a ticket" routine).

> On the other hand, if one or two "legitimate" messages (for "legitimate",
> consider here "messages that recipient wants or at least may want") end up
> in the spam folder, which means they will never be read by an average user,
> is a much more serious issue.

I'll come back to this point below.

> If someone is stupid enough to fall for a phishing message, they should be
> educated. It should start from schools; it should take place in companies
> etc. People should be constantly taught how to recognize phishing and not
> fall for it. Why do we teach people how to safely cross the street, but we
> don't teach them how to safely use the Internet?

People still get run over crossing the road; they still cross the road in 
stupid places, when they're not concentrating, when they're in a rush, when 
they're not feeling very well... the list goes on. People aren't "stupid" per 
se, they are - as you state - human, and humans make mistakes. No amount of 
education will prevent humans making mistakes or being distracted. I'm not 
saying don't educate, but as someone who is regularly involved awareness 
campaigns about IT security I am acutely aware of the fine line between too 
much and too little. Too little? Users get scammed. Too much? They report. 
Every. Single. Unwanted. Message (even the ones that are "legitimate").

Additionally (from above), if you think education is the key, why not educate 
your users to check the junk folder? It would be "stupid" to not check it if it 
exists (your term). Our users are taught to do just this, a side-effect of 
which is week-old emails that were put in the Junk folder get reported as - you 
guessed it - Junk.

Humans are fallible. Computers programmed by humans inherit the same 
fallibility, despite our ongoing attempts to either teach them to not be or 
make them teach themselves. They inherit the same biases from us, but what they 
can do is the same task at mega-scale that we can do at an individual level, 
and they can do it much more quickly. And they never get tired. This does mean 
they can make mistakes at a stupendous rate too, though, which brings us to...

> Don't try to be too perfect at spam filtering. Just be good enough. That's
> enough :).

There's the issue. Your "good enough" isn't a global setting - so we're back to 
"their network, their rules" all over again.

G
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] A1/aon.at contact

[Jan-Philipp Benecke via mailop]

Hey together,

hoping there is someone from aon.at/A1 on list.
We tried to reach out to you but your postmaster@ mailbox exceeded the
quota ;)

Can someone may contact me off-list ?

Thanks a lot.

Have a nice day,
Jan-Philipp

 
 
 
Jan-Philipp Benecke
Deliverability Team

Fon: +49 4402 97390-16 
E-Mail: j...@cleverreach.com 

Xing  LinkedIn
 

*CleverReach GmbH & Co. KG
HRA 4020 Oldenburg (Oldb.)*
cleverreach.de 
CleverReach® 
CleverReach® 

Vertreten durch: CleverReach Verwaltungs GmbH, HRB 210079 Oldenburg (Oldb.)
//CRASH Building | Schafjückenweg 2 | 26180 Rastede | Germany
Geschäftsführung: Jens Klibingat & Sebastian Schwarz
Aufsichtsrat: Rolf Hilchner & Heinz-Wilhelm Bogena

PUSH///  CleverReach®
 CleverReach @Instagram
 https://twitter.com/cleverreach
 CleverReach @YouTube


Aktuell können Sie einige Informationen nicht sehen.Bitte aktivieren Sie
externe Inhalte, um die Mail vollständig angezeigt zu bekommen oder
klicken Sie hier.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Jaroslaw Rafa via mailop]

Dnia 23.10.2019 o godz. 15:56:00 Joel M Snyder via mailop pisze:
> There are few that would argue that phishing should not be trapped
> and blocked today, but 10 years ago what we now call "whale
> phishing"---one-to-one non-commercial non-bulk messages, sometimes
> between friends---would have gotten through every mail filter.

But even if one such message goes through, is this really a problem?

Perhaps we should ask ourselves what is the actual goal of spam filtering.
In my opinion it is *not* to filter out *absolutely all* spam (for "spam",
consider here "messages unwanted by the recipient"), because it's not only
impossible but also requires too much effort and - most important - doesn't
make sense.

The goal of spam filtering is - in my opinion - filter the majority of spam
messages, so that they don't clutter the user's mailbox and don't prevent
him/her from normally using e-mail. If one or two (or even five) spam
messages go through, it's not a tragedy - the user can delete them manually.

On the other hand, if one or two "legitimate" messages (for "legitimate",
consider here "messages that recipient wants or at least may want") end up
in the spam folder, which means they will never be read by an average user,
is a much more serious issue.

I have an impression that we are trying to replace user's own intelligence
by artificial intelligence and machine learning, trying to prevent user from
every possible - actual and imagined - "bad" message. That's simply
impossible, will not work and has no sense. We are humans and computers are
computers; we have to be smarter than computers and we have to decide what we
do and what we don't want to see. And if we don't want to see, we simply
delete it. As long, as it's not like 20 or 30 messages per day and a large
part of my inbox, it's absolutely no problem that one or two unwanted
messages go through.

If someone is stupid enough to fall for a phishing message, they should be
educated. It should start from schools; it should take place in companies
etc. People should be constantly taught how to recognize phishing and not
fall for it. Why do we teach people how to safely cross the street, but we
don't teach them how to safely use the Internet?

We have the unique capability that differs us from computers that we are
able to THINK. We (all) should make use of that capability. Instead, we
(engineers) try to make computers think - is it in a hope that they will
replace human thinking and we (all) wouldn't need to think anymore?

It's clearly visible in the smartphone business. The "smarter" the
smartphones and their applications are, the dumber their users become. They
"outsource" all their thinking to the device they are holding in hand and
just trust blindly whatever the device tells them.

That's just absurd.

Don't try to be too perfect at spam filtering. Just be good enough. That's
enough :).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Alessandro Vesely via mailop]

On Wed 23/Oct/2019 22:26:17 +0200 Jaroslaw Rafa via mailop wrote:
> Dnia 23.10.2019 o godz. 12:59:26 Brandon Long via mailop pisze:
>> Re Postel's Law:
>> 
>> The Harmful Consequences of the Robustness
>> 
>> Principle ie Postel was wrong
>> 
>> 
>> https://tools.ietf.org/html/draft-iab-protocol-maintenance-03
> 
> Interesting draft - thank you Brandon - however after reviewing it, I would
> say that contrary to the title this document by no way proves that Postel's
> law was wrong. It just tries to make it's applicability area more precise.


To be fair, Postel's words on being tolerant, cited right at the beginning of
the Introduction of that draft, end in "unless [intolerance] is required by the
specification".  IOW, tolerance is the default behavior.  That doesn't mean
that protocol specifications should be sloppy, but just in case...


> However, even within this draft, we are still talking about
> changing/modifying specifications. What if there's no specification at all?
> In our case, you don't know what exactly causes your mail to go to spam or
> be rejected?


The draft exemplifies a few protocols (TLS, JSON, HTTP, HTML) but not SMTP.

I'd note that the Internet Standard for email is still rfc821.  Rfc5321 is a
Draft Standard.  It is 11 years old and is not yet being refined, AFAIK.  It
doesn't dig into spam filtering, reputation, authentication, and similar; it
barely acknowledges that they exist.  It is still a specification, though.

There are specifications on authentication, such as SPF, DKIM, and DMARC.  For
reputation, there is a specification (rfc7070 & Co.) for exchanging reputation
values, it neither says how to obtain those values nor how to treat them.
After all, also HTML specifies the format, not the content.  The same goes for
DNSxLs.

We invented a global loudspeaker but said nothing about lists to speak.


Best
Ale
-- 

























___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] FW: Junk filtering as a tool for unfair competition

[Paul Smith via mailop]

On 24/10/2019 04:56, Noel Butler via mailop wrote:


On 24/10/2019 05:16, Michael Wise via mailop wrote:




Also, trivial messages look like probes, and are probably going to be 
junked.


Therein lies the problem, what if we all decided to junk everybodys 
email because it looks trivial, we might as well junk everybodys email 
and be done with it.


There's 'trivial' and then there's 'trivial'.

"Should we meet at the pub tonight" is trivial, but (probably) not what 
Michael means.


"Test" is trivial, and possibly what Michael means.

I have seen cases where we have received thousands of emails with the 
word 'test' (or 'hello', or similar) to different random email addresses 
on our systems in a very short period of time. It seems to be an attempt 
to try to work out which email addresses are valid and which aren't. The 
problem is that there's very little in that message that can be used for 
content filtering and it's a common way to do a legitimate test as 
well.  So, to filter it effectively, you need to use other means (sender 
reputation, looking at all received messages across the whole system 
looking for patterns etc).


To be honest, given the message content, you have to wonder if it's 
worth going to a lot of effort just for that.


I've simply learned never to send a test message with just something 
like 'test' in the message body. Put more content in the message to give 
the content filter something to look at. (eg "This is a test message 
from Bob at Bobtech Ltd. Please let Jim in your IT department know if it 
worked or not"). Also, make each test message different, or that can 
look spammy as well, and don't send zillions at once.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Suresh Ramasubramanian via mailop]

On 24/10/19, 11:43 AM, "mailop on behalf of Thomas Walter via mailop" 
 wrote:

>Users can not be trusted to categorize emails.

Not one user no.  Neither can a single voter be trusted with the decision of 
who gets to rule a country.

Yes sometimes the aggregate of all the voters - or all the users at a provider 
- might get it wrong, and you then end up with [insert politiican's name here] 
or [university alerts getting misfiled] 

That's still better than some omniscient postmaster deciding what's spam and 
what's legit.

--srs 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Chris Wedgwood via mailop]

> Users can not be trusted to categorize emails.

who better than the recipient to decide if it's undesirable?

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Thomas Walter via mailop]

Hay Jay,

On 24.10.19 01:58, Jay Hennigan via mailop wrote:
> It does seem that the user behavior of incorrectly marking mail as spam
> has been going on far too long. Large webmail providers, PLEASE update
> your UI to label that choice "Report as spam", not simply "Junk".

This doesn't help as long as users categorize "emails I don't like right
now" as Spam.

For example a lot of our students seem to be sorting official university
emails that remind them to re-register or important test reminders as
"Junk". E-Mails they have explicitely subscribed to and that are
important for their academic career.

Users can not be trusted to categorize emails.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop