Steven M. Bellovin wrote:
It will be a few days before I can look at the code, but I don't see a
privacy policy on the web page. What, if anything, is done with the
data collectible by your servers?
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Odd, I can see one
Rich Kulawiec wrote:
More bluntly: the closed-source, faith-based approach to security
doesn't cut it. The attacks we're confronting are being launched
(in many cases) by people who *already have the source code*, and
who thus enjoy an enormous advantage over the defenders.
TBH though, usually
Sean Donelan wrote:
Selling people barn doors and barn door audits is easier than figuring
out how the rustlers are getting the horses. The problem is the horses
aren't being rustled(?) through the barn doors. If they were, you would
expect to see a difference between barns with doors and barns
John Curran wrote:
If you're asserting that having firewalls in the path doesn't have
any impact on rate of infection, please provide a link to this data.
Actually, it doesn't - practical experience on a medium sized corporate
network is that the firewall protects perfectly against TCP/IP worms -
Per Gregers Bilse wrote:
Just because one can find a counter argument against an argument
doesn't mean the original argument is invalid.
Sometimes it does :)
disproof by counterexample is a valid technique.
Erik Haagsman wrote:
Spammers can only work when making enormous amounts of connections
each hour, so limiting a normal user to 10 connections per hour with
some extra slack after two or three connectionless hours, with an hour
blocking penalty if the user goes over shouldn't pose a problem
Joshua Brady wrote:
The Child you speak of caused destruction over a network, the same
applied for the 2 hackers here who were sent over without even
questioning the UK. If the US Government is Satan then I suppose I am
going to hell, because I sure as hell support it.
Oh, so do I - I just
Jeffrey Paul wrote:
Perhaps I'm being naïve, but this seems like a very good way to cause
spammers to suddenly start having valid PTR RRs. Thoughts?
or limiting attacks for relay/proxy/trojan purposes targets that have valid
PTR records which of course ideally should be all of them.
Brian Bruns wrote:
My favorite quote is...
BG: Until we had this concept of Web services, software on the
Internet couldn't talk to other software on the Internet. The only
thing that worked was you could move bits - that's TCP/IP -
or you could put up screens - that's HTML - but
[EMAIL PROTECTED] wrote:
I don't see how that is the same thing here. I have an
agreement with cust X to provide services in accordance with
my AUP. cust X resells that service to cust Y, etc. cust Y
is bound to the terms and conditions of my agreement with
cust X, despite that I do not
Avleen Vig wrote:
If more IP addresses is the only motivation for using IPv6, it's
really not enough. For environments where direct access to the
internet isn't required, NAT serves perfectly well.
IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT,
doesn't it?
Simon Lockhart wrote:
Anything that relies on knowing which host it is talking to by
looking at the source address of packets breaks.
Indeed. Novell networking for example - or MS Exchange New Mail
notification. of course, you shouldn't be doing either on the internet,
but a common small
Avleen Vig wrote:
Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at least in most
multi-site enterprises i've seen).
Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at
Kuhtz, Christian wrote:
And there are workarounds for all those.
NAT-T for ipsec is really intended for endnodes only - which is fine if
you are doing the NAT yourself (typical medium/large company scenario -
internal users shouldn't be using IPSEC, that is done at the
gateway/firewall) but
Kuhtz, Christian wrote:
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session). Works great.
Yup. there are various proprietary solutions that require us to trash out
an expensive and *working* VPN-1 solution, buy an equally
Kuhtz, Christian wrote:
Kuhtz, Christian wrote:
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session).
Works great.
Yup. there are various proprietary solutions that require us
to trash out an expensive and *working* VPN-1
Crist Clark wrote:
Unless your AV software has a clue, like most do, and unzips archives
and see what's inside.
which is ideal for virus scanning, but not for blanket-blocking of email.
A zipped archive containing an executable cannot (unless something has
changed that I don't know about) be
I am not sure I am following the argument here.
as far as I can make out
1. Many (all!) providers underprovision (aka oversell) their bandwidth,
expecting peak utilisations to be approximately the provisioned amount
because experience has shown that actual usage is only a percentage of
shnipp Data Protection stuff
At least theoretically, the US *is* supposed to have a comparable system.
European privacy law makes it illegal to transfer personal data of any kind
to a country without a comparable system - the US has a voluntary Safe
Haven scheme that is supposed to enable US
E.B. Dreger wrote:
Date: Sun, 26 Jan 2003 00:22:02 -0500 (Eastern Standard Time)
From: Alex Rubenstein
Agreed. And, even if it is super encrypted, who cares? Enough
CPU and time will take care of that.
Articles about 1000 years to crack using brute force are a bit
disconcerting if
Your not my customer I really don't care *click*
Nice. professional too.
I had a similar experience with them - even though we *are* a UUNet
customer, we weren't the customer with the problem (in this case, a email
address which was a subdomain of the company's main address was being
rejected
21 matches
Mail list logo
