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 the
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 have
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 into
> > 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 do
> 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 MX
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 5
In article
you write:
>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
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 related
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,
required?
"This memo provides information for the Internet community. It does
not specify an Internet standard of an
On Wed, 6 Jun 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?"
https://www.linkedin.com/pulse/should-mail-servers-publish-ipv6-mx-records-rob-mcewen/
Th
> 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 IP
> 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 q
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): [...]
>
> Well
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 tagg
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 - mistakenly
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 a
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 is
> (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 havi
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 w
-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 customers
-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 o
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 concl
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 filter.
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 comme
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 been
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 sufficie
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, in
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 t
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 limiting
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
greylist
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 publ
On 6/6/2018 8:11 PM, Brandon Long wrote:
Isn't the simplest way to handle this is to treat IPv6 at the /64 or
smaller level?
Brandon,
Everything I've stated in that article, and in my comments on this
thread - came with the foreknowledge that many of those who have
discussed implementing IPv
> 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 s
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
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 part
> 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, DNS
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
40 matches
Mail list logo
