North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: FW: The worst abuse e-mail ever, sverige.net

  • From: Daniel Senie
  • Date: Tue Sep 21 14:21:57 2004

At 01:29 PM 9/21/2004, Daniel Golding wrote:

On 9/21/04 1:00 PM, "james edwards" <[email protected]> wrote:

>
>> Sheesh. Get over /yourself/. Your network is rude by its very existence,
>> if it lets spammers relay crud by way of it. Your own arrogance in
>> thinking it's not your problem to fix is astounding.
>
> I did no say it is not my problem, we have a 10 year history of being
> very pro-active for all abuse issues and have a dedicated staff person to
> deal with these issues. Slaming my mail admin because a dial up user has a
> virus
> is rude, period. Our dial up address space is listed, if people choose to
> block
> mail from that space.
>
> james
>

To shift this to a more operational tone...

Networks make choices. One choice is to declare their dynamic space and put
the duty of ignoring emails from dialups users on the receiving networks.
Another choice is to filter port 25. Filtering port 25 has its own costs -
some users are offended/bothered by this, since they can't use their own
corporate mail servers, in some cases.

If a network makes the choice of putting the duty of filtering on the
receiving party, they need to accept that this will upset some of those
receivers. Today's security environment means that spam-sending viruses are
common.

The only responsible thing to do is filter port 25, smarthost for your
users, and inform them about using the alternate submission port with
authenticated SMTP in order to work with enterprise mail servers - or IPSec
VPNs, for that matter. This is simply the best practice, at this point in
time. Using humans ("dedicated staff person") to stop spam isn't scalable -
automated processes are sending this stuff, we need systematic ways to fight
it - black/white lists, SPF, port 25 filtering, bayesian filtering and other
tools.

I'd add on to this in one area. Dan's text is good as far as it goes. What I'd add is:

Implement Reasonable and Easily Handled INADDR

1) By this I mean provide PTR records for all ports

2) for dialup, DSL and Cable users on dynamic ports who should not generally be running servers, name the INADDR with something like:

    w-x-y-z.dialup.example.net
    w-x-y-z.dynamic.example.net

or similar. I don't care what scheme you want to use to the LEFT of 'dialup.example.com' or 'dynamic.example.com' but please put the information about these being dynamic blocks in a place where they can be filtered using simple mechanisms (i.e. without regex overheads).

With the naming above, it's easy to filter out dialup.example.com in the access lists of mail servers without any worries. Users coming in from those addresses using authenticated connections to the submission port will work fine, while spam direct from those machines will not work.

Many ISPs do this quite well. While it's still some work for the receiving systems vs. port 25 filtering, it sure beats guessing about remote topologies.

Also note that while some large ISPs have handed out IP address ranges of dynamically assigned address in the past, telling others they can block from those addresses, this results in stale data almost instantly. Keeping this type of thing based on PTR records in DNS means the owner of that space has the job of maintaining the designations, as it should be, and avoids pushing that task onto recipients.

3) Provide proper PTR records for your business customers. A PTR record of .biz.example.net sure looks a lot more questionable than office.example.com (where example.com is a small business, let's say).

4) Think about the other guy. If you have issues identifying what to block on your inbound flows, perhaps you might think about how your naming and other policies affect how others see your outflow. Cooperation makes things better for everyone.


--
-----------------------------------------------------------------
Daniel Senie                                     [email protected]
Amaranth Networks Inc.                    http://www.amaranth.com