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
Hi,
Lately, I notice we are getting a fair amount (10-12 per day per client)
of spam coming from freemail users (FREEMAIL_FROM triggers). Usually the
Subject is non-existent or empty, and the message is always just an URL
Is there a good rule for flagging these as possible spam? I understand
(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
At 03:53 PM 12.30.2010 +0100, Benny Pedersen wrote:
>On tor 30 dec 2010 15:45:10 CET, "Jack L. Stone" wrote
>
>> Ooops! that module "body_0.pm" not body_500.pm
>
>yes sa-compiles pt priority rules
>
>body foo /foo/
>priority foo 500
>body bar /bar/
>priority bar 100
>
>when no priority 0 is used
>
On 2010/12/30 7:49 AM, David F. Skoll wrote:
Actually... is anyone on the list aware of an IPv6 provider that assigns
less than a /64 to end-users? My tunnel broker gives us a /64 for our tunnel
and a routed /48 for our network. Our hosting provider gives us a /64
for each host. Anyone on the
On tor 30 dec 2010 15:45:10 CET, "Jack L. Stone" wrote
Ooops! that module "body_0.pm" not body_500.pm
yes sa-compiles pt priority rules
body foo /foo/
priority foo 500
body bar /bar/
priority bar 100
when no priority 0 is used
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
TOP POST correction
Ooops! that module "body_0.pm" not body_500.pm
Jack
At 08:33 AM 12.30.2010 -0600, Jack L. Stone wrote:
>I've just caught up with another issue noticed when manually running some
>spam through SA.
>
>Perhaps I have an obsolete module - "body_500.pm" perhaps that's causing
this
On tor 30 dec 2010 15:33:41 CET, "Jack L. Stone" wrote
Perhaps I have an obsolete module - "body_500.pm" perhaps that's
causing this?
sa-update
sa-compile
restart spamd (if used)
try again :-)
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
I've just caught up with another issue noticed when manually running some
spam through SA.
Perhaps I have an obsolete module - "body_500.pm" perhaps that's causing this?
Dec 30 08:27:56.192 [10711] dbg: zoom: loading compiled ruleset from
/var/db/spamassassin/compiled/5.008/3.003001
Dec 30 08:27:
On Thu, 30 Dec 2010 10:15:42 +0100
Matthias Leisi wrote:
> Can you be really, absolutely sure that there will never, ever be a
> need to report reputation on anything else than /64?
I think it's a safe bet, especially for whitelists. If you're
whitelisting someone, chances are that person knows
On Wed, 29 Dec 2010 15:42:58 -0800
Ted Mittelstaedt wrote:
> What this really calls for is a reworking of the SpamAssassin code.
> SA is going to have to start caching the results of any IPv6 DNS
> BL queries for a set period of time, probably 2 days.
Why? Isn't caching the results of queries t
On ons 29 dec 2010 18:33:25 CET, Marc Perkel wrote
I would skip test if they have SPF because spammers often set their
SPF correctly.
stop this throlling, spammers dont add whitelist_from_spf into spamassassin
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
On ons 29 dec 2010 18:24:00 CET, Matt wrote
So any email from hotmail.com, gmail.com, yahoo.com, etc. if there SPF
or DKIM passes skip any further DNS tests?
blind testing if sender is one of them, dont do more mta testing ?
if wanting to reduce load on sa then whitelist from spf or dkim, and
Mark Martinec wrote:
> On Wednesday December 29 2010 20:05:20 Per Jessen wrote:
>> How about the case of rejecting/scoring obviously forged senders?
>> I.e. "from-address = facebook.com" and "dkim verification completed,
>> but failed". That is a pretty good reason for a high score or a
>> reject
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
47 matches
Mail list logo
