1 INFO-VAX	Sun, 21 Sep 2003	Volume 2003 : Issue 523       Contents:0 Re: A flood of spams - another virus on the way?0 Re: A flood of spams - another virus on the way?0 Re: A flood of spams - another virus on the way? merging queue databases " Re: newbie multinet, wasd question2 strangeness with temporary text files used by MAIL Re: VMS Upgrade Needed Re: VMS Upgrade Needed  F ----------------------------------------------------------------------  # Date: Sat, 20 Sep 2003 19:32:50 GMT ' From: Don Sykes <anonymous@pacbell.net> 9 Subject: Re: A flood of spams - another virus on the way? + Message-ID: <3F6CABF0.BAD2DD4C@pacbell.net>   E As I've been complaining about recently, I can't even get the HP SMTP F service to check incoming messgaes for a valid user during the initialF connection, which IIRC could be done in the 2nd step of the connection process!  F This most recent onslaught of crap is just another example of what theE problem REALLY is - i.e. no check points along the email path. In the D current SMTP model the only one who even has an opportunity to blockF spam & assc viruses is the end receipient. This means that even if youF have a "good filter" on your email reader and don't ever "see" the badD emails, an enormous amount of bandwidth is taken up on the internet,E because each piece of crap sent out gets the same treatment all along G the way to the destination user. Only then do we get a chance to ignore G it. So who's at fault? Our own industry for embracing tcpip/smtp as the G holly grail in its original form - i.e. no forced checkpoints. As I see G it any ISP that is authorized to hand out an IP address s/b responsible F for its misuse. They should at minimum be required to check the sourceD of all email to be sure it's valid and has not been spoofed. FurtherB each of the ISP's customers should have to register an approximateF number of emails they will be sending out in any one day. Then if theyC grossly exceeded that, the initial ISP router should reject further C emails and immediately inform their customer of the action. Any ISP E failing to do this should have their IP addresses revoked or put on a C lookaside list of all legit routers and not route emails from them.   @ Granted this is a half-baked idea at this point, but if WE, as aF community, are ever going to stop this madness, we're going to have toF come up with a technical solution at a fundamental, routing level; notB just add more and different filters for the end user to implement.     --     Have VMS, Will Travel  Wire paladin, San Francisco    (paladinATalphaseDOTcom)     Paul Sture wrote:  > 8 > More spams. Is this another virus / worm on the loose? > Q > Since 13:44 CET yesterday I have received some 114 spam messages (oops, another % > one just came in) in this  account.  > L > Normally I just get 3 or 4 per day. Spam filters are in place and the lastK > time they were adjusted was for the last round of email attacks - SoBig.F  > L > I don't have time to analyze the contents of any at the moment, but here's  > a summary for the rest of you: >  > $ mail >  > You have 112 new messages. >  > MAIL> dir R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > = >     1 MX%"rcfgam-svmrgrq@n 18-SEP-2003  new microsoft patch : >     2 MX%"amailprogram@roc 18-SEP-2003  Returned Message@ >     3 MX%"eknlmalraq_57934 18-SEP-2003  Network Security Pack.I >     4 MX%"rob@mirr.demon.n 18-SEP-2003  Newest Microsoft Critical Patch 9 >     5 MX%"qmailengine@amer 18-SEP-2003  failure message > >     6 MX%"smtpautomat@yaho 18-SEP-2003  Failure AnnouncementE >     7 MX%"kuraokmiignvzm@n 18-SEP-2003  New Internet Critical Patch M >     8 MX%"checkme2003@yaho 18-SEP-2003  Absolutely FREE!!! Time:12:38:55 PM A >     9 MX%"tixqspiniqtek_fm 18-SEP-2003  Latest Internet Upgrade ( >    10 MX%"tlgthochrtra-nzb 18-SEP-20038 >    11 MX%"cmailprogram@yah 18-SEP-2003  Failure Letter6 >    12 MX%"kmailengine@aol. 18-SEP-2003  Abort AdviceF >    13 MX%"yqhmxezrgggdvci@ 18-SEP-2003  new microsoft critical patch7 >    14 MX%"conch49@bellsout 18-SEP-2003  Latest Update 6 >    15 MX%"mailerrobot@free 18-SEP-2003  abort adviceJ >    16 MX%"mailroutine@bigf 18-SEP-2003  Undelivered Message User unknown7 >    17 MX%"MAILER-DAEMON@bo 18-SEP-2003  Virus warning  > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > 7 >    18 MX%"MAILER-DAEMON@bo 18-SEP-2003  Virus warning = >    19 MX%"srwmuivjriglae@f 18-SEP-2003  Net Critical Update 1 >    20 MX%"emailbot@aol.com 18-SEP-2003  Message : >    21 MX%"xnfirkakou@newsl 18-SEP-2003  newest net patch@ >    22 MX%"gbivjcjvmebyoz-o 18-SEP-2003  Current Security PatchB >    23 MX%"masterdaemon@fre 18-SEP-2003  Mail: Returned To SenderJ >    24 MX%"jfdpecdd-zqoklwg 18-SEP-2003  Newest Internet Security Upgrade* >    25 ***     valid message here     ***> >    26 MX%"postservice@micr 18-SEP-2003  Failure Announcement7 >    27 MX%"mcbroom5@teluspl 19-SEP-2003  Abort Message > >    28 MX%"spdtydmvqwdcrkx@ 19-SEP-2003  New Security Upgrade: >    29 MX%"quceoiuevmhfnm-l 19-SEP-2003  Latest Net Patch9 >    30 MX%"mimi-6@comcast.n 19-SEP-2003  Internet Update 4 >    31 MX%"emailprogram@roc 19-SEP-2003  Bug NoticeR >    32 MX%"Antivirus-Daemon 19-SEP-2003  Recipient Virus-alert (sender: wibi@sybe@ >    33 MX%"tpbjvsxt-psvzeyw 19-SEP-2003  Latest Network UpgradeR >    34 MX%"mailerservice@ro 19-SEP-2003  Undeliverable Message: Returned To Maile > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > @ >    35 MX%"wvzaampltzt@tech 19-SEP-2003  Newest Internet UpdateJ >    36 MX%"sjolmws_mmsfa@yy 19-SEP-2003  Current Internet Security Update? >    37 MX%"aeskfojazs@advis 19-SEP-2003  Latest Internet Patch 0 >    38 MX%"amaildaemon@amer 19-SEP-2003  Report; >    39 MX%"fqaxksowjxe_cxri 19-SEP-2003  New Security Pack 0 >    40 MX%"dennismonk@adalp 19-SEP-2003  advice> >    41 MX%"vrcxctaxxskau@co 19-SEP-2003  Last Security UpdateH >    42 MX%"jsjssekggesmh@up 19-SEP-2003  Newest Microsoft Critical PackQ >    43 MX%"masterbot@yahoo. 19-SEP-2003  Undelivered Message: Returned To Mailer P >    44 MX%"webroutine@rocke 19-SEP-2003  Undeliverable Mail: Returned To Sender6 >    45 MX%"zmailautomat@mic 19-SEP-2003  AnnouncementE >    46 MX%"fdjiybui@bulleti 19-SEP-2003  New Internet Critical Patch N >    47 MX%"postdaemon@micro 19-SEP-2003  Undelivered Mail: Returned To SenderE >    48 MX%"vfdujxlayoougai_ 19-SEP-2003  Last Internet Critical Pack F >    49 MX%"tmdyvsf@newslett 19-SEP-2003  last microsoft critical packG >    50 MX%"mailerform@purem 19-SEP-2003  Returned Message User unknown H >    51 MX%"noinjbqxfomyiz_h 19-SEP-2003  Last Internet Security Upgrade > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > 4 >    52 MX%"emailprogram@aol 19-SEP-2003  Bug Notice= >    53 MX%"ccumfrmlhsvezne_ 19-SEP-2003  Net Security Update C >    54 MX%"xvhehc@newslette 19-SEP-2003  Internet Critical Upgrade 4 >    55 MX%"webform@yahoo.co 19-SEP-2003  Bug NoticeK >    56 MX%"lnlhqdqvk-nncvtq 19-SEP-2003  Latest Microsoft Critical Upgrade ? >    57 MX%"pvlqyz@confidenc 19-SEP-2003  Latest Network Update ( >    58 MX%"emailautomat@roc 19-SEP-2003G >    59 MX%"ktztcmnppffyjhz@ 19-SEP-2003  Newest Internet Critical Pack 1 >    60 MX%"postdaemon@purem 19-SEP-2003  message H >    61 MX%"vjjnawljmkk-avqm 19-SEP-2003  Latest Network Security Update0 >    62 MX%"mailservice@rock 19-SEP-2003  notice1 >    63 MX%"MAILER-DAEMON@cn 19-SEP-2003  message I >    64 MX%"hqjgmmna@updates 19-SEP-2003  Last Microsoft Security Upgrade ? >    65 MX%"webautomat@ameri 19-SEP-2003  Message: User unknown A >    66 MX%"jfzaopfimsuj-qfl 19-SEP-2003  New Net Critical Update H >    67 MX%"azncwgoj_osqtv@u 19-SEP-2003  Latest Network Security UpdateA >    68 MX%"zmmcclfkfqvande- 19-SEP-2003  Latest Internet Upgrade  > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > 8 >    69 MX%"mailprogram@bigf 19-SEP-2003  Failure Notice@ >    70 MX%"vkckdghoseko@new 19-SEP-2003  Internet Critical Pack( >    71 MX%"smtpautomat@netm 19-SEP-2003I >    72 MX%"twestzrshxsl_qbb 19-SEP-2003  Latest Internet Critical Update 4 >    73 MX%"eagabohf_wvopm@n 19-SEP-2003  New UpdateQ >    74 MX%"emailform@netmai 19-SEP-2003  Undelivered Message: Returned To Sender 6 >    75 MX%"fdwetxnrikiatn_z 19-SEP-2003  Last Upgrade7 >    76 MX%"webprogram@freem 19-SEP-2003  error message @ >    77 MX%"owypdvkvddffd_hp 19-SEP-2003  Latest Critical Update7 >    78 MX%"mailerengine@aol 19-SEP-2003  Error Message J >    79 MX%"shposik@wpube.co 19-SEP-2003  latest microsoft critical update> >    80 MX%"gdadlgc_lhvwztzr 19-SEP-2003  Latest Internet Pack8 >    81 MX%"masterrobot@free 19-SEP-2003  failure advice0 >    82 MX%"mailerdaemon@aol 19-SEP-2003  Notice( >    83 MX%"vyqlltijy@newsle 19-SEP-20036 >    84 MX%"vapxjfszdo@suppo 19-SEP-2003  Latest PatchH >    85 MX%"mwoxbkemhk@updat 19-SEP-2003  Newest Microsoft Critical Pack > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > : >    86 MX%"postdaemon@ameri 19-SEP-2003  returned message6 >    87 MX%"postrobot@rocket 19-SEP-2003  Error Letter9 >    88 MX%"qfhormtdlsqfku@t 19-SEP-2003  Network Upgrade . >    89 MX%"bjugiww@bulletin 19-SEP-2003  PackH >    90 MX%"haashk@netvigato 19-SEP-2003  Undelivered Mail: User unknown@ >    91 MX%"mcnjbhpc-oafi@bu 19-SEP-2003  Current Security Patch( >    92 MX%"webbot@america.c 19-SEP-2003= >    93 MX%"qdgonoc-rgrb@new 19-SEP-2003  New Microsoft Patch F >    94 MX%"cpuguqqidnjvg_or 19-SEP-2003  New Internet Security Update@ >    95 MX%"fnzusou_cvnhcso@ 19-SEP-2003  New Net Security Patch5 >    96 MX%"postdaemon@yahoo 19-SEP-2003  bug message 4 >    97 MX%"bmailrobot@ameri 19-SEP-2003  Bug Report? >    98 MX%"pxrjnr_lgmzyg@bu 19-SEP-2003  Last Microsoft Update 8 >    99 MX%"reoyqoj_gcrutohu 19-SEP-2003  Security Patch4 >   100 MX%"webautomat@rocke 19-SEP-2003  Bug AdviceC >   101 MX%"xovfjaqjm_opjtif 19-SEP-2003  Latest Net Security Patch 6 >   102 MX%"mailerengine@fre 19-SEP-2003  Announcement > Press RETURN for more... >  > MAIL> R >                                                                          NEWMAIL1 >     # From                 Date         Subject  > J >   103 MX%"mplrco-tmmppz@co 19-SEP-2003  Current Microsoft Critical Patch0 >   104 MX%"mailerprogram@am 19-SEP-2003  NoticeE >   105 MX%"eqokxhwcarcj@new 19-SEP-2003  New Network Security Update Q >   106 MX%"mailbot@yahoo.co 19-SEP-2003  Undelivered Message: Returned To Sender : >   107 MX%"imdupgds_bbsvdrl 19-SEP-2003  Latest Net PatchB >   108 MX%"mailservice@yaho 19-SEP-2003  Mail: Returned To SenderA >   109 MX%"ekjlwjephctmtx_h 19-SEP-2003  new net critical update E >   110 MX%"szjdrqhozxmy-lhc 19-SEP-2003  last internet critical pack 6 >   111 MX%"smtprobot@freema 19-SEP-2003  error noticeM >   112 MX%"maildaemon@netma 19-SEP-2003  Undeliverable Message: User unknown  >  > MAIL>  >  > And another just arrived.  > I > Now, these appear to be junk addresses, but allegedly coming from valid M > domains - msn.com, msn.net, yahoo.com, microsoft.com, support.com and other  > well known ones. > F > 99% seem to be coming from .net and .com addresses, so I also wonder> > whether this could be a side effect of the VeriSign change -> > reverse lookups and RBLs not functioning properly anymore ?? > I > Meanwhile on checking another email account, I see my spam filter there E > caught one entitled "PayPal Account Security Measures". This one is D > inviting me to verify my account details. Nope. Not going there... > H > And they are still rolling in by the minute. Definitely not a good day > for email.   ------------------------------  % Date: Sat, 20 Sep 2003 16:42:19 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>9 Subject: Re: A flood of spams - another virus on the way? ) Message-ID: <3F6CBB93.D1326334@istop.com>    Don Sykes wrote: > G > As I've been complaining about recently, I can't even get the HP SMTP H > service to check incoming messgaes for a valid user during the initialH > connection, which IIRC could be done in the 2nd step of the connection
 > process!    N If you are talking about HP.com's SMTP service, they have had fairly agressiveL spam blocking in effect for some time (as well as Compaq before the merger).N Many of us had had problems reaching a Digital employee within Compaq or HP at one point or another.   N If you are talking about the Digital TCPIP Services for VMS, since 5.1 or 5.3,6 it has had RBL capabilities to block much of the spam.  H The only valid information an SMTP server can have during reception of aH message is the IP address of the remote sender. All other information isJ unverifiable. Also, by the time the SMTP server has gone into DATA mode toN accept the contents of the message, it MUST accept the message and then send aL non-delivery notification if it decides that the contents ofthe message wereI not acceptable. (note that RFC 822 headers are considered content at this  stage of the transport).  * typically, a SMTP session would look like: -----------  HELO <chocolate.com> MAIL FROM: <chef@chocolate.com>  RCPT TO: <elves@cookies.com> DATA# Received from: <received from text> ( From: "Chef Pierre" <chef@chocolate.com>) To: "My little elves" <elves@cookies.com> + Subject: Chocolate coating for your cookies  Date: 31 Feb 2005 22:35 EDT    Dear Elves, K It would be a great pleasure for me to supply you with the 3 tons of melted I swiss chocolate to coat your cookies. We will use a Canadair CL-415 water M tanker to do an aeral dump of the chocolate over your factory. Make sure your 3 cookies are laid out on the roof by 16:00 tomorrow.  .  ---   N Most SMTP servers simply add a Received: line, regenerate the Reply-Path: lineK (on top of headers, and is taken from the MAIL FROM:). Most will also check M for a valid Date: line. However, for the remainder of ther RFC822 header, you K cannot really check much. And in terms of checking the contents, it is very F CPU intensive, especially if checking for viruses in attachements etc.Q (Consider that the RFC header is often updated AFTER the virus checking is done).     G Remember what the first letter of SMTP stands for. Remember that in its L origins, it had to deal with very interesting adresses when you had uucp and2 bitnet adresses that were gatewayed to SMTP email.      D The mail client only sees the RFC822 headers, it doesn't see the 821L conversation between the two SMTP servers. But the receiving SMTP server canJ do a lot during that conversation to check validity of the message. It canJ check to see if the true IP address of the sending server maps to some DNSN entry. If relaying is disabled, it will ensure that the RCPT TO: is within itsM own domain. However, there isn't much one can do with the HELO and MAIL FROM: K in terms of validation because there are many legal cases where the sending M SMTP server was legally entrusted with mail coming from a different domain so N the MAIL FROM: may not match the real domain name of the IP adress of the SMTPM server sending this message. (consider UUNET which owns ozemail in australia. K Some of the SMTP servers reverse map to a UUNET domain name even though the ' mail from is an ozemail.com.au address.     M The RBL mechanisms work almost exclusively with the IP address of the sending L SMTP server, the only trusted piece of information the receiving server getsH (it is obtained from the TCPIP stack during call establishement, and forI responses to make it back to the sending SMTP, the IP must exist and have  routes back to it).     I When you consider the number of intranets and NAT protected firewalls, it I becomes even harder to start to impose rules on SMTP to ensure legitimate J emails. My SMTP server thinks it is 10.0.0.10 but to the outside world, itN appears as a true internet address. And in a multi-homed network, you may haveN multiple domains attached to SMTP server, so you must allow people inside yourJ intranet to send to the outside with a From: that could be anyone of thoseL domains that are multihomed to you. So the mail client may generate an emailE from elves@cookies.com while the SMTP server may reverse translate to J chocolate.com.  Will you block those emails even though they are perfectly legitimate and not spam ?     L Also, when you consider that not all of the world uses normal roman alphabetI and that such languages usually encode their names so that when read on a M ascii terminal, it looks like jibberish. Will you block all From: that appear  as jibbererish ?   ------------------------------   Date: 21 Sep 03 07:11:58 +0200) From: p_sture@elias.decus.ch (Paul Sture) 9 Subject: Re: A flood of spams - another virus on the way? ) Message-ID: <$JqWtFSoRKac@elias.decus.ch>   U In article <00A26247.76C62BCD@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes: d > In article <190920031422271174%paul.anderson@hp.com>, Paul Anderson <paul.anderson@hp.com> writes:G >>In article <00A26240.78C93DF0@SendSpamHere.ORG>, < @SendSpamHere.ORG>  >>wrote: >>A >>> It's probably some poor bastard that has been strapped with a G >>> Micro$haft box and just wants the rest of the world to feel his/her 	 >>> pain.  >>J >>The sad thing is that most Windows users don't realize they're in pain. 5 >>They have no idea "it doesn't have to be this way".  > H > Sadly true.  People using PeeCees seem to think that what they have toE > endure and experience is some pandora-ian pox that plagues all OSs.  > N Unfortunately that appears to be part of the sales model: make it sufficientlyL painful to get things working, and hey presto, everone who gets through that" thinks they are a computer expert.  I I kid you not, it is particularly sad to hear one's family reciting their L Winwoes experiences over an evening meal and thinking they are being helpfulJ whilst doing so. What hurts even more is that they seem to think they know= more about computers than I do. Here's a sample conversation:   / On learning a brother has got broadband and XP: J Me: "Get a firewall. Right now! If not a proper one, at least ZoneAlarm or Kerio"8 Brother: "I'm busy now, I'll look at it after Christmas"   Several weeks later...  G Brother: "I felt more comfortable buying a package, so I got the Norton  firewall (name of package)". ... ( "Are you still running legacy machines?"  - Me: "Sorry, someone's at the door, got to go"    Sad, but true.   ------------------------------  + Date: Sat, 20 Sep 2003 20:09:49 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)  Subject: merging queue databases$ Message-ID: <bkic6d$b98$1@online.de>  E At the moment ( :-) ) (one of) my hobbyist cluster(s) consists of two < VAXes and an ALPHA.  The ALPHA has been running more or lessH continuously for the last 6 years.  One of the VAXes has been running on> and off for the last 5 years or so, but like the ALPHA with an@ "organically grown" system disk.  The ALPHA is at 7.2-1, the VAXD mentioned above at 7.2.  I added a third VAX a couple of months ago,% with a freshly installed 7.3 system.    F I want to upgrade the ALPHA to 7.3-1 and the one VAX to 7.3 soon, but I before I do that---and some other maintenance stuff I have on my list of  H things to do which also requires some reboots---I want to make sure the # cluster is "set up properly" first.   @ On the ALPHA and the VAX which has been around for a while, the  following is in SYLOGICALS.COM:   F $  MOUNT/CLUSTER/NOASSIST DSA1235:/SHADOW=($1$DKA200:,$3$DKA500:) USER! $  IF F$GETDVI("DISK$USER","MNT")  $  THEN = $    FILE := DISK$USER:[SYSTEM.MANAGER]CLUSTER_WIDE_FILES.COM - $    IF F$SEARCH(FILE) .NES. "" THEN @ 'FILE'  $  ENDIF  : (I know, I should take Ken's advice and use /INCLUDE here)G where DISK$USER:[SYSTEM.MANAGER]CLUSTER_WIDE_FILES.COM looks like this:   6 $    CLUSTER_DEF := DEFINE/SYSTEM/EXECUTIVE_MODE/NOLOG7 $    CLUSTER_DEF CLUSTER_SYSTEM  DISK$USER:[SYSTEM.EXE] ; $    CLUSTER_DEF CLUSTER_MANAGER DISK$USER:[SYSTEM.MANAGER] ; $    CLUSTER_DEF CLUSTER_LIBRARY DISK$USER:[SYSTEM.LIBRARY] B $    CLUSTER_DEF SYSUAF                  CLUSTER_SYSTEM:SYSUAF.DATE $    CLUSTER_DEF SYSUAFALT               CLUSTER_SYSTEM:SYSUAFALT.DAT B $    CLUSTER_DEF SYSALF                  CLUSTER_SYSTEM:SYSALF.DATF $    CLUSTER_DEF RIGHTSLIST              CLUSTER_SYSTEM:RIGHTSLIST.DATD $    CLUSTER_DEF NETPROXY                CLUSTER_SYSTEM:NETPROXY.DATE $    CLUSTER_DEF NET$PROXY               CLUSTER_SYSTEM:NET$PROXY.DAT E $    CLUSTER_DEF NETOBJECT               CLUSTER_SYSTEM:NETOBJECT.DAT J $    CLUSTER_DEF NETNODE_REMOTE          CLUSTER_SYSTEM:NETNODE_REMOTE.DATG $    CLUSTER_DEF LMF$LICENSE             CLUSTER_SYSTEM:LMF$LICENSE.LDB L $    CLUSTER_DEF VMSMAIL_PROFILE         CLUSTER_SYSTEM:VMSMAIL_PROFILE.DATAG $    CLUSTER_DEF VMS$OBJECTS             CLUSTER_SYSTEM:VMS$OBJECTS.DAT M $    CLUSTER_DEF VMS$AUDIT_SERVER        CLUSTER_MANAGER:VMS$AUDIT_SERVER.DAT Q $    CLUSTER_DEF VMS$PASSWORD_HISTORY    CLUSTER_SYSTEM:VMS$PASSWORD_HISTORY.DATA U $    CLUSTER_DEF VMS$PASSWORD_DICTIONARY CLUSTER_LIBRARY:VMS$PASSWORD_DICTIONARY.DATA K $    CLUSTER_DEF NETNODE_UPDATE          CLUSTER_MANAGER:NETNODE_UPDATE.COM P $    CLUSTER_DEF VMS$PASSWORD_POLICY     CLUSTER_LIBRARY:VMS$PASSWORD_POLICY.EXEM $    CLUSTER_DEF LAN$NODE_DATABASE       CLUSTER_SYSTEM:LAN$NODE_DATABASE.DAT * $!SYS$SYSTEM:SYS$QUEUE_MANAGER.QMAN$QUEUES+ $!SYS$SYSTEM:SYS$QUEUE_MANAGER.QMAN$JOURNAL  $!SYS$SYSTEM:QMAN$MASTER.DAT  / First, does the list of logicals look complete?   > Second, does the general logic seem OK?  In other words, theseE cluster-common files are on a shadow set with members on two nodes of B the cluster.  Since quorum is 2, at least one of the nodes hostingF DISK$user should always be up.  (The only problem I see is if the nodeG with neither of the members comes up first in a cluster reboot (perhaps H caused by a power failure (no UPS yet)), the logicals won't get defined.G Perhaps I should put in a loop and let it try a few times before giving C up, bypass this if I am booting the node outside the cluster etc.)  E DISK$USER seems like the right place for these files since DISK$USER  F contains the "identity" of the cluster.  For obvious reasons, I don't G want these files on the system disks.  DISK$SCRATCH, DISK$DATA etc are  I just for temporary files, don't get backed up etc while DISK$SOFT (where  H I put third-party software) is designed to be usable in any cluster and D thus shouldn't contain any cluster-specific stuff.  (In the default H location, I have old copies of SYSUAF.DAT etc so that I can log in even  if DISK$USER isn't available.)  G Third, as one can see the stuff about queues is commented out.  I need  D to define QMAN$MASTER to point to the proper directory and move the D files there.  On all 3 nodes.  However, in the two older nodes, the ; corresponding files already exist in the default locations.   I It seems to me to make more sense to somehow "merge" these first then do  I the additional maintenance I want to do with respect to queues (defining  A some generic queues, getting rid of obsolete queues etc), rather  A than a) deleting everything and starting over from scratch or b)  1 cleaning up each node first then doing the merge.   F So, how do I get from where I am now to having all the queue files in F the new location, without changing any behaviour?  After I get there, ) I'm sure I can clean things up as I want.   E (Since I added the third VAX mainly so that I could afford to lose a  G node without losing quorum, I haven't actually done that much stuff on  H it yet.  Today, I tried to send an email from it, but it failed because B the queue manager was not running!  Thus, I thought it was time I  investigate this!)   ------------------------------    Date: 20 Sep 2003 15:53:47 -0700% From: syncitium443@yahoo.com (steved) + Subject: Re: newbie multinet, wasd question = Message-ID: <d1936a6b.0309201453.515edb11@posting.google.com>   \ carl@gerg.tamu.edu (Carl Perkins) wrote in message news:<20SEP200306032217@gerg.tamu.edu>...i > In article <d1936a6b.0309192102.2900c616@posting.google.com>, syncitium443@yahoo.com (steved) writes... 	 > }Hello,  > } : > }I am a newcomer to VMS looking for some help with wasd.N > }I have VMS 7.2 with multinet 4.4 running.  I was able to get wasd built andL > }running, and all seemed fine until a reboot.  Since the reboot, trying to4 > }start wasd with the DEMO command procedure gives: > } 4 > }%HTTPD-E-SOFTWAREID, HTTPd-WASD/8.3.1 OpenVMS/AXP& > }-HTTPD-E-WHERE, module:NET line:355 > }-HTTPD-E-WHAT, end of file  > } D > }It seems that it is failing at a call to gethostname() in net.c. D > }at DCL: show logical MULTINET_HOST_NAME gives the expected value,O > }but a simple C test of gethostname() fills the buffer with: "UCX$INET_HOST," O > }which is not set, and I really don't expect it to be set as multinet is the   > }only TCP/IP stack installed.  > } @ > }Can anyone help this newbie understand what is going on here? > D > Multinet will define the UCX$INET_HOST logical when it is started.F > THis is in MULTINET:START_MULTINET.COM, as well as severl other UCX$ > type logical names.  > G > You may have to set "Load UCX $QIO driver" to true in MULTINET CONFIG ; > to get it to do this, but I thought that was the default.  > H > The section in the startup file that defines these is looks like this: >  > $ ! , > $ ! Load the UCX-compatible $QIO interface > $ ! B > $ If F$Search("MULTINET:UCXDRIVER.EXE") .Eqs. "" Then Goto NoUCX >  > .. relevant stuff is here ...  > 	 > $NoUCX:  > 
 > --- Carl   Ok, Thanks. H It looks like when DHCLIENT runs it unsets UCX$INET_HOST. I am not quiteF sure what I need to do to fix this, but for now I got wasd to start by7 manualy setting UCX$INET_HOST to something appropriate.    ------------------------------  + Date: Sat, 20 Sep 2003 20:27:47 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply); Subject: strangeness with temporary text files used by MAIL $ Message-ID: <bkid82$b98$2@online.de>  H Each user has SYS$SCRATCH defined as DISK$SCRATCH:[USERNAME].  MAIL has F EDT as the editor.  From most accounts, after exiting a file composed E with SEND/EDIT to send the message, I see something like this on the   screen:   2    DISK$SCRATCH:[USERNAME]MAIL_203470C7_SEND.TMP;1  H However, from one account I don't.  The file IS written to disk and the > message is sent, though.  Output of SHOW TERMINAL is the same.  
 Any ideas?   ------------------------------  # Date: Sat, 20 Sep 2003 19:52:24 GMT 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: VMS Upgrade Needed 5 Message-ID: <Yd2bb.275359$ef4.2975970@news.chello.at>   U In article <3F5FB547.4D851CB3@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:  >Hoff Hoffman wrote:g >> In article <bjo33t$l54u4$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@jomatech.com> writes: ^ >> :"Don Sykes" <anonymous@pacbell.net> wrote in message news:3F5F8C36.D28312B2@pacbell.net... >> :> Can anyone help?4 >> :> I need to upgrade from my VMS 7.2 to VMS7.2-2.G >> :> I've been all over the HP site looking for a downloadable file to E >> :> accomplish this, but can't seem to find one. I see all kinds of G >> :> downloads in ftp://ftp.service.digital.com/public/vms/axp/v7.2-2/ J >> :> like .CHECKSUM .README & layered products, but where's the file that >> :> will do the VMS upgrade? >>  H >>   Those are patches and patch kits, and not product kits.  That's the5 >>   old OpenVMS Alpha patch FTP server address, too.  > F >Ouch. I thought I just needed a patch to bring it to the -2 level. ItH >sounds like I may as well upgrade to 7.3. I didn't want to do this now.; >I'm a firm believer in "if it ain't broke, don't fix it".  ( >And all this just to install Java 1.3. I >AND the only reason I need to install Java 1.3 is because the Java based " >James SMTP facility requires it. F >AND the only reason to use James instead of HP/Compaq's TCPIP/SMTP isC >because I CAN'T MAKE THAT FACILITY SAY "NO SUCH USER" AND DROP THE H >CONNECTION, during the connect phase, when there really IS no such user	 >anymore!    Don't upgrade for JAVA only.< VMS Upgrade is good for many reasons, but JAVA is a bad one.  G Don't use a JAVA based mailer only because TCPIP's SMTP is not perfect.   D JAVA is such a performance hog and mail is such an important serviceG in times of virus/worm attacks so that a good/fast mailer is essential. D Use MX (strongly recommended), PMDF or maybe TCPware/Multinet's SMTP? server if TCPIP's is not sufficient (which I still understand).   E Upgrade to VMS V7.3-1 (don't forget the ECOs !!) or try E7.3-2 (it is K good enough for me so far) and upgrade to JAVA 1.4.1. I second this. But...   + If you need additional help, drop me a line    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sat, 20 Sep 2003 17:15:37 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: VMS Upgrade Needed ) Message-ID: <3F6CC35F.53F9CB30@istop.com>   H > >AND the only reason to use James instead of HP/Compaq's TCPIP/SMTP isE > >because I CAN'T MAKE THAT FACILITY SAY "NO SUCH USER" AND DROP THE J > >CONNECTION, during the connect phase, when there really IS no such user > >anymore!    We had this discussion before.  J The way I understand how the Digital TCPIP SMTP server works, the receiverM merely receives the message with minimal processing and queues it to the SMTP K queues for later delivery. It is the SMTOP symbiont in that queue that does 
 all the work.   L However, when you look at the control files that are generated, the receiverL does parse the RFC822 header since the subject of the message as well as theC "nice" To:  are stored in the control file as well as the received: 
 information.    I And the receiver is the one that does the RBL processing as well as relay R prevention since those are done during the SMTP negotiation before the DATA phase.  K However, the receiver is given a list of "local" hosts to which relaying is M allowed.  Those hosts may or may not be part fo a cluster, hence the receiver K doesn't have the ability to verify the validity of a recipient because such < recipient doesn't necessarily reside on a node with the same2 vmsmail_profile.data as the receiving smtp server.  J And there are security implications in allowing the receiver to validate a username given in RCPT TO:  M since it would allow for some rogue process to start issuing tons of RCPT TO: $ to gather a list of valid usernames.   ------------------------------   End of INFO-VAX 2003.523 ************************                                                                                                                                                                                                62,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 2