Re: TCPIP V5.4, SMTP & non-existant users #7

From: JF Mezei <jfmezei.spamnot@teksavvy.com> > But i see your point. I was kinda hoping that they would have a more > limited list of names used to construct fake email addresses. The one > advantage is for Hollywood folks who now have an easy access to a wide > variety of names that can be used in their scripts :-) I'm no junk e-mail expert, but the names appear to be more pronouncable than purely random letters, rather like VMS generated passwords. > Out of curiosity, how did you generate that list ? Did you use SEARCH to > scan all the different receiver logs to extract the RCPT TO lines ? ALP $ search /match = and /noheader - TCPIP$SMTP_RECV_RUN.LOG;* "RCPT TO", "@antinode.org" I currently keep about 4000 log files, so you didn't get the whole list. (And I did remove a few cases of valid addresses.) Directory SYS$SPECIFIC:[TCPIP$SMTP] TCPIP$SMTP_RECV_RUN.LOG;20428 2 10-OCT-2005 22:00:07.10 (RWED,RWED,RE,) TCPIP$SMTP_RECV_RUN.LOG;16401 2 10-OCT-2005 19:28:13.17 (RWED,RWED,RE,) As you can see, that's about 4000 in about 2.5 hours (which is about as fast as I've seen it). > It would be interesting for you to do a SET WATCH FILE in the receiver > to see if the receiver tries to access the VMSMAIL_PROFILE.DATA and/or > the SYSUAF.DAT No, it might be interesting for _you_. > HP could do us a big favour if they were to open source the > TCPIP$RECEIVER . We need something that can move fast for the anti-spam > features, and right now, the TCPIP Services folks are moving way too > slow. And we don't get it for VAX anymore. From: Kilgallen@SpamCop.net (Larry Kilgallen) > The typical response to such behavior is alternate vendors. > > Process Software is in this market with three lines of email support. True, and there is a Hobbyist license there, too, though not for MX, I believe, but conversion involves actual work, too. As I've said before, I'd settle for a hook to a user-supplied command procedure which could implement more complex behavior. (Perhaps one for the receiver and one for the symbiont.) The same goes for anonymous connections to the FTP server, where I could greatly reduce my annoyance by rejecting these: search /match = and /noheader - SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG - "logged in", "gpuser@home.com" 3-JAN-2003 08:10:39.49 User:anonymous logged in ident:Cgpuser@home.com from Host:166.114.253.187 6-JAN-2003 19:57:17.07 User:anonymous logged in ident:Igpuser@home.com from Host:p50878BA1.dip.t-dialin.net 8-JAN-2003 12:11:43.92 User:anonymous logged in ident:Ugpuser@home.com from Host:AToulouse-105-1-11-150.abo.wanadoo.fr 12-JAN-2003 20:32:49.66 User:anonymous logged in ident:Ngpuser@home.com from Host:pD9051AC8.dip.t-dialin.net 13-JAN-2003 09:19:46.53 User:anonymous logged in ident:Rgpuser@home.com from Host:TK212017072094.tuwien.teleweb.at 14-JAN-2003 13:38:26.45 User:anonymous logged in ident:Ygpuser@home.com from Host:pD9511383.dip.t-dialin.net 16-JAN-2003 19:05:24.62 User:anonymous logged in ident:Sgpuser@home.com from Host:CDR8-29.accesscable.net 25-JAN-2003 11:22:44.91 User:anonymous logged in ident:Rgpuser@home.com from Host:pD9E48DED.dip.t-dialin.net 31-JAN-2003 13:08:40.15 User:anonymous logged in ident:Qgpuser@home.com from Host:p50844B10.dip.t-dialin.net 1-FEB-2003 19:57:46.58 User:anonymous logged in ident:Cgpuser@home.com from Host:80.131.52.140 6-FEB-2003 22:12:42.11 User:anonymous logged in ident:Ogpuser@home.com from Host:pD9E3337C.dip.t-dialin.net 14-FEB-2003 16:12:25.93 User:anonymous logged in ident:Mgpuser@home.com from Host:node-c-458d.a2000.nl 17-FEB-2003 03:38:11.39 User:anonymous logged in ident:Qgpuser@home.com from Host:CDR8-29.accesscable.net 23-FEB-2003 06:20:49.66 User:anonymous logged in ident:Igpuser@home.com from Host:pD9E33613.dip.t-dialin.net 28-FEB-2003 06:33:51.99 User:anonymous logged in ident:Hgpuser@home.com from Host:pD9E7D823.dip.t-dialin.net 21-MAR-2003 07:09:37.31 User:anonymous logged in ident:Mgpuser@home.com from Host:ALyon-207-1-4-238.abo.wanadoo.fr [...] These would be easy enough to identify, but I'm unaware of a mechanism to do it with the current FTP server. From: JF Mezei <jfmezei.spamnot@teksavvy.com> > One idea. > > point antinode.ord to node2 > > On node2, [...] If electric heat were cheaper than natural gas, or if I had some real work for the other system to do, I might more seriously consider something like that. But it's not, and I don't. (The "new" XP1000 is already doing SETI@home work units oodles faster than the AlpSta 200 4/233. It's even gaining in the "You have completed more work units than NN.NNN% of our users." value, for a change.) ------------------------------------------------------------------------ Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street sms@antinode-org Saint Paul MN 55105-2547

"Steven M. Schweda" wrote: > I'm no junk e-mail expert, but the names appear to be more > pronouncable than purely random letters, rather like VMS generated > passwords. Of the junk I get, the From: lines are quite telling. They all have valid human first and last names in the freeform areas, and some apparently valid username @domain.tld in the email address, however, the username never matches the freeform name eg: From: Alexis Bauer <rzhhhddth@optoonline.com> It appears that they have harcvested a lot fo valid email addresses and names and are mixing the name and email or simply randomly generating the email address with a valid domain. Remember that for every tactitc used by systems managers, the spammers work hard to find a way around it. > No, it might be interesting for _you_. Knowing how the addition to the receiver works might help determine a way to make it work. For instance, if the receiver process uses MAIL$USER_GET_INFO routine, it needs SYSNAM. Doesd the TCPIP$SMTP_RECEIVER.EXE image have SYSNAME installed ? If not, its requests to lookup the user profile would all come back with "not enough privileges". Also, consider that it is possible to have a user with a SYSUAF entry but no VMSMAIL_PROFILE.DATA entry and vice versa. But if I remember correctly, $GETUAI requires SYSPRV to find entries other than yours. So consider the coder. With a name longer than 12 characters, he would know to only check vmsmail_profile.data with MAIL$USER_GET_INFO and not bother checking SYSUAF since it couldn't be in sysuaf whose key is max 12 bytes. However, failure to get MAIL$USER_GET_INFO doesn't necessarily mean it is undeliverable sincit could be in SYSUAF without an entry in VMSMAIL profile yet. > As I've said before, I'd settle for a hook to a user-supplied command > procedure which could implement more complex behavior. (Perhaps one for > the receiver and one for the symbiont.) TCPIP$SMTP_RECEIVER.EXE uses undocumented TCPIP$xxxxxx routines to create the control files and submit them to the symbiont. If those were documented, it would then be possible to write your own receiver to simply replace the DEC supplied one. Right now, one would have to use the SFF routines which means incoming message would have to be written to file, then give that file to SFF routines which would then rewrite the same data to another set of files (essentially executing the SMTP commands you add to the top of the message) and submit them to the symbiont for processing.

Steven, I don't have a quick answer (and since I've been pulled out of the office almost constantly the last couple of days I haven't been able to call in a problem report either) but there is one possible alternative if you want to spend the time looking at it. Last year the following message was posted to COV by Jeff Morgan showing a way to prefilter email; it does happen after receipt but before delivery, so it might be applicable to this problem. I just checked and the website and download are still there too. I actually intended to try this at home but haven't had time to set up the domain I was going to use it on. Rich http://groups.google.com/group/comp.os.vms/msg/e03d20ee60be5173