spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Marynowski <mi...@singulink.com>
Subject Re: Spam rule for HTTP/HTTPS request to sender's root domain
Date Thu, 28 Feb 2019 14:25:39 GMT
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 or a 200 ok) then you can treat it like a valid 
website. You don't even need to receive the body of the HTTP result, you 
can quit after seeing the status.

And yes, as a 100% ban rule this is obviously a bad idea. As a score 
modifier I think it would be highly effective.

I found several "email only" domains in my sampling but all the big ones 
still had landing pages at the root domain saying "this domain is only 
used for serving email" or similar. I'm sure there are exceptions and 
some people will have email only domains, but that's why we don't put 
100% confidence into any one rule.

On 2/27/2019 7:57 PM, Grant Taylor wrote:
> On 02/27/2019 03:25 PM, Ralph Seichter wrote:
>> We use some of our domains specifically for email, with no associated 
>> website.
>
> I agree that /requiring/ a website at one of the parent domains 
> (stopping before traversing into the Public Suffix List) is 
> problematic and prone to false positives.
>
> There /may/ be some value to /some/ people in doing such a check and 
> altering the spam score.  (See below.)
>
>> Besides, I think the overhead to establish a HTTPS connection for 
>> every incoming email would be prohibitive.
>
> Why would you do it per email?  I would think that you would do the 
> test and cache the results for some amount of time.
>
>> There is a reason most whitelist/blacklist services use "cheap" DNS 
>> queries instead.
> I wonder if there is a way to hack DNS into doing this for us. I.e. a 
> custom DNS ""server (BIND's DLZ comes to mind) that can perform the 
> test(s) and fabricate an answer that could then be cached.  ""Publish 
> these answers in a new zone / domain name, and treat it like another RBL.
>
> Meaning a query goes to the new RBL server, which does the necessary 
> $MAGIC to return an answer (possibly NXDOMAIN if there is a site and 
> 127.0.0.1 if there is no site) which can be cached by standard local / 
> recursive DNS servers.
>
>
>



Mime
View raw message