At 01:29 PM 9/21/2004, Daniel Golding wrote:
On 9/21/04 1:00 PM, "james edwards" <hackerwacker@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@amaranth.com Amaranth Networks Inc. http://www.amaranth.com