Re: [mailop] Bitninja

[Tom Ellengold]

I have replied to messages from them numerous times of the years looking to get 
additional details on a supposed issue (always the same IP).

I never received a single reply back, eventually I gave up.

Cheers,

Tom

[Mapp]

Tom Ellengold
Sr Compliance & Privacy Consultant
(o) 619-342-4346
(m) 718-986-2848
www.mapp.com



From: mailop  On Behalf Of Ewald Kessler | webpower
Sent: Thursday, January 24, 2019 10:52 AM
To: Alexander Burch 
Cc: mailop 
Subject: Re: [mailop] Bitninja

This email has reached Mapp via an external source

Hi Alex,

As far as my experience with BitNinja goes, on both occasions that they 
contacted us, they were pretty cooperative in finding the spam source. But I 
must admit our IP's never got blacklisted, only greylisted.

Regards,
Ewald

On Thu, 24 Jan 2019 at 16:38, Alexander Burch 
mailto:abu...@activecampaign.com>> wrote:
Is there any reason I should think Bitninja is reputable? They send us 
complaint reports all the time and I often investigate them but they seem 
totally erroneous and never lead to any real spam activity.

Then they send me a notice they've blacklisted our IP and that we should 
consult them for services to help keep our IPs clean.

It seems completely untrustworthy, but maybe I'm wrong? Is there any legitimacy 
to bitninja?

Thanks,
Alex

--

[https://d226aj4ao1t61q.cloudfront.net/cy3nisxfd_ac_logo-circle.png]

Alexander Burch
ActiveCampaign / Deliverability Engineer
abu...@activecampaign.com
1 North Dearborn St Suite 500, Chicago IL, 60602
[https://d226aj4ao1t61q.cloudfront.net/ys2h3to2m_email-facebook.png]
 [https://d226aj4ao1t61q.cloudfront.net/tc3x0kcsn_email-twitter.png] 
  
[https://d226aj4ao1t61q.cloudfront.net/y1t0ztxcr_email-linkedin.png] 
  
[https://d226aj4ao1t61q.cloudfront.net/j14l6ck9n_email-google.png] 



[https://www.activecampaign.com/sig/?u=aburch]
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


--
Deliverability & Abuse Management, 
www.webpower-group.com
ewald.kess...@webpower.nl
t: +31 342 423 262
li: www.linkedin.com/in/ewaldkessler

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

Re: [mailop] Quick question on SPF...

[Dave Warren]

On 2019-01-24 09:29, Paul Ebersman wrote:

And if the
server doesn't give the same complete answer every time (regardless of
order), it's technically violating the DNS RFCs.


I'm not sure that this is really true from a client's standpoint.

Just because you get a different answer from my authoritative server 
every time you query doesn't actually mean I am giving you incomplete 
answers, maybe I'm just changing the zone very very frequently?


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

Re: [mailop] Quick question on SPF...

[Paul Ebersman]

ebersman> And if the server doesn't give the same complete answer every
ebersman> time (regardless of order), it's technically violating the DNS
ebersman> RFCs.

dw> I'm not sure that this is really true from a client's standpoint.

dw> Just because you get a different answer from my authoritative server
dw> every time you query doesn't actually mean I am giving you
dw> incomplete answers, maybe I'm just changing the zone very very
dw> frequently?

Yes, if the zone changes. But assuming the same SOA for the zone, giving
a different answer for the same query is breaking the "rules". Doesn't
mean it doesn't happen (there are all sorts of places we now do "stupid
DNS tricks") but it does violate the RFCs. And assuming you're not also
doing DNSSEC tricks, it breaks DNSSEC.

But getting back to the original topic, the point is that using things
like DNS round robin or trying to load balance by giving different
responses to the same question will tend to bite you in the ass because
you might not want to follow the rules but someone else in the DNS chain
might be strict.

In general, it's far more reliable for the app that is generating the
query to have any logic or load balancing or whatever built into the app
and not assume that the DNS won't ever surprise you.

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

Re: [mailop] Quick question on SPF...

[Dave Warren]

On 2019-01-26 16:24, Paul Ebersman wrote:

ebersman> And if the server doesn't give the same complete answer every
ebersman> time (regardless of order), it's technically violating the DNS
ebersman> RFCs.

dw> I'm not sure that this is really true from a client's standpoint.

dw> Just because you get a different answer from my authoritative server
dw> every time you query doesn't actually mean I am giving you
dw> incomplete answers, maybe I'm just changing the zone very very
dw> frequently?

Yes, if the zone changes. But assuming the same SOA for the zone, giving
a different answer for the same query is breaking the "rules".


Assume I incremented the SOA so many times it wrapped around and is back 
to the original number (because you can't prove it didn't, therefore 
your code can't make assumptions about the SOA even if you happen to 
have it available).


Besides which, the SOA serial shouldn't be used by anything other than 
primary/secondary implementations which rely on classic zone transfers.




Doesn't
mean it doesn't happen (there are all sorts of places we now do "stupid
DNS tricks") but it does violate the RFCs. And assuming you're not also
doing DNSSEC tricks, it breaks DNSSEC.

But getting back to the original topic, the point is that using things
like DNS round robin or trying to load balance by giving different
responses to the same question will tend to bite you in the ass because
you might not want to follow the rules but someone else in the DNS chain
might be strict.


Outside of DNSSEC, everyone else can be as strict as they want, they can 
either cache the result (within the TTL) or not (it doesn't matter).


(My understanding of DNSSEC is that you could make this work by signing 
the responses on the fly, but I could be wrong about this, I freely 
admit I am not up to speed on DNSSEC beyond signing basic zonefile based 
zones.)




In general, it's far more reliable for the app that is generating the
query to have any logic or load balancing or whatever built into the app
and not assume that the DNS won't ever surprise you.


Agreed. But in practice, it works well enough on the small scale.

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

Re: [mailop] Quick question on SPF...

[Paul Ebersman]

dw> Assume I incremented the SOA so many times it wrapped around and is
dw> back to the original number (because you can't prove it didn't,
dw> therefore your code can't make assumptions about the SOA even if you
dw> happen to have it available).

There are all sorts of ways to abuse and break DNS. But mail has enough
moving parts outside your control that if you can avoid adding to the
chaos, that seems like a prudent move. And you should understand what
rules you're breaking and what the possible failures are.

ebersman> In general, it's far more reliable for the app that is
ebersman> generating the query to have any logic or load balancing or
ebersman> whatever built into the app and not assume that the DNS won't
ebersman> ever surprise you.

dw> Agreed. But in practice, it works well enough on the small scale.

If you control everything (servers, stubs, middleware, firewalls) in the
chain between original querier and the auth server and the auth server,
sure. In servicing email, that's a hard assumption to make.

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

Re: [mailop] Quick question on SPF...

[John Levine]

In article <20190126232417.87671fb7...@fafnir.remote.dragon.net>,
>dw> Just because you get a different answer from my authoritative server
>dw> every time you query doesn't actually mean I am giving you
>dw> incomplete answers, maybe I'm just changing the zone very very
>dw> frequently?
>
>Yes, if the zone changes. But assuming the same SOA for the zone, giving
>a different answer for the same query is breaking the "rules".

Actually, Dave is technically right.  SOA serial numbers only matter
for synchronizing zones via AXFR.  Other than that, authoritative
servers can give any answers they want.

>But getting back to the original topic, the point is that using things
>like DNS round robin or trying to load balance by giving different
>responses to the same question will tend to bite you in the ass because
>you might not want to follow the rules but someone else in the DNS chain
>might be strict.

Right, it's technically legal but it is a bad idea unless you
understand what you're doing really really well and can do tricks like
synthesized CNAMEs invented by CDNs.

For a mail server, I agree that if you don't give the same answer
every time (perhaps give or take the order of the records) you will
shoot yourself in the foot soon enough.  I also agree that except in the
simplest cases, explicit SPF ip4: and ip6: clauses are a better idea than
indirecting through a: and mx: clauses.

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