Paweł Leśniak a écrit : > mouss pisze: >> João Miguel Neves a écrit : >> >>> OK, I'll take that into consideration if I re-enable SAV. >>> >>> >> >> >> if you re-enable SAV, do as much checks as you can. the minimum is >> zen.spamhaus.org. but you can also use spamcop. >> >> it would also be good to do it after greylisting, but this means your GL >> server need to return a defer instead of defer_if_permit. >> >> what you can also do is run a log parser that counts the SAV probes you >> send, and disable the feature if some threshold is reached (rate limit >> per client network, per sender domain, and global). (an alternative is >> a policy server that implements this, but a log parser is enough). >> >> I was under the impression that you did it before zen check because the >> log you posted has a client listed in zen. but I now realize it may have >> been listed later. >> > And again my 5 cents. I think that people should take advantage of SPF > and/or DKIM records. If you'll check DKIM/SPF then you could for example > do SAV for clients/senders who are not allowed via SPF/DKIM or do not > provide those records. I believe this change is no cost for you, and is > saving some resources on both sides. Anyways whether you'll do SAV for > "bad" hosts or just reject emails from them is your choice. But no one > will blame you if you reject those emails, as you should be informed by > administrator (in terms of SPF/DKIM records) which hosts are permitted > to send (relay) - if you're given SPF record it should be correct, right? >
first, let's rule DKIM out of this. DKIM doesn't tell you "which hosts are permitted". And DKIM verification requires getting the message DATA. people want to reject a transaction before getting this data. In addition, doing verification based on data requires a milter or a proxy filter. second, many of us ignore SPF at once. if you think it is good, go on. but there will be no discussion on this list (it is taboo here. search the archives).
