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> 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
