On 10 Jun 2018, at 17:26, Al Iverson via mailop wrote:
example.net IN MX 0 .
Nice. It's been listed in a few best practice documents as well as
RFC 7505 for more than a few years. Good to see it getting some
traction.
I cry a little inside every time I see a null MX, think of
On Fri, 8 Jun 2018 at 18:14, Stefano Bagnara wrote:
> On Fri, 8 Jun 2018 at 17:53, Michael Peddemors wrote:
> > [...]
> > And while using that as feedback might seem the logical conclusion, in
> > the real world we still see more feedback reports from legitimate email
> > the customer should
On 06/10/2018 03:26 PM, Al Iverson via mailop wrote:
I cry a little inside every time I see a null MX, think of the lost
opportunity to be handling it as a spamtrap domain instead.
~chuckle~
Fair enough.
I also view it as an opportunity to accidentally leak email that ends up
being feed
> > example.net IN MX 0 .
>
> Nice. It's been listed in a few best practice documents as well as RFC 7505
> for more than a few years. Good to see it getting some traction.
I cry a little inside every time I see a null MX, think of the lost
opportunity to be handling it as a spamtrap
> On Jun 10, 2018, at 10:18 AM, Grant Taylor via mailop
> wrote:
>
> On 06/09/2018 09:32 AM, Andrew C Aitchison wrote:
>> If a domain has no MX record, do all servers deliver to an record, as
>> required by (at least) RFC3974, or do some email systems ignore domains with
>> no MX and no
On 06/09/2018 09:32 AM, Andrew C Aitchison wrote:
If a domain has no MX record, do all servers deliver to an record,
as required by (at least) RFC3974, or do some email systems ignore
domains with no MX and no A record ?
My personal stance has been "Don't be surprised if the lack of an
In article you write:
>>> If a domain has no MX record, do all servers deliver to an record,
>>> as required by (at least) RFC3974,
>
>You'd expect, No MX record, no mail delivery. MX is related to
>hostname, not the transport stack.
Only if you'd never read RFC 5321, particularly section
On 10/06/2018 3:16 AM, Stefano Bagnara wrote:
> On Sat, 9 Jun 2018 at 17:36, Andrew C Aitchison
> wrote:
>> I'm curious.
>> If a domain has no MX record, do all servers deliver to an record,
>> as required by (at least) RFC3974,
You'd expect, No MX record, no mail delivery. MX is
> If the industry had moved to a reputation model, it would be easier to
> discuss "how bad is it" and whether it's bad enough to block at IP time, or
> whether you mix it into your spam score.
Isn’t this what postscreen_dnsbl_sites is doing, for example?
> Will SMTP be the last hold-out on
> Isn't the simplest way to handle this is to treat IPv6 at the /64 or smaller
> level?
There is no broad consensus yet on where IPv6 reputation should be attached to.
Cheap hosting providers handing out individual /128s to customers…
Discovery protocols to find the „right“ prefix length to
On Fri, 8 Jun 2018 at 19:31, Michael Peddemors wrote:
> On 18-06-08 09:14 AM, Stefano Bagnara wrote:
> > [...]
> > In fact I still have to understand how spam reports and false positive
> > reports are collected in the whole plesk world (I guess you know what
> > I'm talking about): [...]
>
>
On 18-06-08 09:14 AM, Stefano Bagnara wrote:
On Fri, 8 Jun 2018 at 17:53, Michael Peddemors wrote:
[...]
And while using that as feedback might seem the logical conclusion, in
the real world we still see more feedback reports from legitimate email
the customer should have wanted, vs emails
On 6/8/2018 11:50 AM, Michael Peddemors wrote:
It is sometimes important to point out that the email marketing is a
multi-billion dollar business.. The spam protection and RBL operators
get very little money if any in comparison..
I was reading an ebook on marketing this past week -
On 6/8/2018 12:02 PM, David Hofstee wrote:
Earlier you stated that larger setups depended on having blacklists at
the gate to keep processing manageable but which results in less
weighed filtering. [see #5]
yes, but I wasn't referring to ALL blacklists - just a handful of the
most effective
On Fri, 8 Jun 2018 at 17:53, Michael Peddemors wrote:
> [...]
> And while using that as feedback might seem the logical conclusion, in
> the real world we still see more feedback reports from legitimate email
> the customer should have wanted, vs emails tagged as spam that are spam.
Well, this
> (1) First, I "eat my own dogfood", ...
Yes, that was clear.
> (2) A large percentage of invaluement subscribers use SpamAssassin
So this should work somewhat. If you have the capacity to let everything be
processed by the SA content filter. Earlier you stated that larger setups
depended on
On 18-06-08 08:21 AM, Stefano Bagnara wrote:
If you really think that rejecting email from senders that want to
optimize their costs is a good strategy
Well, IPv6 is simply a way to make email sending cheaper. So not
supporting Ipv6 is an effective way to dump cheap sending.
I guess anyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-06-08 at 17:21 +0200, Stefano Bagnara wrote:
> On Fri, 8 Jun 2018 at 16:47, Jim Popovitch via mailop org> wrote:
> > On Fri, 2018-06-08 at 10:27 -0400, Rob McEwen wrote:
> > > there has to be some justified level of "collateral damage"
On Fri, 8 Jun 2018 at 16:47, Jim Popovitch via mailop wrote:
> On Fri, 2018-06-08 at 10:27 -0400, Rob McEwen wrote:
> > there has to be some justified level of "collateral damage" these
> > days, due to the very high frequency of hijacked accounts, hijacked
> > websites, and spamming ESP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-06-08 at 10:27 -0400, Rob McEwen wrote:
> there has to be some justified level of "collateral damage" these
> days, due to the very high frequency of hijacked accounts, hijacked
> websites, and spamming ESP customers (from ESP that are
On 6/8/2018 5:49 AM, David Hofstee wrote:
> ... score of the sending-IP, which is similar to what you've
described, correct?
Correct.
So you have these mechanisms in place. But your customers, who get
access to the invaluement RBL, do not. Am I correct? If I am,
it still results in the
On Fri, 8 Jun 2018 at 13:57, David Hofstee wrote:
> Hi Stefano,
>
> The only problem I see with Cloudmark is that they are not just a reputation
> provider, but a spamfilter provider with access to all the data. Which has
> been acquired by Proofpoint.
Well it is a mix of reputation and
Hi Stefano,
The only problem I see with Cloudmark is that they are not just a
reputation provider, but a spamfilter provider with access to all the data.
Which has been acquired by Proofpoint.
I'm asking myself the question if the fingerprints they collect are GDPR
proof (although Jaren may
On Fri, 8 Jun 2018 at 11:53, David Hofstee wrote:
> [...]
> I also think that there is space for a reputation provider which can:
> - Identify more than just IP addresses and domains from an email.
This is what CloudMark Authority does about this, but you enable a new
set of issues that have
Hi Rob,
> ... score of the sending-IP, which is similar to what you've described,
correct?
Correct.
So you have these mechanisms in place. But your customers, who get access
to the invaluement RBL, do not. Am I correct? If I am, it still results in
the conclusion that blacklists are not
On 6/7/2018 6:55 PM, Brandon Long wrote:
Note I'm not saying that IP time blocking isn't useful. My issue is,
are most RBL's good for IP time blocking? An RBL is a statement that
everything from that IP is bad, but the truth of that statement varies
greatly based on the RBL in question. But,
Note I'm not saying that IP time blocking isn't useful.
My issue is, are most RBL's good for IP time blocking?
An RBL is a statement that everything from that IP is bad, but the truth of
that statement varies greatly based on the RBL in question.
But, in the end, what everyone seems to have is
On 6/7/2018 9:45 AM, David Hofstee wrote:
Isn't it time conclude that "separate IP blacklists" combined with
"separate content filters" are not sufficient any more? Because you
need one to interact with the other? You need the content filter to
steer the IP blacklist (and other traffic
Hi Rob,
Isn't it time conclude that "separate IP blacklists" combined with
"separate content filters" are not sufficient any more? Because you need
one to interact with the other? You need the content filter to steer the IP
blacklist (and other traffic limiting methods like throttling and
In article
you write:
>Isn't the simplest way to handle this is to treat IPv6 at the /64 or
>smaller level?
That's what Spamhaus does. They made rbldnsd serve v6 CIDRs like it serves v4.
Apropos of Steve's comment about blowing caches, I did some
simulations a while ago of various ways to
> 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
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
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
> 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,
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
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
36 matches
Mail list logo
