Using telnet to send e-mail to a Novell Groupwise account.

are we discussing about spammers, or how to close an open-relay?
reynotm, could you please set the focus.

reynotm, how do you know that telnet is used to compromise your MTA?
I'd suggest that you check your MTA's docs how to prevent using it from outside your valid IP range (usually your LAN).
Note: that this aproach is completely different to what have been suggested before.

As a network administrator myself, I can tell you that the reason for the resistance, in enabling the pursuit of spam, comes not from the technical staff, but from the legal and marketing staff.

We offer our customers some assurances about our willingness to protect their privacy, under the notion that people do not want their privacy to be easily invaded, under the premise of 'spam'.  Too often, we will get calls from someone who believes that we should give them information, and it turns out to be some angry, spurned chatroom would-be lover, who has decided to stalk the person who spurned them, or attempt to perpetrate a fraud in their name - or otherwise create trouble for them.  If all they had to do, was say the magic word 'spam', and get the information that they want, then we could not assure anyone of any level of privacy protection.

Now, I typically know the difference between real spam attacks, and the usual bullshit.  But the legal liabilty involved, far exceeds my employer's faith in my good judgement - or that of the lawyers.  Moreover, if we *do* enable the pursuit of the spammer, and it turns out that we are in some way negligent, or that the spammer is in some significant way, connected to us - then we may bear liability, or even become the target of a frivilous lawsuit, as the 'deep pockets' associated with the event.  You see, we stand to be sued by both the person pursuing the spam, *and* the person who perpetrates it - and that stinking $20 per month account is just not worth all that liability and headache.

We will typically shut down the offender, to the best of our ability - but when you are a large ISP, it is difficult to keep track of who the offenders are, or how many accounts they signed up for, under different identities.  Most ISPs will accept cash payments, since not all of our users have credit or checking accounts (bad credit), and - after the notorious abuses of such information - not all users are comfortable with giving us their financial information.  We are, after all, in business to take their money.  If they pay for enough service, up front, we *will* take their money, regardless of the form that it takes.  We will also keep it, when we cut them off for violating our Acceptable Use Policies.  I suppose that, in a way, that means that we benefit from spam activity on our networks - but the point is actually to inflict such penalty as we can, on the spammers, for the pain in the ass that they represent.

We love to see someone go legal, but we also know these guys well enough to know when they don't have the assets to be worthwhile to pursue.  Most spammers are rapidly identitfied by network administrators of the networks that they abuse, it's merely a game of cat and mouse, trying to determine what accounts they are on.  If they actually had any assets, we'd sue them ourselves - after all, their spam is traversing our networks, to our detriment, and in violation of the agreement that they signed with us.  Most of these guys are playing the "nothing to lose" game, and rolling the dice about penalties, because they figure that you can't squeeze blood out of a turnip.

If we actually sued each one that pops up, every time that they do so, the lawyers would own the company, because we'd go bankrupt trying to pay their fees.

It's not that we don't care.  It's that the chase simply is not in our best interests, as a business, and those of us that do care, are constrained by the business executives, to stay within the business model, or look for jobs elsewhere.  Right now, that isn't as easy to do, as it used to be - and no one wants to hire someone whose spam crusade is more important to him than his job, or the welfare of his employer.

It is possible to get a spammer who is spoofing your email address.  You typically do have to go legal, and it is often not a financially productive battle to fight - but not fighting it may damage you more than fighting it, depending upon how much you value your online reputation, and your email identity.  They can be caught and stopped.  It just depends upon how badly you want them...  :)

If we all sat around counting points, we'd never get around to helping anyone...  :)

The telnet 'exploit' is actually well-understood and quite old; the SMTP protocol was designed to be tested using a telnet client, some 20 or 30 years ago.  That was how server software designers, in the 'olden' days (the days when guys like Paul Vixie, John Postel, and Eric Allman used to sit around a game of Dungeons & Dragons at U.C. Berkeley, thinking this crap up), performed regression tests of the software that they were developing.  Also - telnet.exe comes with Windows, ever since Windows '95 - indeed, there was a free TCP/IP package for Windows for WorkGroups, which contained a free telnet.exe program.

I'd like to suggest that you direct your technician to www.cyberarmy.com - in particular, the CyberArmy University, where we actually conduct classes in these types of tactics.  Understanding the tactics will help you to identify when you have actually been victimized by them, what they actually mean, and what sorts of countermeasures you can reasonably and effectively apply.  Admittedly, most of the CyberArmy University training material is fairly low-level stuff, but it sounds like your technician - and indeed, most of your network staff - may be new to the subject area, and we have found, at CyberArmy, that useful introductory-level tactical material tends to be hard to find.  It is usually written at too high of a technical level, or is too vague when it comes to details, for the novice user to be able to duplicate conditions and results.  We tend to be a bit on the wordy side, but we try to avoid both of the other two training pitfalls...  :)

It sounds like you might have a novice 'hacker' inside of your network - possibly one of your students.  If that's the case, you should really try to learn how to read message headers, so that you can track down the workstation that they are coming from, and nip the problem in the bud.  Left unchecked, the attacks will only grow in effect and scope.

A word of warning, however:  the kids who do this are typically social outcasts within their peer groups, and are looking for approval.  They want to distinguish themselves as capable and unique and important, and coming down on them like a ton of bricks only serves to grant them that validation, through negative reinforcement (that's a psychology term that the school counselors are likely to understand, for those onlookers who don't recognize it).  If you go down this road, the attacks are sure to grow by geometic proportions; your responses to them grant the attacker the very validation that he is looking for - and the more extreme your response, the more notorious the attacker becomes.  You have an opportunity, here, to turn this individual to your advantage, while still granting him the validation that he so desperately wants - ask him to participate in the design of your network security countermeasures.  Allow him to be validated for his abilities, in a way that demonstrates his weakness (he almost certainly will not know how to secure systems against his own attacks) before his peers, but also acknowledges that he is unique and talented - all while forcing him to turn those talents to the light.  If he chooses to be helpful, then he continues to be validated.  If not, then he turns back into a 'script kiddie', who gave up his access to professionals and training, in favor of the computer equivalent of spray-painting the school walls.

You should not put him in charge of computer security - indeed, everything that he suggests or does, should be overseen by someone who is at least capable of applying the 'sanity-check' principle to his efforts (his mentor and patron, in the department) - but by allowing him to participate, you may well turn him from the path of black-hat behavior, into the light.  And you may find that he has a lot of tactical knowledge (and perhaps more importantly, time) to devote to helping you.  Moreover, you'll take him from the half-assed script-kiddie stage, into the realm of professional information security.  The kid is probably a pain in his teachers asses, right now, and probably bored in his classes.  This would offer him a real challenge, with real-world applications, in a subject area that obviously interests him.  It could serve as an excellent motivator for turning what might otherwise be an obnoxious troublemaker, into a devoted student...

In case anyone missed the subtext there, a lot of what I'm talking about, is my own history...  :-P

Hi!

The guy is using an insecure SMTP server which allows access to anyone by connecting at port 25. It is immaterial which operating system you are using. But you can surely trace the culprit. This is how:

Although SMTP protocol can be easily fooled. But when someone make a telnet connection (remember port 25 is TCP port). It also leaves his IP address and other info. Now you normally dont see this info but it gets transferred to your email client (on your computer or web based). In outlook you can see that info by clicking SHOW FULL HEADERS. Same is for yahoo. Here is a sample of full headers

X-Apparently-To: someone@yahoo.com via 101.199.70.95; 06 Jul 2003 11:44:07 -0700 (PDT)
Return-Path: <someother@rediffmail.com>
Received: from 103.199.83.33 (HELO rediffmail.com) (103.119.83.32) by mta410.mail.yahoo.com with SMTP; 06 Jul 2003 11:44:06 -0700 (PDT)
Received: (qmail 18935 invoked by uid 510); 6 Jul 2003 18:43:48 -0000
Date: 6 Jul 2003 18:43:48 -0000
Message-ID: <20030706184348.18934.qmail@webmail32.rediffmail.com>
Received: from unknown (203.94.241.112) by rediffmail.com via HTTP; 06 jul 2003 18:43:48 -0000
MIME-Version: 1.0

PLEASE PAY ATTTENTION TO LINE RETURN - PATH

Now you have the IP of that guy and also the server he used to send you this mail. Now, what can you do. Simple enough go to:

http://www.arin.net

Which is whois authority for US (it will redirect your request to specific whois authoruty if IP is outside US) and search there database for this IP address. You will get the geographical information of that person, with the name location of his ISP, Administrator and also the contact person for ABUSE. Either you can report this matter to some agency or send a request to this guy's ISP. Which can take good care of him.

It worked for me and should work for you. You can stop him this way not only for abusing you but also many other people. NAIL HIM!!!

reynotm,
Your question is "What can we do to keep this from happening?"

To set the Filter rule is what can I suggest with so limited information at the moment.

Using telnet or whatever anonymous emailer/tools to send spam email thru open relay SMTP server to others are happend in everyday for poor system administration.  However your SMTP server is not allow open relay as you described.

Can you tell us more is it only the administrators group received anonymous mail or other users also received anonymous mail.  The email content you said is weird but not like MrYowler descirded type, does these anonymous mail has some relevent to your school or students affair?  It may happened from insider (internal to internal) because Novell's NDS tree allowed user to browse the tree members information.