[146039] in North American Network Operators' Group
Re: Outgoing SMTP Servers
daemon@ATHENA.MIT.EDU (Brian Johnson)
Mon Oct 31 21:15:33 2011
From: Brian Johnson <bjohnson@drtel.com>
To: Jack Bates <jbates@brightok.net>
Date: Tue, 1 Nov 2011 01:12:32 +0000
In-Reply-To: <4EAEE9A0.30200@brightok.net>
Cc: "<nanog@nanog.org>" <nanog@nanog.org>,
"dcrocker@bbiw.net" <dcrocker@bbiw.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Sent from my iPad
On Oct 31, 2011, at 1:30 PM, "Jack Bates" <jbates@brightok.net> wrote:
>=20
>=20
> On 10/31/2011 11:48 AM, Michael Thomas wrote:
>> I've often wondered the same thing as to what the resistance is to outbo=
und
>> filtering is. I can think of a few possibilities:
>>=20
>> 1) cost of filtering
>> 2) false positives
>> 3) really _not_ wanting to know about abuse
>=20
> On the other hand, you have
>=20
> 1) cost of tracking
> 2) support costs handling infections
>=20
> It's really an range from "easiest and cost effective" to "doing it right=
". I personally run hybrid. There are areas that are near impossible to tra=
ck; this is especially true for wide area wireless/cellular/NAT areas. I al=
ways recommend my customers block tcp/25, even to the local smarthosts. Use=
587 and authentication to support better tracking. It's a hack, though, as=
it doesn't stop other abuses and it won't fix the underlying root cause.
Let me know when u can "fix" the root causes. The two I know of:
1. Bad actors
2. Clueless users
>=20
> In locations that support ease of tracking, using a mixture of feedback l=
oops with proper support is usually the proper way. This allows notificatio=
n and fixing of the root cause. In our case, we recommend quick suspensions=
to demonstrate to customer how seriously we take the problem, and then we =
point out that the sending of spam/scanning is only the easier to detect sy=
mptoms. It is unlikely we'll notice if they have a keylogger as well.
Still not the real root cause, but close. ;)
Largely in agreement otherwise.
- Brian=
