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

Daniel Senie dts at senie.com
Tue Sep 21 18:11:11 UTC 2004


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

>On 9/21/04 1:00 PM, "james edwards" <hackerwacker at cybermesa.com> 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                                     dts at amaranth.com
Amaranth Networks Inc.                    http://www.amaranth.com




More information about the NANOG mailing list