Am 29.08.2014 um 04:26 schrieb Karsten Bräckelmann: > On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote: >> look at the attached zp-archive [...] > > Since I already had a closer look at the contents including your local > cf, and I am here to offer help and didn't mean no harm, some comments > regarding the SA config.
thanks >> # resolves a bug with milter always triggering a wrong informational header >> score UNPARSEABLE_RELAY 0 > > See the RH bug you filed and its upstream report. Do you still need > that? This would be the first instance of continued triggering of that > test I ever encountered. well, since there was no software update in the meantime i fear yes, however it don't harm >> # disable most builtin DNSBL/DNSWL to not collide with webinterface settings >> score __RCVD_IN_SORBS 0 >> score __RCVD_IN_ZEN 0 >> score __RCVD_IN_DNSWL 0 > > Rules starting with double-underline are non-scoring sub-rules. > Assigning a zero score doesn't disable them like it does with regular > rules. In the case of RBL sub-rules like the above, it does not prevent > DNS queries. It is better to > > meta __FOO 0 > > overwrite the sub-rule, rather than set a score that doesn't exist. thanks for the information, i will change that i verfified that it does *really* skip all of them because as i had only all sub-rules listed it still fired the request >> # unconditional sender whitelists >> whitelist_from *@apache.org >> whitelist_from *@bipa.co.at >> whitelist_from *@centos.org >> whitelist_from *@dovecot.org > [...] uhm i am not terrible happy to not have stripped that block from the config :-( > Unconditional whitelisting generally is a bad idea and might > appear in forged addresses. i know - i would love the same logic for senders as for MORE_SPAM_TO and ALL_SPAM_TO to and at the end even combine it From/To for mailing-lists you need a big hammer to be present if URIs are blacklisted or in case of security discussions refer to exploits which is not possible on the device i am about to replace which leads anytime something is on the zero-hour-intent-list appears in a message to override whitelists - like the name of the SA config file if some client wraps it in link headers something like that would be me final goal "from s...@a.tld to s...@b.tld -100" "from @a.tld to s...@b.tld -20" "from @a.tld to s...@b.tld -2" which would give a way to implement dropdowns in the admin backend for different trust levels without need to know the underlying scores which could be adjusted transparent since it may make sense to do so in the context of tag-score/block-score in general after going online and analyze things my intention will be "no whitelists at all active" but only after some time where i can make sure from logs there are no false positives which are more bad than slipped spam but have known working options if needed > If possible, it is strongly suggested to use whitelist_from_auth, or at > least whitelist_from_rcvd (which requires *_networks be set correctly) oh - fine, that pretty easy, the config is generated from a webUI based script - the networks are correct now, that was only a temporary thing in the other thread to study behavior with hand-written craft before write backends and find out that i can't implement it later as expected "whitelist_from_rcvd" i already had in mind, but since only my personal domain is live i rely at forging by myself for testing things out
signature.asc
Description: OpenPGP digital signature
