On 1/4/2011 11:14 AM, David F. Skoll wrote:
> On Tue, 04 Jan 2011 11:01:52 -0500
> Rob McEwen wrote
>> I've thought this through and... best case scenario is that spammers
>> then get 5+ years of play time because it will take at least that time
>> for those other techniques to catch up.
> Umm.. n
Funny thing, and I think John Levine remembers 1994:
OH MY GOD, THE INTERNET WENT COMMERCIAL, with all these new computers,
its the end of the internet.
and the oft quoted:
"Breaking Story: Death of the Internet, gif at 11"
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259
On 01/05/2011 05:14 AM, David F. Skoll wrote:
> On Tue, 04 Jan 2011 11:01:52 -0500
> Rob McEwen wrote:
>
>> When we are left with only whitelists and no blacklists, an
>> interesting problem will happen... there will be extreme prejudice
>> against ALL new IPs not already whitelisted.
> Life will
>In summary, I believe DNS caching is basically *useless* for any site
>small enough to use Spamhaus for free. And any very large site is
>probably large enough to deserve an rsync feed.
Hmmn. See the ASRG list where I've posted some numbers I worked up
from my own servers.
R's,
John
>This is a great topic! Is this been discussed at the IETF level?
Well, yeah, that's the internet draft that I started this with.
There's a parallel discussion in the IETF anti-spam research group
(ASRG) which is a better place to continue this.
See http://wiki.asrg.sp.am/ which has a link to su
On Tue, Jan 4, 2011 at 9:24 PM, David F. Skoll wrote:
> (Spamhaus could greatly lower the load on its servers by using much
> bigger TTLs, especially for lists that don't change often like the PBL.
> But as another posted mentioned, sometimes DNSBL owners want to see
> the queries, particularly i
Following up on myself...
> I ran a little experiment.
Just for fun, I took a day's worth of logs from a fairly busy server.
There were just over 3.1 million SMTP connections/day. If they'd been
using a DNSBL with a 15-minute TTL, they would have had about 1.13 million
cache misses and 1.97 mill
On Tue, 4 Jan 2011 06:18:55 -0800 (PST)
John Hardin wrote:
[DFS says all queries should be to authoritative name servers to avoid
cache blowouts.]
> You can't compare them. The nature of the queries is vastly different
> - the root nameservers only get queries like "where are the
> authoritative
On Tue, 04 Jan 2011 11:01:52 -0500
Rob McEwen wrote:
> When we are left with only whitelists and no blacklists, an
> interesting problem will happen... there will be extreme prejudice
> against ALL new IPs not already whitelisted. This will create a
> "chicken/egg" problem whereby a new startup c
Le 04/01/2011 17:01, Rob McEwen a écrit :
I've thought this through and... best case scenario is that spammers
then get 5+ years of play time because it will take at least that time
for those other techniques to catch up. Great damage will happen in the
meantime.
That scenario assumes rapid ado
On Tue, 04 Jan 2011 11:01:52 -0500
Rob McEwen wrote:
> I've thought this through and... best case scenario is that spammers
> then get 5+ years of play time because it will take at least that time
> for those other techniques to catch up.
Umm.. no. We have plenty of effective techniques we're u
On 1/4/2011 10:43 AM, David F. Skoll wrote:
> I agree that it's probably eventually "game over" for DNSBLs, but not
> for DNSWLs. DNSBLs are a pretty effective first-line defense against
> spam, but they will gradually become less and less effective as IPv6
> becomes more heavily adopted. That ju
On Tue, 4 Jan 2011, David F. Skoll wrote:
On Tue, 4 Jan 2011 06:18:55 -0800 (PST)
John Hardin wrote:
DNS needs to deal with an exponentially-increased address space
regardless of how RBLs behave. Perhaphs DNS caching needs to be
partitioned so that a huge number of queries on *.spamhaus.org d
On Tue, 04 Jan 2011 10:34:43 -0500
Rob McEwen wrote:
> "game over".. the spammers have already won. And they are quite amused
> right now reading us discuss all different ways to rearrange the deck
> chairs on the Titanic.
We are talking at cross-purposes here, but I think we mostly agree. :)
>
On 1/4/2011 9:31 AM, David F. Skoll wrote:
> Right, but once your cache is blown, you're back to always querying
> the authoritative server. John Levine proposes a fix with a clever way
> to represent many entries with a small number of queries so you don't blow
> your cache. I think making zone
On Tue, 4 Jan 2011 06:18:55 -0800 (PST)
John Hardin wrote:
> DNS needs to deal with an exponentially-increased address space
> regardless of how RBLs behave. Perhaphs DNS caching needs to be
> partitioned so that a huge number of queries on *.spamhaus.org don't
> blow everything else out of the c
On Tue, 4 Jan 2011, David F. Skoll wrote:
If the problem is blowing DNS caches, then one solution is to query only
authoritative name servers.
After all, the total volume of DNS[BW]L queries from mail servers even
without caching is probably very much less than the total volume of
queries that
A couple more cents on this topic...
If the problem is blowing DNS caches, then one solution is to query only
authoritative name servers.
Spamhaus, for example, permits 300,000 free queries per day. I bet
many small sites will be under this limit even if they query Spamhaus
directly with no cach
On 1/4/2011 1:57 AM, John Levine wrote:
> I also don't think it's very realistic to expect that there will
> be a master mail host file distributed periodically like HOSTS.TXT
> was. There's a reason that the DNS was invented, and at the time it
> was, there were a whole lot less hosts on the net
On Mon, Jan 3, 2011 at 9:27 PM, Jason Haar wrote:
> On 01/04/2011 04:50 PM, Dave Pooser wrote:
> > Frankly, I'd think that besides costing the spammers money (a good thing
> in
> > and of itself)
> ...spammers steal other people's resources - so they'll pay nothing...
> The best case scenario we
On Tue, Jan 4, 2011 at 8:27 AM, Jason Haar wrote:
> This is a great topic! Is this been discussed at the IETF level? This is
> much bigger than SA. From the sounds of this thread, spam under ipv6 is
> going to be almost an *infinitely* bigger problem than ipv4. What about
The IETF is where it's
On 01/04/2011 04:50 PM, Dave Pooser wrote:
> Frankly, I'd think that besides costing the spammers money (a good thing in
> and of itself)
...spammers steal other people's resources - so they'll pay nothing...
The best case scenario we can ever hope for is that they will be stuck
sending all their
>Frankly, I'd think that besides costing the spammers money (a good thing in
>and of itself) it would also be a pretty good spamsign if a block has more
>than, say, 5 or so registered senders in a /64. Just thinking out loud
>here
There are a lot of non-spam mail systems with a heck of a lot m
On 1/3/11 9:34 PM, "Rob McEwen" wrote:
> BTW - Ironically, it is all the more of an upside that spammers could freely
> pay registrars for as many IPs to have "SMTP designation" as desired because,
> quite frankly, that is a lesser evil than the registrars ever getting
> "political" about who get
On 1/3/2011 9:21 PM, Dave Pooser wrote:
> Not to speak for Rob, but...
Dave,
You described my point quite well and I appreciate your help! What I
described is vastly different than whitelisting and has massive
"upsides". I haven't yet found any noteworthy downsides.
Overall, this discussion thre
Not to speak for Rob, but...
> Haven't you just reinvented whitelisting? I think it's pretty likely
> that people will make lists of IPs known to be mail clients to keep
> down the filtering load, but there's still the problem that bad guys
> can sign up so you have endless compliance problems.
>Please reconsider... and how about this twist...
>
>Let the IP registrars (arin.net, etc) add a very nominal fee for
>allowing networks to designate particular IPs as being used for SMTP.
Haven't you just reinvented whitelisting? I think it's pretty likely
that people will make lists of IPs know
John Levine said:
>> Rob McEwen said:
>>
>> To be extra clear, the kind of sender's list I was talking about
>> wouldn't be the same as a yellowlist because it would ALL types of IPs
>> (black, white, yellow). Except everyone... including spammers... would
>> have to jump through some hoops to get
>And SMTP is the same philosophy. Unicode addressing should rightly be
>an add-on to a simpler system. And frankly the biggest proponent of
>EAI is China - and why do you think that this is?
Silly me, I thought it was because they have 1.2 billion citizens
who read and write Chinese rather than
Ted Mittelstaedt wrote:
> End users all over most of the world WANT to interact with foreigners.
End users all over the world primarily want to interact with family and
friends, 95% of which speak the same language and live in the same
country.
> They DO NOT want to have the Internet on their
Ted Mittelstaedt writes:
> No, since the number of total host numbers in a /64 is vastly larger
> than in a /128, if you hold to single number queries then it will blow
> it out far far faster.
>
> This is why I said SA needs to be modified to treat a single hit in a
> /64 as the entire /64 is c
Hi, all,
We run a system of data collection that collects reputation information
about IP addresses. Our system has data on over 18 million IPv4 addresses
and 2658 IPv6 addresses (which shows how poor the penetration of IPv6
is.) For details of our system, see http://mimedefang.org/reputation
A
On 12/30/2010 9:49 PM, John R Levine wrote:
I'm not wedded to the CNAME hack.
Actually, I was thinking about that. Consider a hack on a DNS server
that gives all records an absolute expiry time that marches forward
in (say) 5-minute intervals. Then when the DNS server is queried,
the TTL is com
I'm not wedded to the CNAME hack.
Actually, I was thinking about that. Consider a hack on a DNS server
that gives all records an absolute expiry time that marches forward
in (say) 5-minute intervals. Then when the DNS server is queried,
the TTL is computed to be the difference between the curr
On 12/30/2010 8:10 PM, David F. Skoll wrote:
So assume a spammer has 1,000 botnet nodes, each of which has 2^64 possible
IPv6 addresses. Explain how you can efficiently detect such cycling and block
it.
Well perhaps not efficiently but the RBL has got to step up to the
plate and do some mo
On Thu, 30 Dec 2010 19:21:25 -0800
Ted Mittelstaedt wrote:
> No, I am assuming the spammers will do as they have always done in the
> past - attempt to use other people's computers for free. Other
> computers that are NOT cycling through lots of IP number in the
> normal case.
That's because t
On Thu, Dec 30, 2010 at 5:21 PM, Ted Mittelstaedt wrote:
> On 12/30/2010 5:43 PM, John Levine wrote:
>
>> Ah, I see the problem. You're assuming that spammers will follow the
>> rules. That's a poor assumption.
>>
>>
> No, I am assuming the spammers will do as they have always done in the
> pas
On 12/30/2010 5:43 PM, John Levine wrote:
Ah, I see the problem. You're assuming that spammers will follow the
rules. That's a poor assumption.
No, I am assuming the spammers will do as they have always done in the
past - attempt to use other people's computers for free. Other
computers th
On 31 Dec 2010 01:19:16 -
John Levine wrote:
> >Now obviously, there's a breakpoint at which synchronizing the local
> >database from the master becomes cheaper than doing lookups. Right
> >now, that's quite high, but it will move lower with IPv6.
> Why do you say that? The number of compu
On 30 Dec 2010 17:49:46 -0500
"John R Levine" wrote:
[...]
> I'm not wedded to the CNAME hack.
Actually, I was thinking about that. Consider a hack on a DNS server
that gives all records an absolute expiry time that marches forward
in (say) 5-minute intervals. Then when the DNS server is quer
Ah, I see the problem. You're assuming that spammers will follow the
rules. That's a poor assumption.
>> The IPv6 address space is big. Very, very big. Even if you chop it
>> in half to /64s, it is still four billion times bigger than the v4
>> address space. Bad guys hopping around /64s will
>Now obviously, there's a breakpoint at which synchronizing the local
>database from the master becomes cheaper than doing lookups. Right
>now, that's quite high, but it will move lower with IPv6.
Why do you say that? The number of computers on the net isn't going
to be much bigger with IPv6. T
On 12/30/2010 9:13 AM, John Levine wrote:
Hi. I hear there's been some interest in my IPv6 DNSBL proposal. My
goal is that since there are (close enough to) no v6 BLs or WLs yet,
this is the time to switch to a query design that will scale. The
design I put in RFC 5782 isn't it, unfortunately,
John, I agree that your draft is clever. But I think it's really
stretching DNS way beyond what it was designed for and it might be
time to look at a different approach. To paraphrase the old saying,
when all you have is DNS, every problem looks like a lookup.
I agree that it's sort of an odd
To be extra clear, the kind of sender's list I was talking about
wouldn't be the same as a yellowlist because it would ALL types of IPs
(black, white, yellow). Except everyone... including spammers... would
have to jump through some hoops to get a single IP that list. But this
/then/ VASTLY lowers
> John, I agree that your draft is clever. But I think it's really
> stretching DNS way beyond what it was designed for and it might be
> time to look at a different approach. To paraphrase the old saying,
> when all you have is DNS, every problem looks like a lookup.
To be honest, my first reac
On 12/30/2010 2:28 PM, David F. Skoll wrote:
> I in no way implied that we should abandon
> IP address lookups in favour of only content-scanning
Thanks for the clarification!
--
Rob McEwen
http://dnsbl.invaluement.com/
r...@invaluement.com
+1 (478) 475-9032
On Thu, 30 Dec 2010 14:18:13 -0500
Rob McEwen wrote:
> On 12/30/2010 2:09 PM, David F. Skoll wrote:
> > But I think it's really
> > stretching DNS way beyond what it was designed for and it might be
> > time to look at a different approach.
> But David, every example you've provided requires vas
On 12/30/2010 1:55 PM, John Levine wrote:
> it will clearly also be useful to
> have what was called a yellow list a few days ago, hosts that send
> enough real mail that you can't just blacklist them even if you see
> some spam.
John,
First, let me mention that I'm grateful that you are working
>>(3) A shifting of focus on whitelists is important... but some of those
>>shouldn't really be "whitelists" in the traditional sense. Instead, they
>>should merely indicate that an IP is a candidate for sending mail.
>
> This one I agree with. The Spamhaus whitelist is intended only for
> very vi
On 12/30/2010 2:09 PM, David F. Skoll wrote:
> But I think it's really
> stretching DNS way beyond what it was designed for and it might be
> time to look at a different approach.
But David, every example you've provided requires vastly more resources
then blocking a spam with a single DNS lookup
(Same error on this mail, I should pay more attention to To: and the
reply button. Sorry for the mess)
On Thu, Dec 30, 2010 at 8:10 PM, Matthias Leisi wrote:
> On Thu, Dec 30, 2010 at 7:43 PM, John Levine wrote:
>
>>>Any protocol that makes lookups in a huge adress space efficient and
>>>efficie
(Sorry, sent to David only by error)
On Thu, Dec 30, 2010 at 8:05 PM, Matthias Leisi wrote:
> On Thu, Dec 30, 2010 at 7:26 PM, David F. Skoll
> wrote:
>
>> The real problem is the human effort needed to monitor the enormous IPv6
>> address spave for abuse. I think it'll be hard or impossible t
On 30 Dec 2010 18:57:44 -
John Levine wrote:
> Hey! I have an idea! How about if we form the data into a B-tree and
> let people download pages on demand via the DNS?
Nah, I have a better idea... a "B-ish" tree where some nodes can get
out of sync because of caching. Won't be a problem in
>I used rsync as an example. You can use a more efficient technique; I
>gave ClamAV's signature-distribution mechanism as an example of a
>system that works pretty well.
Hey! I have an idea! How about if we form the data into a B-tree and
let people download pages on demand via the DNS?
R's,
J
>If blacklists like CBL are currently at 100 MBs (for IPv4)... the bloat
>for IPv6 could break DNSBLs. RSYNCing Gigabyte (or terabyte!) -sized
>files is memory and CPU intensive. Loading those into rbldnsd is also
>resource expensive! Furthermore, getting that data out to DNS mirrors
>quickly and e
On 30 Dec 2010 18:43:50 -
John Levine wrote:
> >I agree, so I propose a much larger change: Stop using DNS for this
> >purpose. I don't think it's the right tool for the job.
> Sigh. Yes, that's one of the bad ideas.
What is? Using DNS or using something else? :)
[...]
> Consider the a
On Thu, 30 Dec 2010 10:36:59 -0800 (PST)
John Hardin wrote:
> Timeliness? How often are you going to refresh the local copy of the
> entire WL/BL? Or are you assuming the WL/BL will be relatively
> unchanging over time?
A WL should be relatively unchanging over time. I doubt BLs will be
useful
>I agree, so I propose a much larger change: Stop using DNS for this
>purpose. I don't think it's the right tool for the job.
Sigh. Yes, that's one of the bad ideas.
Remember that part of the goal is to keep the traffic to and from the
DNSBL/WL's servers under control.
>Any protocol that makes
On Thu, 30 Dec 2010, David F. Skoll wrote:
On 30 Dec 2010 17:13:07 -
John Levine wrote:
We'll have to change our software to handle v6 lookups no matter what,
so I don't see it as a big deal whether it's a small change or a
slightly larger change.
I agree, so I propose a much larger cha
On Thu, 30 Dec 2010 13:34:16 -0500
Rob McEwen wrote:
> Does John's system do anything to prevent a spammer from sending a
> million different spams from a million different IPs (one-ip-per-spam)
> ...with that IP never to be heard from again)?
Well, obviously not. Nothing can control what a spa
On 12/30/2010 1:26 PM, David F. Skoll wrote:
> Well, not really... John Levine proposes a way to summarize swaths
> of IPv6 address space into very little storage, so that shouldn't be
> an issue. While I'm not crazy about using DNS for this purposes,
> John's basic ideas are correct.
>
> The real
On Thu, 30 Dec 2010 13:19:03 -0500
Rob McEwen wrote:
> If blacklists like CBL are currently at 100 MBs (for IPv4)... the
> bloat for IPv6 could break DNSBLs. RSYNCing Gigabyte (or terabyte!)
> -sized files is memory and CPU intensive.
Well, not really... John Levine proposes a way to summarize s
On 12/30/2010 12:47 PM, David F. Skoll wrote:
> On 30 Dec 2010 17:13:07 -
> John Levine wrote
>> We'll have to change our software to handle v6 lookups no matter what,
>> so I don't see it as a big deal whether it's a small change or a
>> slightly larger change.
> I agree, so I propose a much
On 30 Dec 2010 17:13:07 -
John Levine wrote:
> We'll have to change our software to handle v6 lookups no matter what,
> so I don't see it as a big deal whether it's a small change or a
> slightly larger change.
I agree, so I propose a much larger change: Stop using DNS for this
purpose. I d
Hi. I hear there's been some interest in my IPv6 DNSBL proposal. My
goal is that since there are (close enough to) no v6 BLs or WLs yet,
this is the time to switch to a query design that will scale. The
design I put in RFC 5782 isn't it, unfortunately, nor is anything
similar to it.
We'll have
On Thu, Dec 30, 2010 at 12:42 AM, Ted Mittelstaedt wrote:
> Thus, we can safely make the assumption that any mailserver is going
> to follow the model of a single host per /64. Thus it will ALSO be
> just as useful for whitelists to have the same granularity - a /64 -
> as it would be for blackl
I think the biggest problem with his draft is the following:
For blacklists, an obvious approach would be to limit the granularity
of DNSBLs, so that, say, each /64 had a separate listing, and the
queries only used the high 64 bits of each address. While this might
limit the damage from
Hi all,
I'm not sure whether that would be more appropriate for the dev list,
but I guess this is relevant/of interest to the SpamAssassin project,
and I don't know whether this has caught attention here yet.
John in his draft mentioned below is very right to point out that
simply applying the IP
69 matches
Mail list logo
