Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation mentions obsolete monitored_domain config item #542

Open
okapia opened this issue Jan 3, 2022 · 7 comments
Open

Documentation mentions obsolete monitored_domain config item #542

okapia opened this issue Jan 3, 2022 · 7 comments

Comments

@okapia
Copy link

okapia commented Jan 3, 2022

In the documentation for the RBL module, it mentions that monitored_domain can be set to "INVALID". My attempts to probe what effect this has exactly didn't get very far so I had to search for it in the rspamd sources. The only match in a recursive grep is in an old ChangeLog entry. Probing git sources implies that the last reference was removed when the C version of the module was removed - I guess that was deprecated in favour of a lua module.

If I am correct in my conclusion that this feature has been removed, could it perhaps also be removed from the documentation.

Otherwise, it isn't entirely clear to me whether this was doing a RBL query for the literal domain "INVALID" or whether that value has a specific meaning. And what this would mean where queries for an IP are expected. The initial reason, I looked into this is that I was informed that a system I maintain was doing queries for 127.0.0.1 which was assumed to be a configuration mistake. I suspect the actual cause was this monitoring but was unsure whether the best course of action was to set disable_monitoring = true or to set monitored_domain. The documentation could provide more clue as to what effect this "monitoring" has. If the query fails, does it just log something or does it disable that block list, either for a set period or until rspamd is restarted? And with what regularity is the monitoring performed?

@vstakhov
Copy link
Member

I have updated the documentation to the actual state, thank you!

@vstakhov vstakhov transferred this issue from rspamd/rspamd Jan 14, 2022
@slavkoja
Copy link

Except, that it doesn't work as described, i have two (beside others) domain RBL defined:

  spamhaus_zrd {
    rbl             = "<mykey>.zrd.dq.spamhaus.net";
    no_ip           = true;
    checks          = ["helo", "rdns" ]
  }

  ZRD {
    rbl             = "<mykey>.zrd.dq.spamhaus.net";
    ignore_defaults = true;
    no_ip           = true;
    checks          = ["emails", "replyto", "urls", "dkim"]
    emails_domainonly = true;
  }

(return codes excluded) Thus both have set no_ip, but monitoring tells:

2022-01-15 11:19:16 #22854(controller) <hi7upk>; monitored; \
    rspamd_monitored_dns_cb: DNS reply returned 'no error' for <mykey>.dbl.dq.spamhaus.net \
    while 'no records with this name' was expected when querying for \
    '1.0.0.127.<mykey>.dbl.dq.spamhaus.net'(likely DNS spoofing or BL internal issues)

As you can see, the IP is checked, not random string, or something extra is needed to setup?

@slavkoja
Copy link

Seems, that mentioned check is triggered by the spamhaus_zrd rule, as disabling monitoring for it helps.

@vstakhov
Copy link
Member

Yes, exactly. The first rule does not imply random checks according to both the docs and the current implementation. Presumably, I should improve the logic for that as well.

@vstakhov
Copy link
Member

vstakhov commented Jan 15, 2022

I have improved that in b93688875

@slavkoja
Copy link

IMO, simplest can be opposite check, if RBL has from or received checks (IMO no_ip implies all to false), return false for random, i.e. use 127.0.0.1 for checks...

As here are composite RBLs able to check both IP & domains, using static string for checks can simplify things...

@okapia
Copy link
Author

okapia commented Jan 16, 2022

That looks clearer in the updated documentation, thanks!

In the updated example, indentation on closing braces doesn't match indentation on their corresponding opening lines but the intent is clear enough.

moisseev added a commit that referenced this issue Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants