From: JF Mezei <email@example.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
> 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.)
2 10-OCT-2005 22:00:07.10 (RWED,RWED,RE,)
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 -
"logged in", "firstname.lastname@example.org"
3-JAN-2003 08:10:39.49 User:anonymous logged in ident:Cgpuser@home.com
6-JAN-2003 19:57:17.07 User:anonymous logged in ident:Igpuser@home.com
8-JAN-2003 12:11:43.92 User:anonymous logged in ident:Ugpuser@home.com
12-JAN-2003 20:32:49.66 User:anonymous logged in ident:Ngpuser@home.com
13-JAN-2003 09:19:46.53 User:anonymous logged in ident:Rgpuser@home.com
14-JAN-2003 13:38:26.45 User:anonymous logged in ident:Ygpuser@home.com
16-JAN-2003 19:05:24.62 User:anonymous logged in ident:Sgpuser@home.com
25-JAN-2003 11:22:44.91 User:anonymous logged in ident:Rgpuser@home.com
31-JAN-2003 13:08:40.15 User:anonymous logged in ident:Qgpuser@home.com
1-FEB-2003 19:57:46.58 User:anonymous logged in ident:Cgpuser@home.com
6-FEB-2003 22:12:42.11 User:anonymous logged in ident:Ogpuser@home.com
14-FEB-2003 16:12:25.93 User:anonymous logged in ident:Mgpuser@home.com
17-FEB-2003 03:38:11.39 User:anonymous logged in ident:Qgpuser@home.com
23-FEB-2003 06:20:49.66 User:anonymous logged in ident:Igpuser@home.com
28-FEB-2003 06:33:51.99 User:anonymous logged in ident:Hgpuser@home.com
21-MAR-2003 07:09:37.31 User:anonymous logged in ident:Mgpuser@home.com
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 <email@example.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
||10/11/2005 2:41:39 AM
See related articles to this posting
"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
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
From: Alexis Bauer <firstname.lastname@example.org>
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.
10/11/2005 3:59:24 AM
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.
10/11/2005 7:16:25 PM
12/5/2013 7:08:29 AM
page loaded in 60506 ms. (0)