[121179] in North American Network Operators' Group
Re: SORBS on autopilot?
daemon@ATHENA.MIT.EDU (Brian Keefer)
Tue Jan 12 14:28:25 2010
From: Brian Keefer <chort@smtps.net>
In-Reply-To: <20100112184859.GB12541@vt.edu>
Date: Tue, 12 Jan 2010 11:27:32 -0800
To: Dave Martin <darkmoon@vt.edu>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 12, 2010, at 10:48 AM, Dave Martin wrote:
> On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:
>> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote:
>> The vibe I got from a number of administrators I talked to about it =
was "why
>> would a standards document assume an IPv4/IPv6 unicast address is a =
residential
>> customer with a modem, forcing those with allocations to prove that =
they are
>> not residentially allocated rather than the other way around?"
>=20
> Because a default allow policy doesn't work in today's environment.
There are lots of other ways to deny that don't cause massive collateral =
damage. Allowing IPs with "suspicious" PTRs to attempt a connection =
doesn't mean their mail is delivered, or even that their connection will =
succeed. There are better ways to deny.
> Blocking generic and residential addresses is the single most =
effective
> thing we've ever done to reduce spam.
Not surprising, but at what cost of false positives? Maybe your =
organization is different, but the ones I talk to are much more worried =
about missing a single e-mail than blocking an extra 1,000.
> Most legit senders don't want to look like a compromised box in
> someone's bedroom anyway.
There are literally thousands of companies who don't grasp the =
difference, or have little ability to influence their appearance. I =
listen to the guy in the next cube over say "setup your RDNS" probably =
half a dozen times a day. He's lucky if they even understand what he =
said most of the time. Most people just do not grok DNS--even when =
they're given simple templates to fill out, cut, and paste they still =
manage to screw it up, or simply ignore it.
The membership of this list probably has one of the highest =
concentrations of DNS-clue in the world, but it's not representative of =
most organizations with an e-mail server.
--
bk=
