INFO-VAX Tue, 03 Apr 2007 Volume 2007 : Issue 186 Contents: Re: anti-spam advice CMMi Level 5 Company Relevant Experience: 2+ to 5 years DNS server and root.hints Re: DNS server and root.hints Re: DNS server and root.hints Re: DNS server and root.hints Re: DNS server and root.hints Re: firmware cd 3.6 - HELP Re: Free MicroVAXen in Central Illinois. Mistake Ignore previous Re: DNS server and root.hints Re: More on why Javascript is evil Re: More on why Javascript is evil Re: More on why Javascript is evil Re: Password change, IP alias Re: Password change, IP alias Re: Should DECW X server release memory ? Re: Should DECW X server release memory ? Re: Switching off MULTITHREAD ---------------------------------------------------------------------- Date: Tue, 3 Apr 2007 08:43:32 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: anti-spam advice Message-ID: In article , JF Mezei writes: > Phillip Helbig---remove CLOTHES to reply wrote: > > I agree. However, one could set up a completely legitimate email server > > on a dynamic IP address, i.e. the ONLY "reason" for rejecting email > > from it would be because it is dynamic. > > This is quite questionable. In the early days of the net, everyone had fixed IPs > and so did mail servers. Try to limit your lines to 72 characters. > Dynamic IPs came along for dialup (SLIP and later PPP). None of those were > expected to run SMTP mail servers. Those with intermittent connections used UUCP > to transfer mail. Who did the expecting? > It wasn't until the advent of outfits like dyndns.org that it because possible > to cheat and use "residential" dynamic IPs for a SMTP server. This is a hack. I don't see why it is a hack. For receiving mail, one needs something like dyndns.org, but not for sending mail. Yes, it's something new, but why is it a hack? > You need to face the fact that this hack no longer works because it has been > abused by spammers. Sad but true. Yes, that is my point. ------------------------------ Date: 3 Apr 2007 04:15:14 -0700 From: "jai" Subject: CMMi Level 5 Company Relevant Experience: 2+ to 5 years Message-ID: <1175598914.022739.152100@l77g2000hsb.googlegroups.com> Company: CMMi Level 5 Company Relevant Experience: 2+ to 5 years Job Category: Self Employed / Consultants Location(s): Mumbai, Pune, India Job Description Job Description: Candidates with 3+ yrs of ABAP Tech exp plus JAVA exp and BSP prefered. ABAP Technical Development experience Develop new SAP portal using BSP Desired Profile: ABAP - BSP Consultant Contact Contact To view this user's contact information you are required to login to your Jobs.ByIndia account. Need an account? Register as a job seeker! URL:http://jobs.byindia.com/viewjob.php?jid=150 ------------------------------ Date: Tue, 03 Apr 2007 02:39:17 -0400 From: JF Mezei Subject: DNS server and root.hints Message-ID: If you run your own DNS server, when you make a request for a .TLD that isn't yet known, it will go to the root servers (there are a number of servers defined in root.hints ) How does the DNS server decide which of the root servers to use to resolve that query ? In my case, I.ROOT-SERVER.ORG is right next door with a box in the same building as my ISP's main router. (toronto internet exchange/ 100 Front Street). Is there a way to tell my DNS server that this "I" server is a prefered one ? ------------------------------ Date: Tue, 03 Apr 2007 05:49:35 -0500 From: Dan Foster Subject: Re: DNS server and root.hints Message-ID: In article <7467$4611f9aa$cef8887a$25575@TEKSAVVY.COM>, JF Mezei wrote: > BTW, the root.hints file that came with TCPIP Services 5.6 was > "packaged" in 2006 but using data from 2003. > > the entry for B.ROOT-SERVERS.NET. is wrong. It points to 128.9.0.107 > > But the current entry should point to 192.228.79.201 > > Source: http://www.internic.net/zones/named.root > > Last updated: Jan 29 2004. Yeah. I usually see that happen every year or two with various package maintainers for their DNS package. Someone with a current HP OpenVMS support contract probably wants to file a bug report to have it fixed via a subsequent TCPIP patch. I would if I could, but being contract-less, I can't. It should be a trivial bug fix for HP to resolve, though. > Also, in an entry such as: A.ROOT-SERVERS.NET. 188459 IN A > 198.41.0.4 > > I take it the 188459 is the TTL in seconds ? Yes, it is. You can see how much time is left on your machine before the cache expires and it then re-fetches updated information by doing: $ dig . ns (This is also the canonical way of discovering what are the current nameservers and their IPs.) > In the internic official source, the TTL is now 3600000 (1000 hours). That makes sense and looks right. Nearly 42 days; probably to alleviate the load on the root nameservers. Given that they are distributed and robust, and don't change TLDs/ccTLDs very often or fast, that's probably a reasonable number. -Dan ------------------------------ Date: Tue, 03 Apr 2007 08:09:03 -0700 From: "Tom Linden" Subject: Re: DNS server and root.hints Message-ID: On Tue, 03 Apr 2007 03:49:35 -0700, Dan Foster wrote: > You can see how much time is left on your machine before the cache > expires and it then re-fetches updated information by doing: > $ dig . ns BTW, why no help on dig? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 03 Apr 2007 08:54:59 -0700 From: "Tom Linden" Subject: Re: DNS server and root.hints Message-ID: On Tue, 03 Apr 2007 03:49:35 -0700, Dan Foster wrote: > In article <7467$4611f9aa$cef8887a$25575@TEKSAVVY.COM>, JF Mezei > wrote: >> BTW, the root.hints file that came with TCPIP Services 5.6 was >> "packaged" in 2006 but using data from 2003. >> >> the entry for B.ROOT-SERVERS.NET. is wrong. It points to 128.9.0.107 >> >> But the current entry should point to 192.228.79.201 >> >> Source: http://www.internic.net/zones/named.root >> >> Last updated: Jan 29 2004. > > Yeah. I usually see that happen every year or two with various package > maintainers for their DNS package. > > Someone with a current HP OpenVMS support contract probably wants to > file a bug report to have it fixed via a subsequent TCPIP patch. I would > if I could, but being contract-less, I can't. > > It should be a trivial bug fix for HP to resolve, though. > >> Also, in an entry such as: A.ROOT-SERVERS.NET. 188459 IN A >> 198.41.0.4 >> >> I take it the 188459 is the TTL in seconds ? > > Yes, it is. > > You can see how much time is left on your machine before the cache > expires and it then re-fetches updated information by doing: > > $ dig . ns BTW, why no help on dig? > > (This is also the canonical way of discovering what are the current > nameservers and their IPs.) > >> In the internic official source, the TTL is now 3600000 (1000 hours). > > That makes sense and looks right. > > Nearly 42 days; probably to alleviate the load on the root nameservers. > Given that they are distributed and robust, and don't change TLDs/ccTLDs > very often or fast, that's probably a reasonable number. > > -Dan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 03 Apr 2007 11:26:54 -0500 From: Dan Foster Subject: Re: DNS server and root.hints Message-ID: In article , Tom Linden wrote: > On Tue, 03 Apr 2007 03:49:35 -0700, Dan Foster wrote: > >> You can see how much time is left on your machine before the cache >> expires and it then re-fetches updated information by doing: >> $ dig . ns > > BTW, why no help on dig? Hmm, good question re: online HELP. The TCPIP docs does have info: http://h71000.www7.hp.com/doc/732final/6526/6526pro_015.html#bottom_015 I only use Multinet so I'm not sure but there might be a chance it could be in the HELP section somewhere under 'HELP TCPIP'? If not, then the TCPIP product documentation is probably the only place for that information. Basic dig usage: $ dig [] [@nameserver] - If no record type, it assumes 'A' (name-to-IP address lookup) - If no nameserver hostname or IP address specified, goes through local resolver - Defaults to verbose output unless you tack on +short as an optional parameter In this case, the suggested command directed dig to: - Look up NS (nameserver) records for the . zone (aka 'root zone', the very top level of the DNS hierarchy) - Return information verbosely -- including the current time-to-live [in seconds] for each returned NS record Other examples of dig usage: Find IP address of www.hp.com, and print only its IP address: $ dig www.hp.com +short Find AOL's mail servers, and print only the mail server hostnames: $ dig aol.com mx +short Find the 'real' name of www.yahoo.com, and print the debug information: $ dig www.yahoo.com cname Look up www.example.com's IP address via a locally-hosted nameserver: $ dig www.example.com @localhost Admittedly, dig can be a bit arcane but it's by far my favorite single DNS debugging tool (and doesn't require privileges). It's like the swiss army knife of DNS troubleshooting (or even just basic info gathering). I administer somewhere over 10,000 but less than 100,000 DNS zones and would be completely lost without dig for debugging even the oddest or most estoteric issue... but also use it for the simplest stuff, too. -Dan ------------------------------ Date: Tue, 03 Apr 2007 09:06:12 +0200 From: Michael Kraemer Subject: Re: firmware cd 3.6 - HELP Message-ID: Island Computers, D B Turner schrieb: > Well it seems that we need 3.6 > If anyone had a copy I would greatly appreciate it > > David > well, by the time you arrive at 3.3 I might have a copy. BTW, talking of the "Nuclear Sites" in need of such ancient stuff, where are they located, US or Ayatollahbad ? ------------------------------ Date: Tue, 03 Apr 2007 13:11:16 GMT From: "John E. Malmberg" Subject: Re: Free MicroVAXen in Central Illinois. Message-ID: John E. Malmberg wrote: > I have 3 q-bus MicroVAXen + some spare parts that I need to get rid of. > > They are located in Tolono, Illinois. > > > 1. VAX 4000 Model 500 with expired hobby licenses. > Includes 3 RF 72? drives, and a KZQSA that is bootable, > 2 CXY08 cards with cables, 128 M Memory, and TLZ06 built in. > Spare DELQA is also available. This system has VMS 7.3 on it with > hobby licenses that will expire in days. I have not powered it up > since the move, and will likely be unable to do so. > > > 2. VAX (Server?) 3500 in a world box that was upgraded from being > a MV-II. Has TK50 drive, third party bootable SCSI controller that > emulates MSCP. Inside are SCSI drives and RD54 drives. System could > not find a boot disk the last time I tried to boot it. Estimate that > there is either 32 M or 48 M of memory in it. Has DELQA. > > I suspect that one of the SCSI disks failed in a way that is causing > all disks to not show up. > > 3. MicroVAX I. No disks in this one. However I do have somewhere an > RQDX3 that will fit it, and some RD54s that are in unknown condition. > > There are also other spare cables and boards, including the MV-II CPU > and memory that were removed from the world box. > > Theoretically, it may be possible to use the world box to build a 7.3 > installation on an RD54 and then boot it on the MicroVAX I, even > though that is not a supported configuration. > > I also have a number of TK50 tapes, also in unknown condition. > > Tolono is only a few hours drive from Chicago, St. Louis, and > Indianapolis. > > As this stuff needs to go, I am willing to give it to who ever will > pick it up. I would like it to go as a set. > > If these are worth money to the person that picks them up, they can make > a donation to the operation of encompasserve.org. Repeating in case it was missed. Do I need to explain how to demung the e-mail addresses? -John wb8tyw@qsl.network malmberg@encompasserve.organization Personal Opinion Only ------------------------------ Date: Tue, 03 Apr 2007 08:55:53 -0700 From: "Tom Linden" Subject: Mistake Ignore previous Re: DNS server and root.hints Message-ID: On Tue, 03 Apr 2007 08:54:59 -0700, Tom Linden wrote: > On Tue, 03 Apr 2007 03:49:35 -0700, Dan Foster > wrote: > >> In article <7467$4611f9aa$cef8887a$25575@TEKSAVVY.COM>, JF Mezei >> wrote: >>> BTW, the root.hints file that came with TCPIP Services 5.6 was >>> "packaged" in 2006 but using data from 2003. >>> >>> the entry for B.ROOT-SERVERS.NET. is wrong. It points to 128.9.0.107 >>> >>> But the current entry should point to 192.228.79.201 >>> >>> Source: http://www.internic.net/zones/named.root >>> >>> Last updated: Jan 29 2004. >> >> Yeah. I usually see that happen every year or two with various package >> maintainers for their DNS package. >> >> Someone with a current HP OpenVMS support contract probably wants to >> file a bug report to have it fixed via a subsequent TCPIP patch. I would >> if I could, but being contract-less, I can't. >> >> It should be a trivial bug fix for HP to resolve, though. >> >>> Also, in an entry such as: A.ROOT-SERVERS.NET. 188459 IN A >>> 198.41.0.4 >>> >>> I take it the 188459 is the TTL in seconds ? >> >> Yes, it is. >> >> You can see how much time is left on your machine before the cache >> expires and it then re-fetches updated information by doing: >> >> $ dig . ns > > BTW, why no help on dig? >> >> (This is also the canonical way of discovering what are the current >> nameservers and their IPs.) >> >>> In the internic official source, the TTL is now 3600000 (1000 hours). >> >> That makes sense and looks right. >> >> Nearly 42 days; probably to alleviate the load on the root nameservers. >> Given that they are distributed and robust, and don't change TLDs/ccTLDs >> very often or fast, that's probably a reasonable number. >> >> -Dan > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 03 Apr 2007 05:05:55 -0400 From: JF Mezei Subject: Re: More on why Javascript is evil Message-ID: <9ce7d$46121911$cef8887a$32169@TEKSAVVY.COM> Richar Maher wrote: >For anyone else who has the time to look this up (it's about five pages >before they start to tell you what they're talking about :-() can you please >give me an english version of the exact vulnerability scenario? http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf The way I understood it: Say you are a legitimate member of Google Mail. They use fancy javascript which dynamically generates its own HTTP requests. These requests result in a javascript response stored in memory. When that response is executed (eval), it does whatever Google wanted it to do, for instance, setting an array that contains all your email contacts. If you access a malicious web site, it can use the