Re: Has postini been taken over?
On Fri, Aug 20, 2004 at 07:53:05AM +0300, Hank Nussbacher wrote: At 09:14 AM 19-08-04 -0700, Jay Hennigan wrote: Have you or a mail administrator for your domain signed up with Postini for spam filtering? If so, all mail for the domain will flow through How exactly does all mail for the domain will flow through Postini's servers? I ask since the IP sending to some postini IP like exprod5mx30.postini.com is blocked for outgoing port 25+80. That means that the data is flowing to postini in 1 of the following ways: a) auto-GRE tunnels b) email packaged in some way c) email is being sent via some dialup/DSL connection to postini You're making this entirely too complicated. Just because mail can't enter postini's network via the address it comes from, doesn't mean it can't enter it on a different IP. Postini's a mail filtering company, I'd be willing to bet they have a lot of IPs that allow inbound mail. :) I am just trying to understand how postini is bypassing my anti-spam ACLs. Again, you haven't answered his question Did your ISP or some other email provider possibly sign up for Postini? How many different domain addresses forward into your account? If you accept mail from any other server for any other domain, that domain could be a postini customer. Postini does not originate or forward spam, they filter mail destined for their customer domains. Some spam gets through their filters, because spammers are smart and adaptively evil. It's really quite simple. -- Ray Wong [EMAIL PROTECTED]
Re: .ORG DNS Problem?
Or if you can't reach em, even good old traceroute can be useful... Ray On Thu, Jun 24, 2004 at 09:45:24AM -0700, Mike Damm wrote: rant A reminder to folks giving status reports on anycasted DNS deployments, don't forget to mention which node you are querying. For the F root (and other BIND implementations): dig +norec @f.root-servers.net hostname.bind chaos txt For UltraDNS: dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a /rant I'm seeing no problems with tld1.ultradns.net (udns2pxpa.ultradns.net) or tld2.ultradns.net (udns2eqsj.ultradns.net). -Mike -Original Message- From: Alexander Bochmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 7:49 AM To: [EMAIL PROTECTED] Subject: Re: .ORG DNS Problem? Hi, ...on Thu, Jun 24, 2004 at 11:18:26AM -0400, Adam Kujawski wrote: Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Same here, until a few minutes ago. Didn't work (connection timed out) from various places in Europe, while I had no problems when coming from a host in the US. Alex. -- AB54-RIPE -- Ray Wong [EMAIL PROTECTED]
Re: Postini, Re: Verisign vs. ICANN
On Fri, Jun 18, 2004 at 08:02:34PM +, Edward B. Dreger wrote: JN Date: Fri, 18 Jun 2004 12:56:11 -0600 JN From: John Neiberger JN Postini's patent issue (do a Google search to get more info) JN is suspicious, and _possibly_ indicative of a slimy tactic. It does look pretty ridiculous. ETRN, formail, procmail, Web- based UIs, etc. have been around far longer than Postini. Yep, and NAT, PAT and stateful inspection exist outside of Cisco. This need by already dominant players to patent everything related to their business is unpleasant enough, but it's also common enough to make singling anyone out as slimy to be a bit disingenuous. I'd hazard to guess that a large number of folks on this list work for employers with similarly ridiculous patents. -- Ray Wong [EMAIL PROTECTED]
Re: Verification required for steve@blueyonder.co.uk, protected by 0Spam.com.
Only because I was up checking on a remote problem... This is the future of e-mail, if something better at spam suppression doesn't come along. Like the Delete function? what's NOT better than easily duped validation mechanisms? Perhaps the only reason spammers haven't bothered is because adoption rates are so low. Consider: 1) in order to reduce annoyance, systems validate essentially ONCE. At best, they're going to validate once a month or so. 2) it's trivial these days to register a fresh domain and enter auth servers. Fraudulent registrations are already common. 3) DHCP assignments on broadband are *just* stable enough that someone can setup some verifiable servers and send some mostly mundane messages 4) it's technically trivial to collect verify responses and direct things into a bot that senses a validation system and replies(via email or web, either is a well-known pattern that MUST remain valid once deployed to customer sites, to be useful to the customers) as needed. 5) it'll take longer to clean these out of your validation system than it will for them to move onto another domain that's newly in(hours). All you've really down is open up your whitelisting policy to the outside world. Well, that and tie up more system resources to manage the database. Now ask yourself how you're going to track down a validated server that went away, to be replaced by more spam from 0wned systems. Your own protection system has opened the door. You think getting help stopping a DDOS in progress is bad? And of course, the folks you're asking for help are the ones getting spammed by your validation email to begin with. Congratulations. If these annoying systems become widespread, very smart people with more time than us to work on it will have no trouble defeating them. A message you recently sent to a 0Spam.com user with the subject Re: Source address validation (was Re: UUNet Offer... was not delivered because they are using the 0Spam.com anti-spam service. Please click the link below to confirm that this is not spam. When you confirm, this message and all future messages you send will automatically be accepted. http://www.0spam.com/verify.cgi?user=1079785893verify=568107 -- Ray Wong [EMAIL PROTECTED]
Re: example.com/net/org DNS records
* Are they breaking anti-UCE filters by doing this? (yes) How? They own example.com. If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter? Why should example.com be any different? they will likely never use the domain name, so probably wouldn't care if you feel the need to blacklist it explicitly, for that matter. Roger Marquis Roble Systems Consulting http://www.roble.com/ -- Ray Wong [EMAIL PROTECTED]
Re: Stupid .org registry code change
On Mon, Dec 22, 2003 at 04:18:37PM -0700, Michael Lewinski wrote: Sponsoring Registrar:R11-LROR All I really want to know is the Registrar's name/URL to tell my client so they can modify their nameservers. Does anyone have: 1) A URL to the table that will allow me to lookup a name from the above code (or better, a hack to whois that will do said lookup for me)? http://www.google.com/search?hl=enlr=ie=UTF-8oe=UTF-8q=R11-LROR+registrar which finds: http://www.orgtransition.info/whois/registrar_list -- Ray Wong [EMAIL PROTECTED]
Re: Hijacked IP space
While it's definitely worth submitting it to completewhois and developing whatever paper trail it takes to give it back to the registrars if they don't want to keep it, another obvious stopgap would be to advertise the space, Does anyone actually have a low-cost offering to do this officially? This is almost a network operation issue, even if it's more about network non-operation. =) Part of the whole point is that people stop routing the space itself in the first place, for many reasons. In my case, it's gotten harder and harder to find ISPs who have the clue/pricing to actually route space they didn't get assigned. I'm not a big bandwidth customer, but (when budget again allows) would like to have portable space that isn't tied to a single upstream. I've received a couple offers of help, but doubt we want to advocate setting up a volunteer network of nice guy ASs. It would seem to be a relatively easy offering to make, not really any more complicated than domain name parking or any of the other services that tend to be in the add to configuration once, remove at end of service category. I do think it's worth paying a few bucks for, and would happily have done so before, even without knowing what trouble NOT advertising it would lead to. Either a parking web-site or even a null route would have simplified life dramatically. A tunnel to a residential linux/bsd box would have been nifty, if not particularly reliable or wise. Anyone? Should such a boutique offering be official somewhere or what would be the reason not to? -- Ray Wong [EMAIL PROTECTED]
Re: Hijacked IP space.
On Mon, Nov 03, 2003 at 04:47:44PM -0500, Chris Lewis wrote: [ re: 204.89.0/21...] No announcement for that block has been visible here at any time in the past couple of weeks (specifically, since Oct 13). We might have missed it if it was never announced for more than a few minutes at a time, but it's _much_ more likely that the block was never announced and was merely forged into headers of a spam. Our system reports that neither that prefix, nor any of its more-specifics, has been seen in the global routing tables at any moment since January 1st, 2002. [ http://www.renesys.com ] We haven't seen anything from that block in our spamtrap either for at least a week. The .224/24, on the other hand, it a real sewer. Correct. Unfortunately, that's my old block and I wasn't quite ready to hand it back since I'd sort of wanted to announce it again. I've been trying to chase down CW as the upstream of AS 30080, the jokers who've been pulling this stuff for quite some time with other blocks. My POC updates to ARIN keep getting rejected, so yes, it looks like an abandoned block with an old netcom.com address. I'm starting to figure that, given the delays, there's been enough damage done that 204.89.224/24 will never be able to get off the blocking lists anyway, so perhaps I'll turn it back in afterall. *sigh* That's what I get for trying to find low-cost ISPs willing to announce portable space. -- Ray Wong [EMAIL PROTECTED]
Re: first Yahoo, now RoadRunner?
RR has been using a lot of blocks for quite some time. Fortunately, they were very responsive when I mailed their abuse address as indicated on that URL. I gave them the allocation I was responsible for, asked for that subset of addresses to be unblocked, and things were fine within the day. Was simple, if somewhat annoying. On Fri, Oct 10, 2003 at 10:03:29AM -0400, Mark Jeftovic wrote: rr.com blocking our netblock since this morning now 5.7.1 Mail Refused - 216.220.40 - See http://security.rr.com/mail_blocks.htm#security Anyone else? -- Mark Jeftovic [EMAIL PROTECTED] Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237 -- Ray Wong [EMAIL PROTECTED]
Re: News of ISC Developing BIND Patch
On Tue, Sep 16, 2003 at 04:07:21PM -0600, John Neiberger wrote: http://apnews.excite.com/article/20030916/D7TJOF3G0.html -- my favorite: VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual service providers were free to configure their systems so customers would bypass Site Finder. But he questioned whether releasing a patch to do so would violate Internet standards. ^^ What else is there to say? Any bets that Verisign tries to accuse ISC of being a terrorist organization once the patch comes out? At the least a spurious lawsuit seems certain. -- Ray Wong [EMAIL PROTECTED]
list thoughts on unsupported hardware?
I realize this isn't arguing about Windows patch mechanisms, but recently realized I've never answered this issue to my own satisfaction... How long do we keep upgrading and using network hardware once it's fallen off the support lists? The Cisco 7500 finally went off back in Feb of this year, as I recall. 3rd party upgrades, and used parts, are still readily available. (Actually, does anyone have suggestions on vendors for said upgrades and parts? I've noticed a lot more discounting than in the past, but usually from vendors I have no experience with). A client I've recently taken on happens to be relying on a 7500 for their border. In reality, their current use could fit on a 2621/2650, though they have been much larger in the past (there's a small pile of DS3 cards sitting on the shelf). They're still relying on a single provider for connectivity, etc. So, does anyone have any thoughts on how long we should be letting our poorer customers/employers live with products that are officially off the support lists? Clearly there will be (i.e. IOS) image support for quite some time. Is keeping (tested) spares around sufficient to justify actually spending some money to fit the newer/larger images? Newer/still current hardware seems much more a no-brainer, but advocating spending a thousand bucks to avoid spending 5x that on a more current fire-sale item is a little less clear, to me. -- Ray Wong [EMAIL PROTECTED]
Re: Some very strange network behaviors
Even if a switch floods all ports, it does not change the fact the packet will not have the correct MAC address and his NIC should never pass it up the stack. Switches do not rewrite the Ethernet addresses on packets. Correct, ethernet switches do not. The question is, what were the systems in question connecting to? Many hotels bought into proprietary broadband systems, some of which are still in service. Just because there's an ethernet port in the room says nothing about the hotel's internal net. Some of them did(do) a very poor job of encapsulating or translating the ethernet (or even layer 3, some of them were IP-only) at the room, converting to some other p-t-p method (i.e. atm pvc logic, similar to dsl), and again converting (badly) back downstairs. It's entirely possible the next IP speaking box in line does not, in fact, know what the MAC of the client PC on the end of the line actually is. Room 2037A gets the traffic for room 2037A, regardless of what the router's arp cache or the switch's mac map actually says. The MAC seen may very well be generated by the concentrating equipment and not the peecee. Even if the IP is negotiated with the node, a la pppoe, there's no certainty that the traffic isn't modified in between. Without speaking to someone in the know about the hotel, there's no telling what actually happened. All of which misses the issue he suggested, that traffic in any public arena must be viewed as suspect. Yes, Corporations who rely on an edge firewall solution and do not standardize on some form of node protection and audit process are likely exposing themselves to this sort of thing all the time. Should they fix it? Probably, but few of them are employing me/us, so there's nothing I or most here can do about it. That's not a technical problem. :-\ -- Ray Wong [EMAIL PROTECTED]
Re: Microsoft distributes free CDs in Japan to patch Windows
On Mon, Sep 08, 2003 at 06:59:25PM +0200, Niels Bakker wrote: And getting the lead time down to 4-6 weeks would be a challenge - remember you have to *ship* the re-mastered patch CD to every retailer and get it on the shelves. That's going to hit your bottom line. * [EMAIL PROTECTED] [Mon 08 Sep 2003, 18:03 CEST]: Ever heard of Windows 98? How about Windows 98 SE (Second Edition)? Windows 98SE was only available to OEMs and wasn't on shelves in stores. As Valdis also notes, it's an entirely different situation. Oh, this topic hasn't died yet? Very well: Of course the normal retail software channel doesn't work and would cost too much money. Strawman. A patch CD isn't a product, to be distributed in shrinkwrap and left to sit. It's a periodical (especially in the case of Microsoft, but really, for all of them) with a looser timetable. Ever notice how much trouble the Wall Street Journal has getting a daily issue out for under a buck? How about Business Week, or any of the weekly rags? While it may seem that MS has daily patches, a weekly update is essentially adequate, and likely the finest granularity most folks are going to update on if they actually do attempt it regularly. CDs happen to cost a lot less than a printed magazine, too. Back in the mid 90s, it was trivial to have batches in the low-thousands count (easily handled locally, near the customer acceptance point, rather than centrally, near the vendor) priced in whole cents. Today, it's possible to price the same for fractional cents. The real question: If people don't care enough to hold Microsoft (or any software producer) accountable for the product at sale, what good will having this alternate channel be? Arguing the practicality of CDs as a patch distribution mechanism is pointless, it's trying to find a technical cause for a non-technical problem. It's not a matter of being ABLE (technology) to do something, it's a matter of DOING (people). Sun (to pick a convenient example) was able to ship patch CDs every quarter or month, depending on when you asked and what your support options were, for years in the 90s. Yes, it did fall on us, the IT folks, whether we were called Systems Managers, Network Administrators, whatever, to ensure that policy and procedure included getting the updates IN. We learned our lesson with the Morris worm if we hadn't learned it before that. How many sites hit with Blaster or Sobig.f were business with at least one person designated as IT staff? Too many. That home users have multiplied to even greater numbers than business users is another problem, but realize that many folks who think they can handle their home PC believe so because of what they see at work. (Unemployed people, barring laid-off IT folks who shoul know better anyway, generally cannot afford computers). Culturally, people will be more likely to discpline themselves when they get used to seeing other people disciplined enough to maintain things elsewhere. Call it peer pressure if you have to. I seem to be repeating myself a lot: The problem is not technical; hence the solution is not technical either. Now, other than being a poor attempt to pass the buck, how does this help us as network operators (and similar IT professionals) in fixing the problem? -- Ray Wong [EMAIL PROTECTED]
Re: Microsoft distributes free CDs in Japan to patch Windows
On Mon, Sep 08, 2003 at 01:40:01PM -0400, Sean Donelan wrote: On Mon, 8 Sep 2003, Ray Wong wrote: I seem to be repeating myself a lot: The problem is not technical; hence the solution is not technical either. Now, other than being a poor attempt to pass the buck, how does this help us as network operators (and similar IT professionals) in fixing the problem? If infected users have an offline method for obtaining patches, then we don't need to figure out a way to keep their buggy, infected computers connected to the network long enough to download the patches. very well. Then see my comments about how doable it is to produce and distribute CDs cheaply. It's practical if folks care enough to bother. Of course, since we STILL have to handhold users into doing things, why not just download the patches to our own servers, and either make CDs as a courtesy to customers, or setup a quarantine network we shove them off to, which only has access to our local patch server? M$ still does have everything downloadable, for those of us who can figure out how to do it. This is one reason why universities are distributing thousands of CDs with the fixes to their students. For this latest mess, a floppy actually suffices. I handed quite a few out, once I found some. :-) -- Ray Wong [EMAIL PROTECTED]
Re: BMITU
that nothing can equal, much less beat, sendmail. This is especially true when you start talking about filtering for spam or viruses via the milter interface. Well, considering that milter is sendmail's, yes, wanting to use the milter method gives sendmail an advantage. There are plenty of other options if you choose the filter method suited to each mail server. What are people using for network based anti-virus? A friend of mine started a company www.raeinterent.com/rav and claims to have an industrial broken link btw. probably meant raeinternet.com? They no longer claim anything except to have been acquired by M$. anti-virus app that plugs into Communigate Pro. Any experience with network based anti-virus mail systems? I sure wouldn't call an antivirus scanner that runs on the most common target platform an ideal solution. In terms of high-performance anti-virus, go to Trend Micro. While they have their problems, the vscan interface is the quickest and most scalable scanner I've found. 500k users is one thing. Being able to handle the unpredictable traffic (mail volume over time) for those users is another. Being able to open each message, recursively open up containering file formats (zip, tar, rar, et al) and scan the actual file for viruses is still another. I don't particularly care for their sendmail replacement solution, but vscan is a solid component solution. Admittedly, my own experience is limited to about 1 million messags/hr, so depending on your actual mail traffic, it may not hold up as well. Ignore the data you have on sending mail, or at least put it in its place. It's much easier to keep up your own outbound traffic rate than it is to deal with the same quantity of inbound traffic (sendmail can easily flood an identical sendmail configuration, or at least render it unable to talk to anyone else due to being busy -- yes, you can rate limit senders, but that is not scaling your own ability to accept traffic now, is it?). While none of the unix options are stellar at it, windows options tend to be even more inefficient at I/O operations, rather critical when you're dealing with a lot of small files, such as in a mail server. Unix options generally have an easier time dividing traffic across spindles as well, which is one way to buy yourself more throughput. I've had very encouraging results with Postfix over the years, and it fails the most gracefully and consistently of any common server I've tried. This is quite valuable in designing a reliable and scalable solution, imho. It's fairly easy to plug in modifications as needed, and extremely easy to handle routine configuration changes. Parallelized management works as well as nearly anything. Qmail can be bent to do many things, but was intended to be small, so adding features gets increasingly painful with each addition. If you have made the religious decision that only Windows based servers can do the job for you, your only hope would be Domino. Call IBM, then setup a postfix relay box in front of it to fix the (outbound) headers. :-\ Every other windows-based mail server I've seen fails (often dramatically) at 20k or so users, or smaller. Domino fails too, but at least tends to parallelize well. It also has a path upwards in the event you choose your underlying platform poorly. Whatever it is, you're in for some, umm, interesting times. I still remember my own experiences quite vividly. :) -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 04:04:42PM -0400, Vivien M. wrote: You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Did I miss the obvious? This is not a technical issue. You have presented a case where one lacks the (free) resources needed to perform one's job. This is something you take up with your manager. I could easily do this part during my off hours, it just requires the mail server admin to setup (free) SMTP AUTH s/w to limit access to us employees. If not, the company policy is not to do work during off-hours. It can wait until you get in the next business day. (Note that policy here is defined by the actual behavior, not the statement of policy, which can be wrong) Hence, if no SMTP AUTH relay, you're screwed. Sure. And if they throw the (power) circuit breakers at work, none of my computers work (for long) either. That's not a limitation of the grid. -- Ray Wong [EMAIL PROTECTED]
Re: What do you want your ISP to block today?
On Sat, Aug 30, 2003 at 08:33:54AM +0200, Iljitsch van Beijnum wrote: What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service Eh? Have you ever run a mailing list? The majority of subscribers NEVER post. Those who do, post prior to the large quantity of traffic originates. I suppose the latter can be accounted for using positronic equipment instead of electronic. =) Legit mailing lists may not be 99% of total traffic, but they're sure a good chunk of legit email. attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort. Sure, and I scan my systems from outside all the time. I'm looking for validation that my system has NOT started listening on ports I don't run services on. It's called external monitoring, and is rather useful in letting me get a good night's sleep. Could I do it locally? Sure, but I'd still need a way to verify my sites can be reached from other places. If you want to know how TCP is working to a destination, you have to use TCP to test it. When I'm working a half dozen part-time contracts, each of whom has multiple servers scattered around the country, this traffic may well be nearly continuous. My employers will know about this (it'll be in some memo that no one read), but I'm not going to find every transit provider I cross to warn them, too much hassle. I'm probably not even going to tell my ISP, as it's none of their business. Are those patterns common among DOS/DDOS? Sure. You'll need to do more analysis than that to determine if that's, in fact, what you have. Scans by themselves certainly aren't inherently dangerous. Heavy levels of them? Well, who gets to define heavy? A cracker might need only 2 or 3 scans to get the info needed to attack a site. I probably need a few hundred a day to verify said cracker hasn't succeeded. A script kiddie might run hundreds, or more, or less. -- Ray Wong [EMAIL PROTECTED]
Re: What do you want your ISP to block today?
On Sat, Aug 30, 2003 at 02:53:46PM -0400, [EMAIL PROTECTED] wrote: On Sat, 30 Aug 2003 14:09:40 EDT, Joe Abley said: That won't save them when the time required to download the patch set is an order of magnitude greater than the mean time to infection. This, in fact, is the single biggest thorn in our side at the moment. It's hard to adopt a pious patch your broken box attitude when the user can't get it patched without getting 0wned first... how about ACLing them? upstream from customer: permit udp customer ISP's nameservers port 53 permit tcp customer windowsupdaterange port 80(?) for as much of the windows update range as can be found. Since they've recently akamai'zed, this is somewhat predictable. Downstream, you can either setup stateful, or just be lazy and hope that allowing estab flag is enough... ACL can be either templated or genericized for the OS. (replacing customer with any means the customer pvc (assuming DSL) can only hit microsoft regardless of spoofing. Similar ACLs can be setup for Solaris, OSX, even various flavors of linux. being able to at least semi-automate router config changes is a requisite, but not insurmountable. This will, no doubt, increase support calls. How much compared to a pervasive work is left as an exercise to the reader. -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 09:29:42PM -0700, Michel Py wrote:
However, trying to be pragmatic, this is a situation that will
eventually solve by itself: Since having {Pacific Bell | your ISP} do
anything about it is not an option, when these customers are trying to
email to {AOL | some ISP} and are blocked, they will try first to have
if {AOL | some ISP} to whitelist the address; if it can't be done they
will say get an ISP that does not suck.
Of course, it's also possible people will just work around it, like so
many other things. Postfix transport maps allow relaying of specific
domains through (for example) pacbell's mail server, as does Qmail's
smtproute file, no? I'm supporting a handful of smaller sites, and don't
have the time to chase down some support drone to request whitelistings.
It's just too easy to add aol.com SMTP:mail.sbcglobal.net or whatever.
If an incompetently run ISP relay server makes AOL happy, then their
customers can enjoy having mail delayed for the extra hours and maybe
dropped altogether.
Eventually things will implode. Until then, I predict poorly thought
out hacks will be answered with other poorly thought out hacks. =)
--
Ray Wong
[EMAIL PROTECTED]
Re: dry pair
Good luck getting one from anything but and old-bell. New LECs tend to think only in terms of the switch side, since the last mile belongs to the ILEC anyway. Even the ones that know it don't want to support it, as they can't do any remote testing when it dies, requiring local wire and cable staff. Use old-bell terms, dry pair is very much a network admin's term. alarm circuit, off-premise extension line, (like if you had your own PBX and need another office to run off it), series 1100 line, or maybe LADS. On Fri, Aug 29, 2003 at 11:08:10AM -0500, Austad, Jay wrote: Does anyone know to go about getting Qwest or a CLEC to patch through a dry pair between two buildings connected to the same CO? When I called to order one, no one knew what I was talking about. -jay -- Ray Wong [EMAIL PROTECTED]
Re: Cross-country shipping of large network/computer gear?
On Wed, Aug 27, 2003 at 08:31:58PM -0500, Andy Walden wrote: On 27 Aug 2003, Robert E. Seastrom wrote: Yes, but my point is that you can stack the deck in your favor by using a company that uses appropriate material handling devices to move every package if you are shipping packages that are heavy enough that moving them with a handtruck or by hand is possible-but-unwise. I can agree in principal, so long as we can designate a company that will execute proper company policy and do so *every* time. Unfortunately, for So your position is that the the existence of exceptions defines the probability and severity of damage? That 1% and 40% damage rates are in fact the same? $10 and $10,000? the purpose of the general well-being of our gear, we arrive back at generally blue collar, none-the-less, well paid, package handlers that individually define preferences for how they feel like doing it that day. I still fail to see why I would choose an organiztion with handles hundreds of times more packages, most weighing less and being less breakable than mine, over one with the specialized equipment to move it. An air cargo carrier with heavy-cargo equipment is still less likely to drop a pallet off a pallet jack than an express shipper with a handtruck. That their respective employees are equally lackadaisical doesn't mean all other factors have been equalized. Cargo/freight carriers, in general, are also aware that nearly all their cargo is of declared value, that the fragility warnings are more likely correct, and, perhaps most important, that the customers are far more likely to be filing damage claims against them. Fedex, et al, know that most of THEIR packages are paper and other sturdy items, and that their customers are much less likely to notice/claim damages. It's somewhat like card counting in blackjack. The odds are still quite poor, but that n% shift can make the difference of coming out of the casino money ahead or behind. Of course, good packing is critical either way. If you're going freight, palletize the items with proper/extra padding/packing material, stick some damage (shock and tipping) indicators on each side, and tuck an INSPECTION CHECKLIST for whomever is on the receiving end (not they won't have their own copy, just sends a sign to anyone handling it that someone's going to look when it arrives). If you're still determined to use a shipper, pack and pad it well, then pack that box into another padded/packed box. If you're desperate to get it moved ASAP, see if you can find a college intern you can pay to drive it. You'll want your own people to load it in and out of the car/van, but it'll be cheap and probably less risky than relying on the odds with a shipper. -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 10:18:45AM -0400, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? We block outbound port For some, sure. Maybe even most. That doesn't mean all. Are you a fairly small, perhaps boutique, provider? Such players have very different rules than ones with more than one kind of customer. 25 connections on our dialup and DSL pool. We ask our customers that have their own mail servers to configure them to forward through our mail servers. We get SPAM/abuse notifications that way and can kick Asking is one thing, forcing is another. Giving the option but leaving the choice entirely up to the customer's discretion is yet another. Giving a default, but allowing customers to request exceptions, with reasonably automated tests to verify they can handle it... well, you get the idea. You get SPAM/abuse notifications without diverting all mail through you. You need to investigate either way (unless you trust unknown third parties more than your own customers), which still doesn't require all mail to pass through your server. the customer off the network. We also block inbound port 25 connections unless they are coming from our mail server and require the customer setup their MX record to forward through our mail server. We virus scan all mail coming and going that way. We protect our customers from the network and our network from our customers. We are currently blocking over 3k Sobigs/hour on our mail servers. I would rather have that then all my bandwidth eaten up by Sobig on all of my dialup/DSL connections. Do you also limit your customers' use of web traffic? Bandwidth, at the end of the day, is still bandwidth. Having it all eaten up is a problem, but not enough justification to take away all choice. Your own border shouldn't be that much greater than the aggregate total of your customers, should it? That'd be bandwidth you pay a lot for and can't use. Usual model would suggest your downstream customers represent some value more bandwidth from you than your incoming server could get, or perhaps 1:1. What if I have my own virus scanner? What if your mail server is too slow because all those scans chew up a lot more resources than my own traffic on my server will? What size attachments do you allow? What spam filters do you run; do they account for sender IP in the same probability weighting that mine does? Even per-user configuration of filters like Postini represents a reduction in choice that may not fly with all customers, particularly small and home busineses. Finding solutions that account for the broadest number of cases is useful. If you provide a server architecture doc the way I can expect to see line topo docs, then maybe I'll trust you to get it right, or maybe not. Expecting to tell customers, I know how to run an email server better than you, doesn't fly in this age of bonehead ISPs, at least not for a lot of us/them. Perhaps you do the former; if so, please let me know if you provide service in the San Francisc/Sillycon Valley area, as our choices in home/small pipe have declined quite a bit these years. =) SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) Let's back up. It's entirely possible, even probable, that any ISP I go to will provide good Internet (pipe) and bad Service (protocols), or vice-versa. If they're good pipe, I can setup my own server, and have everything I need. Providing reliable and high-rate connectivity does not mean I trust you, or anyone else, to run an extra man in the middle. You, of course, are not required to trust your customers, and your policy will self-select out the ones who disagree, but suggesting it's applicable in enough cases to be a general standard misses the point. I can think of a number of businesses (including some who are fairly well known in email software, services, etc) who came up with the use of DSL as a server home. They may not rely on it for their primary bandwidth (which would probably be foolish), but particularly for things like DNS and SMTP, both of which provide for multiple addresses and locations, could sanely choose to maintain secondary servers over a completely isolated alternate pipe. Remember, BGP fails, ISPs fail, T1 cards fail, routers fail, etc. Having that last home DSL connection may just save some companies from going totally unreachable at times. That's worth $79.99/month in many books. -- Ray Wong [EMAIL PROTECTED]
Re: North America not interested in IP V6
On Sat, Aug 02, 2003 at 07:10:38PM +, Christopher L. Morrow wrote: On Sat, 2 Aug 2003, Niels Bakker wrote: [E.B. Dreger writes] Assign unchanging IP address based on MAC address. Done/done. * [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Sat 02 Aug 2003, 20:28 CEST]: And quadrupple your techsupport costs? Thanks, but no thanks. For always assigning the same IP address to a customer? Why would this increase support costs? especially done via dhcp... you could probably even automate getting new ips from a dynamic pool and slapping them into permanent assignments. And when the customer slaps in a replacement NIC (recall that with wintel NICs the MAC is carried with the card) and he can't get his old address back, do you expect to convince all your customers that's ok, or train your support folks to go into your DHCP config database and reassign the permanent assignment? Or do you setup a web-based reg system whereby the customer must connect and get the address reassigned? How little support do you think any of those options will require? Who was it that said, if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation? -- Ray Wong [EMAIL PROTECTED]
Re: North America not interested in IP V6
On Sat, Aug 02, 2003 at 09:43:45PM +0200, Niels Bakker wrote: Assign unchanging IP address based on MAC address. Done/done. BUT: I don't think Chris and me were thinking about big bad ugly LANs with customers attached indiscriminately, though. With DSL provisioning systmes using RFC1483 bridged (do I have my buzzwords correct here?) the Correct RFC, close enough. DHCP server can discriminate between customers based on VCI/VPI numbers instead, negating the need to look at the MAC address of the request. Note the exlusive conditions presented by the position you defend and your own. The point being, relying on MAC address is a problematic idea. Yes, you could configure an address based on the PVC; Redbacks even like being configured that way. BTDT. There are still any number of situations whereby you will get grumpy customers loading up your support lines with problems. Who was it that said, if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation? Or you don't understand ours. After all, it's currently all getting done already this way. The question is of specific versus general cases. Not seeing the drawbacks because you can cite a place where something is successful does not solve the problem for everyone else. In reality, this is not a technical problem, hence there is no way to win. -- Ray Wong [EMAIL PROTECTED]
