Does SpamAssassin even have facilities to do that? Don't all rules run
all the time? SpamAssassin still needs to run all the rules because MTAs
might have different spam mark / spam delete /etc thresholds than the
one set in SA.
The number of cycles you're talking about is the same as an RBL lookup
so I really don't see it as being significant. The DNS service does all
the heavy lifting and I'm planning to make it public.
On 3/1/2019 5:09 PM, Rupert Gallagher wrote:
Case study:
example.com bans any e-mail sent from its third levels up, and does it
by spf.
spf-banned.example.com sent mail, and my SA at server.com adds a big
fat penalty, high enough to bounch it.
Suppose I do not bounch it, and use your filter to check for its
websites. It turns out that both example.com and
spf-banned.example.com have a website. Was it worth it to spend cycles
on it? I guess not. The spf is an accepted rfc and it should have
priority. So, I recommend the website test to first read the result of
the SPF test, quit when positive, continue otherwise.
--- ruga
On 3/1/2019 5:09 PM, Rupert Gallagher wrote:
Case study:
example.com bans any e-mail sent from its third levels up, and does it
by spf.
spf-banned.example.com sent mail, and my SA at server.com adds a big
fat penalty, high enough to bounch it.
Suppose I do not bounch it, and use your filter to check for its
websites. It turns out that both example.com and
spf-banned.example.com have a website. Was it worth it to spend cycles
on it? I guess not. The spf is an accepted rfc and it should have
priority. So, I recommend the website test to first read the result of
the SPF test, quit when positive, continue otherwise.
--- ruga
On Fri, Mar 1, 2019 at 22:31, Grant Taylor <gtay...@tnetconsulting.net
<mailto:gtay...@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 will not flag this rule, but if lots of
> afraid.org subdomains are sending spam then I imagine other spam
> detection methods will have a good chance of catching it.
ACK
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'm not sure what you mean by "working up the tree" - if afraid.org has
> a website and I work my way up the tree then either way eventually I'll
> hit afraid.org and get a valid website, no?
True.
I wonder if there is any value in detecting zone boundaries via not
going any higher up the tree past the zone that's containing the email
domain(s).
Perhaps something like that would enable differentiation between Afraid
& DynDNS and the entities that they are hosting DNS services for.
(Assuming that there are separate zones.
> My current implementation fires off concurrent HTTP requests to the
root
> domain and all subdomains up to the email domain and waits for a valid
> answer from any of them.
ACK
s/up to/down to/
I don't grok the value of doing this as well as you do. But I think
your use case is enough different than mine such that I can't make an
objective value estimate.
That being said, I do find the idea technically interesting, even if I
think I'll not utilize it.
--
Grant. . . .
unix || die
