Here ya go ;)
https://github.com/mikernet/HttpCheckDnsServer
On 3/21/2019 5:42 AM, Tom Hendrikx wrote:
On 20-03-19 19:56, Mike Marynowski wrote:
A couple people asked about me posting the code/service so they could
run it on their own systems but I'm currently leaning away from that. I
don't
free to
do with the code as they wish.
Cheers!
Mike
On 3/21/2019 5:42 AM, Tom Hendrikx wrote:
On 20-03-19 19:56, Mike Marynowski wrote:
A couple people asked about me posting the code/service so they could
run it on their own systems but I'm currently leaning away from that. I
don't think
Continuing to fine-tune this service - thank you to everyone testing it.
Some updates were pushed out yesterday:
* Initial new domain "grace period" reduced to 8 minutes (down from 15
mins) - 4 attempts are made within this time to get a valid HTTP response
* Mozilla browser spoofing is
Thank you! I have no idea how I missed that...
On 3/13/2019 7:11 PM, RW wrote:
On Wed, 13 Mar 2019 17:40:57 -0400
Mike Marynowski wrote:
Can someone help me form the correct SOA record in my DNS responses
to ensure the NXDOMAIN responses get cached properly? Based on the
logs I don't think
Can someone help me form the correct SOA record in my DNS responses to
ensure the NXDOMAIN responses get cached properly? Based on the logs I
don't think downstream DNS servers are caching it as requests for the
same valid HTTP domains keep hitting the service instead of being cached
for 4
Any HTTP status code 400 or higher is treated as no valid website on the
domain. I see a considerable amount of spam that returns 5xx codes so at
this point I don't plan on changing that behavior. 503 is supposed to
indicate a temporary condition so this seems like an abuse of the error
code.
Back up after some extensive modifications.
Setting the DNS request timeout to 30 seconds is no longer necessary -
the service instantly responds to queries.
In order to prevent mail delivery issues if the website is having
technical issues the first time a domain is seen by the service, it
tay...@tnetconsulting.net>> wrote:
On 02/28/2019 09:39 PM, Mike Marynowski wrote:
> I modified it so it checks the root domain and all subdomains up to the
> email domain.
:-)
> As for your question - if afraid.org has a website then you are
correct,
> all subdomains of afraid.org wi
On 3/1/2019 4:31 PM, Grant Taylor wrote:
afraid.org is much like DynDNS in that one entity (afaid.org
themselves or DynDNS) provide DNS services for other entities.
I don't see a good way to differentiate between the sets of entities.
I haven't come across any notable amount of spam that's
On 3/1/2019 1:07 PM, RW wrote:
Sure, but had it turned-out that most of these domains didn't have the A
record necessary for your HTTP test, it wouldn't have been worth doing
anything more complicated.
I've noticed a lot of the spam domains appear to point to actual web
servers but throw 403
MTA.
On 3/1/2019 2:26 PM, Antony Stone wrote:
On Friday 01 March 2019 at 17:37:18, Mike Marynowski wrote:
Quick sampling of 10 emails: 8 of them have valid A records on the email
domain. I presumed SpamAssassin was already doing simple checks like that.
That doesn't sound like a good idea
SpamAssassin was already doing simple checks like that.
On 3/1/2019 10:23 AM, RW wrote:
On Wed, 27 Feb 2019 12:16:20 -0500
Mike Marynowski wrote:
Almost all of the spam emails that are
coming through do not have a working website at the room domain of
the sender.
Did you establish what fraction
Changing up the algorithm a bit. Once a domain has been added to the
cache, the DNS service will perform HTTP checks in the background
automatically on a much more aggressive schedule for invalid domains so
that temporary website problems are much less of an issue and invalid
domains don't
For anyone who wants to play around with this, the DNS service has been
posted. You can test the existence of a website on a domain or any of
its parent domains by making DNS queries as follows:
subdomain.domain.com.httpcheck.singulink.com
So, if you wanted to check if mail1.mx.google.com or
You'll be able to decide how you want to prioritize the fields - I've
implemented it as a DNS server, so which domain you decide to send to
the DNS server is entirely up to you.
On 2/28/2019 10:23 PM, Grant Taylor wrote:
On 2/28/19 9:33 AM, Mike Marynowski wrote:
I'm doing grabs the first
I modified it so it checks the root domain and all subdomains up to the
email domain.
As for your question - if afraid.org has a website then you are correct,
all subdomains of afraid.org will not flag this rule, but if lots of
afraid.org subdomains are sending spam then I imagine other spam
I'm pretty sure the way I ended up implementing it everything is working
fine and it's nice and simple and clean but maybe there's some edge case
that doesn't work properly. If there is I haven't found it yet, so if
you can think of one let me know.
Since I'm sending an HTTP request to all
Thunderbird normally shows reply-to in normal messages...is this
something that some MUAs ignore just on mailing list emails or all
emails? Because I see reply-to on plenty of other emails.
On 2/28/2019 3:44 PM, Bill Cole wrote:
On 28 Feb 2019, at 14:29, Mike Marynowski wrote:
Unfortunately
this as a cached DNS
service is just walk up the subdomains until I hit the root domain and
if any of them have a website then it's fine.
On 2/28/2019 2:39 PM, Antony Stone wrote:
On Thursday 28 February 2019 at 20:33:42, Mike Marynowski wrote:
But scconsult.com does in fact have a website so I'm
they are no risk of being blocked even if a non-website domain
triggers this particular rule.
On 2/28/2019 2:25 PM, Bill Cole wrote:
On 28 Feb 2019, at 13:43, Mike Marynowski wrote:
On 2/28/2019 12:41 PM, Bill Cole wrote:
You should probably put the envelope sender (i.e. the SA
"EnvelopeFrom&qu
r. I don't ever need 2
copies of a message posted to a mailing list, and ignoring that header
is rude.
On 28 Feb 2019, at 13:28, Mike Marynowski wrote:
On 2/28/2019 12:41 PM, Bill Cole wrote:
You should probably put the envelope sender (i.e. the SA
"EnvelopeFrom" pseudo-
On 2/28/2019 12:41 PM, Bill Cole wrote:
You should probably put the envelope sender (i.e. the SA
"EnvelopeFrom" pseudo-header) into that list, maybe even first. That
will make many messages sent via discussion mailing lists (such as
this one) pass your test where a test of real header domains
On 2/28/2019 12:41 PM, Bill Cole wrote:
You should probably put the envelope sender (i.e. the SA
"EnvelopeFrom" pseudo-header) into that list, maybe even first. That
will make many messages sent via discussion mailing lists (such as
this one) pass your test where a test of real header domains
about it...more spam catching for me and whoever
decides to install the plugin on their own servers. If it does become
widespread and some spammers adapt then I'll take solace in knowing I
helped a lot of people stop at least some of their spam.
* Mike Marynowski:
Everything we test
Why even use a test for something that is so easily compromised?
-Ralph
Everything we test for is easily compromised on its own.
And the cat and mouse game continues :)
That said, all the big obvious "email-only domains" that send out
newsletters and notifications and such that I've come across in my
sampling already have placeholder websites or redirects to their main
websites configured. I'm sure that's not always
I would not do it at all, caching or no caching. Personally, I don't see
a benefit trying to correlate email with a website, as mentioned before,
based on how we utilise email-only-domains.
-Ralph
Fair enough. Based on the sampling I've done and the way I intend to use
this, I still see
Question though - what is your reply-to address set to in the emails
coming from your email-only domain?
The domain checking I'm doing grabs the first available address in this
order: reply-to, from, sender. It's not using the domain of the SMTP
server. I did come across some email-only
Just one more note - I've excluded .email domains from the check as I've
noticed several organizations using that as email only domains.
Right now the test plugin I've built makes a single HTTP request for
each email while I evaluate this but I'll be building a DNS query
endpoint or a local
I've tested this with good results and I'm actually not creating any
HTTPS connections - what I've found is a single HTTP request with zero
redirections is enough. If it returns a status code >= 400 then you
treat it like no valid website, and if you get a < 400 result (i.e. a
301/302 redirect
Hi everyone,
I haven't been able to find any existing spam rules or checks that do
this, but from my analysis of ham/spam I'm getting I think this would be
a really great addition. Almost all of the spam emails that are coming
through do not have a working website at the room domain of the
31 matches
Mail list logo
