It would reduce overall traffic and ease administration to include it in multi
One thing that I failed to explain is that the software I use DOES report the return code, but was constructed to work with SURBL without giving a lot of thought to the idea of doing different things based particular return codes. It reports the SURBL code for every "hit" in the log files, but within the programming logic, the variable that can be acted on is assigned more of a yes/no as to whether or not there was a single valid hit.
Therefore, not every SURBL has the option to do different things based on the return code. Also, it would be EASY... very easy... for an administrator who DOES have option to do different things based on return codes to not exercise these options and block ALL multi stuff, regardless of the return code. (All administrators are not going to be SURBL gurus)
Rob McEwen
OK, OK... How about an "evilmulti" that included "unconfirmed", which would increase surbl's data size and processing-- having to build two multi lists, but would significantly reduce DNS query traffic since those using the "unconfirmed" list and the "multi" list could use a single query per URI instead of 2 per URI.
Bret ----------
Send your spam to: bretmiller@wcg.org Thanks for keeping the internet spam-free!
Hi!
OK, OK... How about an "evilmulti" that included "unconfirmed", which would increase surbl's data size and processing-- having to build two multi lists, but would significantly reduce DNS query traffic since those using the "unconfirmed" list and the "multi" list could use a single query per URI instead of 2 per URI.
People locally can even build multi's by just adding the extra list on the surbl dataset you are loading. But in general it would mean more overhead on the nameservers. Since they have another 'large' zone to serve... Nice idea however.
Bye, Raymond.
On Thursday, September 2, 2004, 10:12:42 AM, Rob McEwen wrote:
It would reduce overall traffic and ease administration to include it in multi
One thing that I failed to explain is that the software I use DOES report the return code, but was constructed to work with SURBL without giving a lot of thought to the idea of doing different things based particular return codes. It reports the SURBL code for every "hit" in the log files, but within the programming logic, the variable that can be acted on is assigned more of a yes/no as to whether or not there was a single valid hit.
Therefore, not every SURBL has the option to do different things based on the return code. Also, it would be EASY... very easy... for an administrator who DOES have option to do different things based on return codes to not exercise these options and block ALL multi s tuff, regardless of the return code. (All administrators are not going to be SURBL gurus)
Yes, I know of programs using multi that do not differentiate what lists the hits came from or report that to the user.
Obviously including a greylist into multi in that context would be a bad idea since it would be impossible to distinguish black from grey hits.
Jeff C.
-
Bret Miller -
Jeff Chan -
Raymond Dijkxhoorn -
Rob McEwen