Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Steve Atkins]

> On Jun 6, 2018, at 5:11 PM, Brandon Long via mailop  wrote:
> 
> 
> 
> Isn't the simplest way to handle this is to treat IPv6 at the /64 or smaller 
> level?  More likely, because most people use IPv4, the RBL's just don't have 
> the data sources they need to populate the data, not because of some inherent 
> size problem with the data.
> 

IPv6 blacklists served over DNS using "regular" DNS infrastructure risk blowing 
out the caches of recursive resolvers (theoretically) if the lookup is done by 
/128 - there are potentially many, many queries you might have to make without 
getting cache hits. It's better with /64, but that's potentially not as 
selective as you might want while still meaning more cache hits (in theory) as 
/48s are handed out like candy in a way /16s aren't.

I'm not sure I believe that it's an actual problem today, or one that's likely 
in the future, but there is a potential issue there.

Distributing IPv6 reputation data via something other than DNS eliminates the 
issue. It can still be provided to the MXes via DNS, just directly from a local 
authoritative server rather than via a caching resolver.

That'd be better in many respects. (The history of BGP not being trivial to 
feed into mailservers and the coincidence that m4-ed sendmail.cf can be 
persuaded to do DNS lookups are the only reason we're where we are.)


> I'm also not clear that content level scanning is really so much more 
> expensive that it can't be invested in.  "Here's a nickel kid, buy yourself 
> another VM" or something.  More likely, there's a trade-off in trusting RBLs 
> completely vs how much mail you receive, and as you scale up, the more 
> numerous the false positives from RBLs become (not as a fraction but as an 
> absolute number)  and the more effort you need to put into doing more 
> complicated evaluations even as your traffic is higher.

I think content scanning is critical. A significant fraction of the spam I see 
- and a large fraction of the spam that's not trivially blocked - is coming 
from shared infrastructure (whether that be ESPs, Large Webmail Providers or 
Large Hosted Business Apps). Content can block that. Source IP based blocking 
can't, really, as the sources are shared between legitimate users and spammers. 
And, to wander back to the topic, the majority of spam I see on IPv6 comes from 
those sorts of provider.

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

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Brandon Long via mailop]

On Wed, Jun 6, 2018 at 4:48 PM Rob McEwen  wrote:

> On 6/6/2018 6:32 PM, Steve Atkins wrote:
>
> To answer the question in the title: "Probably, yes. Only if your spam 
> filtering is bad." As Rob mentions in his article in the case he's discussing 
> the spam would have been blocked if they'd had better spam filtering in place.
>
>
> Steve,
>
> (1) in that particular example, the technology used (uri blacklists
> checking domains in the body of the message) only applies to a subset of
> all incoming IPv6 spams, and the portion it doesn't apply to is very
> significant.
>
> (2) Also, had my subscriber (discussed in that article) not published IPv6
> MX records, those incoming IPv6 spams would have been sent via IPv4, and
> MUCH of that spam would have been easily blocked by low-FP IPv4 blacklists
> like Spamhaus' IPv4 blacklists and invaluement's IPv4 blacklists. In
> contrast, IPv6 filtering cannot possibly scale as well as IPv4 since the
> resulting increase in content filtering would be order of magnitudes more
> resource-expensive (CPU and RAM) than blocking so many of those connections
> via low-FP IPv4 blacklists at the perimeter. (especially when running the
> IPv4 lists locally in rbldnsd)
>
> Therefore, because of (1), IPv6 spam filtering can't possibly be *as*
> good (all else being equal) as spam filtering on a system that only accepts
> IPv4 connections. Because of (2) the filtering can't be as fast/efficient
> and doesn't scale nearly as well as IPv4 filtering - and the quality of
> one's content spam filtering doesn't change that. In fact, filtering IPv6
> spam will cause an INCREASE in necessary investments in more types of
> content filtering (to compensate for these not being blockable anymore via
> IPv4 blacklists), and that only further exacerbates the resource problems,
> which then only makes IPv6 filtering even LESS scalable.
>
> Steve - you have some valid points, but I think your "probably, yes"
> answer to the question in the title of my article fails to factor in these
> things. Due to these things I mentioned above, even someone with "good
> filtering" (who publishes IPv6 MX records) is still going to need EVEN MORE
> resource-expensive content filtering, which will require MORE hardware to
> run this increased content filtering, and such increases in content
> filtering does not scale very well (or at least don't scale
> inexpensively!). Also, their content filtering is STILL going to have some
> false positives in situations where the spam would have been easily blocked
> by IP4v blacklists had those IPv6 MX records not been published, and the
> content filtering missed. Also, the example of that spam being blockable
> via ivmURI was somewhat anecdotal. While ivmURI can greatly help to block
> IPv6-sent spams that otherwise would have been blocked by IPv4 IP
> blacklists, ivmURI doesn't solve the entire problem, nor can ANY content
> filtering be nearly as efficient as when an IPv4 DNSBL blocks the spam at
> the perimeter! In fact, many medium and large systems heavily depend on
> their content filters getting a reduced spam volume due to IPv4 blocking a
> high percentage of such spams BEFORE the body of the message is accepted
> (before DATA).
>
Isn't the simplest way to handle this is to treat IPv6 at the /64 or
smaller level?  More likely, because most people use IPv4, the RBL's just
don't have the data sources they need to populate the data, not because of
some inherent size problem with the data.

I'm also not clear that content level scanning is really so much more
expensive that it can't be invested in.  "Here's a nickel kid, buy yourself
another VM" or something.  More likely, there's a trade-off in trusting
RBLs completely vs how much mail you receive, and as you scale up, the more
numerous the false positives from RBLs become (not as a fraction but as an
absolute number)  and the more effort you need to put into doing more
complicated evaluations even as your traffic is higher.

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

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Rob McEwen]

On 6/6/2018 6:32 PM, Steve Atkins wrote:

To answer the question in the title: "Probably, yes. Only if your spam filtering is 
bad." As Rob mentions in his article in the case he's discussing the spam would have 
been blocked if they'd had better spam filtering in place.


Steve,

(1) in that particular example, the technology used (uri blacklists 
checking domains in the body of the message) only applies to a subset of 
all incoming IPv6 spams, and the portion it doesn't apply to is very 
significant.


(2) Also, had my subscriber (discussed in that article) not published 
IPv6 MX records, those incoming IPv6 spams would have been sent via 
IPv4, and MUCH of that spam would have been easily blocked by low-FP 
IPv4 blacklists like Spamhaus' IPv4 blacklists and invaluement's IPv4 
blacklists. In contrast, IPv6 filtering cannot possibly scale as well as 
IPv4 since the resulting increase in content filtering would be order of 
magnitudes more resource-expensive (CPU and RAM) than blocking so many 
of those connections via low-FP IPv4 blacklists at the perimeter. 
(especially when running the IPv4 lists locally in rbldnsd)


Therefore, because of (1), IPv6 spam filtering can't possibly be /as/ 
good (all else being equal) as spam filtering on a system that only 
accepts IPv4 connections. Because of (2) the filtering can't be as 
fast/efficient and doesn't scale nearly as well as IPv4 filtering - and 
the quality of one's content spam filtering doesn't change that. In 
fact, filtering IPv6 spam will cause an INCREASE in necessary 
investments in more types of content filtering (to compensate for these 
not being blockable anymore via IPv4 blacklists), and that only further 
exacerbates the resource problems, which then only makes IPv6 filtering 
even LESS scalable.


Steve - you have some valid points, but I think your "probably, yes" 
answer to the question in the title of my article fails to factor in 
these things. Due to these things I mentioned above, even someone with 
"good filtering" (who publishes IPv6 MX records) is still going to need 
EVEN MORE resource-expensive content filtering, which will require MORE 
hardware to run this increased content filtering, and such increases in 
content filtering does not scale very well (or at least don't scale 
inexpensively!). Also, their content filtering is STILL going to have 
some false positives in situations where the spam would have been easily 
blocked by IP4v blacklists had those IPv6 MX records not been published, 
and the content filtering missed. Also, the example of that spam being 
blockable via ivmURI was somewhat anecdotal. While ivmURI can greatly 
help to block IPv6-sent spams that otherwise would have been blocked by 
IPv4 IP blacklists, ivmURI doesn't solve the entire problem, nor can ANY 
content filtering be nearly as efficient as when an IPv4 DNSBL blocks 
the spam at the perimeter! In fact, many medium and large systems 
heavily depend on their content filters getting a reduced spam volume 
due to IPv4 blocking a high percentage of such spams BEFORE the body of 
the message is accepted (before DATA).


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


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

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Steve Atkins]

> On Jun 6, 2018, at 1:41 PM, SM  wrote:
> 
> Hi Rob,
> At 01:08 PM 06-06-2018, Rob McEwen wrote:
>> Here is an article I posted on Linkedin about spam filtering IPv6-sent email.
>> 
>> "Should mail servers publish IPv6 MX records? Could this harm your spam 
>> filtering?"
> 
> In other words, DNSBLs have a scalability problem.

DNSBLs do. Reputation providers keyed on peer IPv6 address don't.

To answer the question in the title: "Probably, yes. Only if your spam 
filtering is bad.".

As Rob mentions in his article in the case he's discussing the spam would have 
been blocked if they'd had better spam filtering in place.

Cheers,
  Steve


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

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[SM]

Hi Rob,
At 01:08 PM 06-06-2018, Rob McEwen wrote:

Here is an article I posted on Linkedin about spam filtering IPv6-sent email.

"Should mail servers publish IPv6 MX records? Could this harm your 
spam filtering?"


In other words, DNSBLs have a scalability problem.

Regards,
-sm 



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

[mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Rob McEwen]

Here is an article I posted on Linkedin about spam filtering IPv6-sent 
email.


"Should mail servers publish IPv6 MX records? Could this harm your spam 
filtering?"


https://www.linkedin.com/pulse/should-mail-servers-publish-ipv6-mx-records-rob-mcewen/

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


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

Re: [mailop] sectoor TOR blacklist

[Al Iverson via mailop]

On Wed, Jun 6, 2018 at 1:09 PM Steve Atkins  wrote:

> > Hence, only half of Domain based blacklists that I know about support
> > the TEST address. That's why I prefer to test something less artificial
> > in this particular case.
>
> Checking other things is a reasonable defensive maneuver for your users, but 
> the blacklists that don't support those test addresses are kinda broken and 
> should really be fixed by their operators (and, perhaps, be treated as broken 
> by health check automation until they do so).

I would also like to add, 50% adoption of the proper test mechanism is
better than the almost 0% adoption seen in the past. Monitoring for
this for half the lists is better than not being able to monitor this
for any lists.

Cheers,
Al
-- 
al iverson // 312-725-0130 // miami
http://www.aliverson.com
http://www.spamresource.com

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

Re: [mailop] sectoor TOR blacklist

[Steve Atkins]

> On Jun 6, 2018, at 9:13 AM, Vsevolod Stakhov  wrote:
> 
> On 06/06/2018 16:55, Steve Atkins wrote:
>> 
>> 
>> IPv4 blacklists will always list 127.0.0.2 and never 127.0.0.1.
>> IPv6 blacklists will always list :::7F00:2 and never :::7F00:1.
>> Domain based blacklists will always list "TEST" and never list "INVALID".
> 
> I wish everybody follows that guidelines, but...
> 
> % host TEST.multi.surbl.org
> Host TEST.multi.surbl.org not found: 3(NXDOMAIN)
> 
> % host TEST.multi.uribl.com
> Host TEST.multi.uribl.com not found: 3(NXDOMAIN)
> 
> % host TEST.dbl.spamhaus.org
> TEST.dbl.spamhaus.org has address 127.0.1.2
> 
> % host TEST.uribl.spameatingmonkey.net
> Host TEST.uribl.spameatingmonkey.net not found: 3(NXDOMAIN)
> 
> % host TEST.public.sarbl.org
> TEST.public.sarbl.org has address 127.0.0.2
> 
> % host TEST.uribl.rspamd.com
> TEST.uribl.rspamd.com has address 127.0.0.2
> 
> Hence, only half of Domain based blacklists that I know about support
> the TEST address. That's why I prefer to test something less artificial
> in this particular case.

Checking other things is a reasonable defensive maneuver for your users, but 
the blacklists that don't support those test addresses are kinda broken and 
should really be fixed by their operators (and, perhaps, be treated as broken 
by health check automation until they do so).

Cheers,
  Steve

> 
>>> 
>>> For URL black lists it is not that clear: in Rspamd, for example, I
>>> monitor if 'facebook.com' is blacklisted by this list, however, I'm not
>>> 100% sure that it is the correct approach.
>> 
>> RFC 5782 is the reference to wave at people. 
>> https://wordtothewise.com/2018/05/spamcannibal-is-dead/ wraps a bit of 
>> friendlier wording around it.
>> 
>> Cheers,
>>  Steve
>> ___
>> 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


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

Re: [mailop] sectoor TOR blacklist

[Vsevolod Stakhov]

On 06/06/2018 09:03, Stefano Bagnara wrote:
> On Wed, 6 Jun 2018 at 09:52, Gianluca  wrote:
>> Hi all,
>> we experience some problems with sectoor.de blacklist, our ips are 
>> blacklisted into this list but the main web page of the blacklist 
>> http://www.sectoor.de/tor.php is simply a blank page without informations.
>> Anyone wih the same problem? Can we consider it a False Positive?
> 
> It is listing everything... sounds like the domain expired.
> So it is an issue for the receiver: they probably want to remove that
> DNSBL from their configuration or they won't receive anything anymore,
> from anyone.
> 
> Stefano
> 
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs

In fact, any software that uses RBLs for blocking should monitor those
lists for sanity.

For IP block lists it is quite straightforward: just check if 127.0.0.1
is listed and disable a list if it is (according to
https://tools.ietf.org/html/rfc5782#section-5).

For URL black lists it is not that clear: in Rspamd, for example, I
monitor if 'facebook.com' is blacklisted by this list, however, I'm not
100% sure that it is the correct approach.


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

Re: [mailop] sectoor TOR blacklist

[Jenkins, Matthew]

We saw the same thing yesterday, but were quickly delisted without action on 
our end.

Matt Jenkins

From: mailop  On Behalf Of Gianluca
Sent: Wednesday, June 6, 2018 9:49 AM
To: mailop@mailop.org
Subject: [mailop] sectoor TOR blacklist


Hi all,

we experience some problems with sectoor.de blacklist, our ips are blacklisted 
into this list but the main web page of the blacklist 
http://www.sectoor.de/tor.php
 is simply a blank page without informations.

Anyone wih the same problem? Can we consider it a False Positive?



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

Re: [mailop] sectoor TOR blacklist

[Stefano Bagnara]

On Wed, 6 Jun 2018 at 09:52, Gianluca  wrote:
> Hi all,
> we experience some problems with sectoor.de blacklist, our ips are 
> blacklisted into this list but the main web page of the blacklist 
> http://www.sectoor.de/tor.php is simply a blank page without informations.
> Anyone wih the same problem? Can we consider it a False Positive?

It is listing everything... sounds like the domain expired.
So it is an issue for the receiver: they probably want to remove that
DNSBL from their configuration or they won't receive anything anymore,
from anyone.

Stefano

--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

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

[mailop] sectoor TOR blacklist

[Gianluca]

Hi all,

we experience some problems with *sectoor**.de* blacklist, our ips are 
blacklisted into this list but the main web page of the blacklist 
http://www.sectoor.de/tor.php is simply a blank page without informations.


Anyone wih the same problem? Can we consider it a False Positive?


Gian Luca Vannucci

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

Re: [mailop] SNDS report issues? (Michael Wise)

[Edgaras | SENDER via mailop]

SNDS authorization emails are working again.

Thanks Michael!






Regards,

[image: Sender] Edgaras Vaitkevičius, founder / CEO
edga...@sender.net
+370 627 60923

Date: Mon, 4 Jun 2018 18:16:58 +
> From: Michael Wise 
> To: "mailop@mailop.org" 
> Subject: Re: [mailop] SNDS report issues?
> Message-ID:
>  namprd00.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
> Hmm.
> Asking around.
>
> Aloha,
> Michael.
> --
> Michael J Wise
> Microsoft Corporation| Spam Analysis
> "Your Spam Specimen Has Been Processed."
> Got the Junk Mail Reporting Tool en-us/download/details.aspx?id=18275> ?
>
> From: mailop  On Behalf Of Edgaras | SENDER
> via mailop
> Sent: Monday, June 4, 2018 9:07 AM
> To: mailop@mailop.org
> Subject: Re: [mailop] SNDS report issues?
>
> Having the same problem here. The access authorization email does not
> arrive, tried all the options: ab...@domain.tld,
> postmas...@domain.tld, etc.
>
> Reported the issue to msn-s...@microsoft.com
> on May 29th, got told that they "will be looking into this issue along with
> the Escalations Team", no resolution or update yet.
>
>
>
>
>
>
> Regards,
>
> [Sender]
>
> Edgaras Vaitkevičius, founder / CEO
> edga...@sender.net
> +370 627 60923
>
> Anybody having any luck with SNDS access verification requests recently? I
> haven't gotten one to work successfully since May 22nd.
>
> Cheers,
> Al Iverson
>
> On Fri, Jun 1, 2018 at 5:03 PM Michael Wise via mailop  >
> wrote:
>
> >
> >
> > Glorious; happy to be able to help!
> >
> > Happy Friday!
> >
> >
> >
> > Aloha,
> >
> > Michael.
> >
> > --
> >
> > *Michael J Wise*
> > Microsoft Corporation| Spam Analysis
> >
> > "Your Spam Specimen Has Been Processed."
> >
> > Got the Junk Mail Reporting Tool
> >  https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fdownload%
> 2Fdetails.aspx%3Fid%3D18275=02%7C01%7Cmichael.wise%40microsoft.com%
> 7C817ea89c3b3c43050c4208d5ca368e40%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636637258027671033=oW4Ajhhe%2Bf%
> 2BgpmA1CeRhopvZ9dmKJdRsL1y%2Fb7f1%2B7U%3D=0>> ?
> >
> >
> >
> > *From:* Joel Golliet mailto:j...@2lm.fr>>
> > *Sent:* Friday, June 1, 2018 4:57 AM
> > *To:* David Hofstee  opentext.dhofs...@gmail.com>>; Michael Wise <
> > michael.w...@microsoft.com>
> > *Cc:* mailop@mailop.org
> > *Subject:* Re: [mailop] SNDS report issues?
> >
> >
> >
> > You're right. It works for me, now.
> >
> > Thanks.
> >
> > Le 01/06/2018 à 11:21, David Hofstee a écrit :
> >
> > It does...
> >
> >
> >
> > Yours,
> >
> >
> >
> >
> >
> > David
> >
> >
> >
> > On 31 May 2018 at 21:30, Michael Wise via mailop  >
> > wrote:
> >
> >
> >
> > Please … try this, replacing [MyKey] with … your key:
> >
> >
> >
> >
> > https://sendersupport.olc.protection.outlook.com/SNDS/
> data.aspx?key=[MyKey]=052818 protection.outlook.com/?url=https%3A%2F%2Fsendersupport.
> olc.protection.outlook.com%2FSNDS%2Fdata.aspx%3Fkey%3D%
> 5BMyKey%5D%26date%3D052818=02%7C01%7Cmichael.wise%40microsoft.com%
> 7C817ea89c3b3c43050c4208d5ca368e40%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636637258027671033=lyJod1qbkuFLs95WWR%
> 2FP4ozZudCBda5SnTUB6SwgpUc%3D=0>
> >  https%3A%2F%2Fsendersupport.olc.protection.outlook.com%
> 2FSNDS%2Fdata.aspx%3Fkey%3D%255bMyKey%255d%26date%
> 3D052818=02%7C01%7C%7Cdc9f8100785a4b7ea98108d5c6a2c9f2%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636633324826424986=
> 40e%2BXzg9Bo8FgiN78IqHf8xvsMU%2FvmpLoHicu20MbxU%3D=0>
> >
> >
> >
> > Apparently it does work.
> >
> >
> >
> > Aloha,
> >
> > Michael.
> >
> > --
> >
> > *Michael J Wise*
> > Microsoft Corporation| Spam Analysis
> >
> > "Your Spam Specimen Has Been Processed."
> >
> > Got the Junk Mail Reporting Tool
> >  http%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fdownload%
> 2Fdetails.aspx%3Fid%3D18275=02%7C01%7CMichael.Wise%40microsoft.com%
> 7Ce08c31ffbad94d6821b808d5c7b6cbee%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636634510298268642=%2FaEf1s2VYLSc2Giw1SbiqPEi%
> 2FNUhYLyX7T1qlgbOLdc%3D=0>
> > ?
> >
> >
> >
> > *From:* mailop mailto:mailop-bounces@mailop.
> org>> *On Behalf Of *Michael Wise
> > via mailop
> > *Sent:* Wednesday, May 30, 2018 3:58 PM
> > *To:* Joel Golliet mailto:j...@2lm.fr>>; mailop@mailop.org
> 
> >
> >
> > *Subject:* Re: [mailop] SNDS report issues?
> >
> >
> >
> >
> >
> > Forwarding on your request …
> >
> > I gather that the data is flowing again, but not sure if we can
> back-fill.
> >
> >
> >
> > Aloha,
> >
> > Michael.
> >
> > --
> >
> > *Michael J Wise*
> > Microsoft