Re: RFC: Combined SURBL list details, phishing list ready
quinlan at pathname.com
Thu May 13 02:46:52 CEST 2004
Jeff Chan <jeffc at surbl.org> writes:
> 1. We had discussed two strategies for a combined list A records before:
We still don't really care as long as you don't it right. :-)
If you think you might end up supporting more than 32 return codes
(seems like a very remote possibility), separate A records is much
easier. Maybe that helps make up your mind.
> So the code using a combined list could be made to detect
> specific results, i.e., the specific list which triggered
> a matching A record could be determined, and not just that it
> matched "all" or any from the original list. On the other hand,
> the fact that matches from any list occurred may be good enough
> for some users. Personally I prefer more a detailed explanation
A more detailed explanation is merely the job of the client. If a
client can't handle multi-DNSBLs, then it's really behind the times.
Given that these clients are going to need to parse URIs and that is
non-trivial, I think you can just require multi-DNSBL support for newer
lists at some point if you want.
> 2. Another question would be the name of the combined list. Since
> there would be three or more lists, someone had suggested a name
> of "all" before. That sounds good to me unless there are other
"query" and "bl" are two somewhat more common names for a single
> 3. I'm assuming TXT records are no longer really feasible in a
> combined list and that descriptive messages will need to be
> signalled by the list (127. address) matched. I suppose it would
> be possible to create custom TXT records for every entry, but a
> generic TXT (or perhaps none) might be more likely. Is a generic
> TXT better than none? Even in a BIND file, where it incurs some
> use of space?
You could return a single URL that if loaded contains information about
exactly which lists hit. You can also return multiple TXT records that
can be matched as SpamAssassin rules (yes!), but unless you promise to
keep the format very very stable, then we'll just use the A records.
My suggestion: start with the A and worry about the rest later.
> 4. TTLs: If an entry has matches on more than one list, should
> it get a unique TTL? If so, should such a custom TTL on the
> multiply-matching entry be the longest TTL or the shortest TTL?
> I lean towards the inheriting the shortest TTL from the matching
> source list, plus setting a default TTL for the combined zone
> file to be near the longest.
Sounds fine to me.
> 5. We will likely want to combine the ws and be lists into a
> single entry in a combined list, probably using the .1 bit for
> both of them, since both lists contain the enumerated
> (non-wildcarded) domains from SA regular expressions. Also,
> things are moving towards combining the non-wildcarded domains
> sa-blacklist and BigEvil/MidEvil, so this would somewhat
> short-circuit that process and future-proof things.
As long as they have similar S/O ratios, I'm okay with it. If they are
maintained separately, it might shift the decision towards keeping them
separate, but if they're getting merged, then that makes more sense.
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
More information about the Discuss