- Test - lists.nanog.org

RE: Scanning (was Re: Stealth Blocking)
by Roeland Meyer 27 May '01

27 May '01

> From: woods(a)weird.com [mailto:woods@weird.com] > Sent: Saturday, May 26, 2001 11:02 PM > > [ On Sunday, May 27, 2001 at 00:17:29 (-0400), William Allen > Simpson wrote: ] > > But, ORBS > > remains indefensible. > > It would seem that I have no problems either defending it, or > using it. > Whether I'm successful in the latter endeavour is only for me > to decide. > Whether I'm successful in the former endeavour is a larger question. > > > The MAPS leads to far fewer mistakes -- does not block non-relaying > > servers just because they don't think the network has sufficient > > "action against spammers in recent months." That's entirely > > judgmental, not operational. > > The mechanically verified part of ORBS cannot, by definition, > lead to any Greg, it all comes down to ONE major issue ... collateral damage. > > We've been > > falsely accused by ORBS, > > Which list were you on again? Wasn't it the manual netblocks list? > > > without any evidence of spamming. He makes a perfectly valid point here. In the past few days I have seen much testimony, from folks right here on this list, that were listed on ORBS. I've also read testimony that their systems were never used for spam. I can't imagine a spammer being on this list for long. Nor, can I imagine those illustrious folks being spammers. Yet, they were on the ORBS list. BTW, MHSC systems were also carried on ORBS for a while and when they were, over 50% of my bandwidth was used to fend off crack attempts. Thank gawd I was using MAPS at the time. None of the relay attempts got through. Although, I *did* have to replace a couple of weak BIND boxen (thanks for the extra work, BTW >:P ). Brother, that is the very definition of collateral damage. In fact, it was worse. It's "friendly fire". If we start taking out innocents and even our own guys, the spammers will win. We need to start fighting the PURE WAR against spammers. What ORBS does is to find innocents and paints bulls-eyes on them for the spammers to find easier. The argument ORBS presented, on their web-site, to justify this, is terribly weak. It still amount to pointing the guns ... in the WRONG direction. > Please do not forget that ORBS goal is not to detect or > prevent spamming per se. But, without spammer behavior, open-relays are perfectly acceptable. Else, why was it the default option in sendmail for so long? The "anti" argument falls over dead without spammers. It's not the gun, it's the bloke pointing it. > It's full name should make this clear: Open Relay Behaviour- > modification System. Any open relay is a bad thing regardless of > whether it has yet been abused by a spammer (because it will > undoubtably be abused unless it is closed first). You make my point here. Remove spammers and ORBS becomes nothing more than a totalitarian tool for a political agenda without merit. If I can run a relay system safely (without spammer abuse) then you have lost the right to tell me I can't do so because there is no possible damage to your systems. It's also a control issue, I strongly resent someone, whom isn't paying the rent here, trying to modify my behavior. I get enough of that from my government. > > ORBS blocks for political reasons, rather than technical. > I guess I can't really disagree with that, though I will > point out that > I am using ORBS as a deterrent against such acts of theft of > service and > fraud and thus it is in fact what's known as a "technical control". Can't you see how inherently corrupt that is? Drop ORBS and go with MAPS. Be friendly to your friends and disdain only those that are truely your enemies.

2 1

RE: ORBS (Re: Scanning)
by Roeland Meyer 27 May '01

27 May '01

> From: Patrick W. Gilmore [mailto:patrick@ianai.net] > Sent: Sunday, May 27, 2001 11:27 AM > (NOTE: I assume we are only discussing the MAPS RSS, not > other MAPS products.) Incorrect, I was discussing MAPS RBL.

2 1

RE: ORBS (Re: Scanning)
by Roeland Meyer 27 May '01

27 May '01

> From: Derek Balling [mailto:dredd@megacity.org] > Sent: Sunday, May 27, 2001 10:49 AM > > At 9:11 AM -0700 5/27/01, Roeland Meyer wrote: > >A system that tests positive for ORBS , yet is using MAPS, > will not be used > >as a spam relay. Yet, ORBS will list such a system. > > I'm not sure I understand this logic: > > 1.) They test positive for orbs... so they ARE an open relay > 2.) That system is using MAPS, which means that there is some subset > of systems the open relay itself rejects mail from I somehow missed your logic here. A MAPS blocked system is, by definition NOT an open-relay, since it IS MAPS-blocked. Yet, ORBS will list it as an open-relay. I agree, there is a disconnect here. Your second premis invalidates the first. This may be a semantic issue, please examine and clarify. A MAPS-blocked system may show as an open-relay to another system not listed in MAPS. However, it will show as closed to a system that is listed in MAPS. It all depends on the source of the test. AHA! Maybe ORBS should be listed in MAPS? That will certainly resolve this problem and ORBS will no longer show false positives. > Somehow that means that non-MAPS-listed sources (of which there are > many) are somehow magically restricted from relaying through the open > relay? Since your first sylogy didn't parse, this one didn't either. I might point out that, since MAPS has been running for a few years, most if not all, the spammer sources are now listed.

3 2

RE: ORBS (Re: Scanning)
by Roeland Meyer 27 May '01

27 May '01

So, you aren't happy when I build a poisoned cake for spammers, you want me to use your specific recipe... even if mine works (better?). Tell me how a MAPS-blocked system can relay spam. Yes, I'll concede that your approach may work, albeit at higher HW cost than my approach. BTW, the MHSC answer to our ORBS listing last year is to drop sendmail and build an MS-Exchange server so that we can authenticate with Win2K Domain logins. But, that's very expensive and doesn't scale well. We also support both PPTP and SSH VPN tunnels. There are obvious problems with both, as I've discovered in practice. 1. Seat license costs with Exchange (scaling issues). 2. Unless very carefully run, Exchange has serious security issues. 3. Exchange is good groupware for corps and way too much for normal users. 4. Many firewalls block any and all tunneling technology. 5. POP-based solutions demand widespread deployment of POPs. If a user is out of POP range, they have to make LD calls. Plus there is an incremental HW cost per POP. If one has a largish number of POPs this is significant addition to the out-of-range LD charges that one still incurrs. > From: E.B. Dreger [mailto:eddy@noc.everquick.net] > Sent: Sunday, May 27, 2001 9:54 AM > > > Date: Sun, 27 May 2001 09:11:39 -0700 > > From: Roeland Meyer <rmeyer(a)mhsc.com> > > [ snip ] > > >> I don't buy the "we need open relay for nationwide users" argument, > >> either. Build a cheap MX that does nothing but take mail > from a given > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> POP, and send it to the world. Anti-spoofing at the border, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> don't accept mail from the outside world, and you're done. > > > You must not have a roaming staff or are willing to keep > telcos wealthy. > > Or I might know a better way. > > Again, put a simple MX at each POP. Want a constant IP > address for the > SMTP server? Each POP's border router redirects the SMTP server's IP > address to the local machine, which only allows inbound SMTP from the > local POPs. > > Nothing new here. > > And then there are VPNs for roaming staff...

2 1

ORBS (Re: Scanning)
by E.B. Dreger 27 May '01

27 May '01

> Date: Sun, 27 May 2001 02:02:24 -0400 (EDT) > From: Greg A. Woods <woods(a)weird.com> >> But, ORBS remains indefensible. > It would seem that I have no problems either defending it, or using it. ORBS catches far more than MAPS. My take is that anybody who has a problem with the infrequent ORBS probes should have a huge problem with the daily bombardment of relay attempts. Besides, whoever said that one must use ORBS "out of the box"? I maintain a whitelist of IP addresses to override ORBS. As much as I'd like to see Earthlink get a clue, MSN close their relays (have they yet?), and RoadRunner cooperate, I allow their MXes through when I find them. Modern spammers have gotten nasty. They use hundreds of different relays, each time changing the source address: a57e6s(a)t8iji7.somedomain.tld in46hi(a)diief4.anotherdomain.tld xkm8ey(a)ithi62.yetanotherdomain.tld with * DNS so that all subdomains resolve, and the subject: I have no respect for netiquette!!!!! [i35ed7] I have no respect for netiquette!!!!! [ed8ooe] I have no respect for netiquette!!!!! [h8qi2h] So as to throw off MXes that look for the same message again and again. I suppose that scanning the body and looking for repetition is possible, but it's only a matter of time until _that_ get perturbed in 100 different fashions. Bottom line: Blocking mail from rogue servers is the best way to stop spam and to not be a party to somebody else getting relay-raped. Anyone with clue closed relays how many years ago? I don't buy the "we need open relay for nationwide users" argument, either. Build a cheap MX that does nothing but take mail from a given POP, and send it to the world. Anti-spoofing at the border, don't accept mail from the outside world, and you're done. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

1 0

RE: E-mail vs. FTP -- ***RTF RFC***
by owen＠dixon.delong.sj.ca.us 27 May '01

27 May '01

I fight FUD almost every day. The reason FUD succeeds is because people who know better are too lazy to fight it. Sure, it seems easier at the time, but in the long run, it just makes all of our lives harder. If you give a mouse a cookie, it will come back for a glass of milk. Owen > One of my clients, a largish dot-com, tried this ... resounding lack of > success. The end-user community did NOT like it when an email arrived with > links. They were too afraid that the link might point to a virus, among > other things (yeah, I know, but YOU try fighting FUD for a while). > > > -----Original Message----- > > From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > > Sent: Saturday, May 26, 2001 7:57 AM > > To: nanog(a)nanog.org > > Subject: E-mail vs. FTP -- ***RTF RFC*** > > > > > > > > Greetings all, > > > > Section 7.3.3 of RFC1341 addresses the external storage, > > expiry, et cetera > > issues. Not perfect, but a good first pass... and almost ten > > years old, > > too. > > > > ((( Thanks to Valdis for pointing this out! ))) > > > > We could probably kludge FTP as an interim measure: > > > > * MTA intercepts attachments, and spools them separately. > > > > * "access-type: ftp" with, e.g., username "msg12345recipient67890" and > > password "mi93et490" and "expiration: Mon, 28 May 2001 > > 00:00:00 +0000". > > The specific parameters would be generated on a per-message basis. > > > > * Mail admins can enforce quotas. Nothing new. The > > arguments in favor of > > electronic transfer are on the grounds of timely communication. One > > could argue that somebody not checking mail for a week > > doesn't deserve > > to receive their attachment without a second > > "transmission". The proxy > > MTA could insert a human-readable expiration notice or > > whatever other > > user-friendly prompting is deemed to be a good idea. > > > > * We could also forget the MIME method, and put in a > > human-readable link > > to get the attachment, a la electronic greeting cards. > > This would allow > > immediate use of non-registered access-type methods. > > > > Eventually, I'd like to see this done via HTTP/1.1 using chunked > > transfers. However, no current MUAs will support a non-existant HTTP > > method or any X-Experimental methods. For something that would work > > *right now*, I think that RTF RFC and going from there is the > > right way... > > > > Does anybody know what MUAs follow the RFC for external > > message content? > > A little smtpd and ftpd hacking could yield something workable PDQ. > > > > > > Eddy > > > > -------------------------------------------------------------- > > ------------- > > > > Brotsman & Dreger, Inc. > > EverQuick Internet Division > > > > Phone: (316) 794-8922 > > > > -------------------------------------------------------------- > > ------------- > > > > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) > > From: A Trap <blacklist(a)brics.com> > > To: blacklist(a)brics.com > > Subject: Please ignore this portion of my mail signature. > > > > These last few lines are a trap for address-harvesting > > spambots. Do NOT > > send mail to <blacklist(a)brics.com>, or you are likely to be blocked. > > > > > >

1 0

Acceptable limits of latency
by Sean Donelan 27 May '01

27 May '01

Gamers are very away of network latency, and can produce fairly decent reports describing what is important to them. Here is a nice report I saw on slashdot about the limits of acceptable latency for Quake gamers. http://members.home.net/garmitage/things/quake3-latency-051701.html

4 3

Anti-spoofing: is anyone doing it?
by Hank Nussbacher 27 May '01

27 May '01

I have recently been researching anti-spoofing for two ISPs and have an operational question or two. We have found that about 5% of sites are connected to 2 ISPs but do not use BGP. They use two different sets of IP addresses and point default to one of the two ISPs. The return traffic will of course go to them via one of the two ISPs, but if you have anti-spoofing filters set up or try to set it up now, you will break their outgoing traffic. Reasons to allow it: 1) Here we have multihomed customers, who are not eating up ASN space and are not asking for PI space and are happy the way they are working. By stopping them, we will force this 5% to ask for ASNs and PI space. So for the general well-being of the Internet - why not just let them be. 2) Anti-spoofing is set up to stop attacks from unknown IPs (RFC1918) or from an IP that doesn't belong to you. In this case, the IP can be traced back to the user (via ISP #2). 3) If you block it, the customer will leave and go to another ISP that does not block these IP addresses. Reasons to not allow it: 1) If ISP #1 has blocked the customer due to being an open mail relay (example), and then that customer just sends the traffic out via ISP #2 (using ISP #1 IPs), they have circumvented the filter and blame will be placed on ISP #1 for not stopping an open email relay (this has actually happened once before). 2) I should not be announcing traffic for IPs that I am not announcing routing updates. I am curious if others have found this 5% occurence and I am curious why no one else has raised this issue before. Could it be that almost no one is running uRPF and/or anti-spoofing filters? Thanks, Hank

3 2

Re: network policy (was Re: Stealth Blocking)
by Paul Vixie 27 May '01

27 May '01

following up my own post: > If the contract between the network owner and her customers does not allow > this type of policy-level traffic rejection, then she may have to stop. At > best this would be a matter for an arbitrator or civil court to determine. > It's certainly not something that third parties, including third parties > whose traffic is being rejected, to have any say in. > > Many restaurants have a "No shirt, no shoes, no service" sign out front. > Perhaps they lose the business of shirtless and/or shoeless persons. But > it's their business to lose. Outsider busybodies have no right to override > the expressed wishes of business owners. i invite debate, preferrably in private but i'll let challengers choose the forum. i've received absolutely no feedback on the above post, which either means that it's too correct to argue with, or too incorrect to bother with. if you think it's the latter, i'd like to hear from you, privately or not.

1 0

RE: EMAIL != FTP
by Roeland Meyer 27 May '01

27 May '01

> From: David Lesher [mailto:wb8foz@nrk.com] > Sent: Saturday, May 26, 2001 6:56 AM > A) A friend got bit badly by the "anything I can attach I will" > syndrome. He was in the UK, and the usual USG local POP (from PSI) > was FUBAR. > > So he called back to DC to get urgent mail. Some MITRE genius > had attacked a 10+meg PowerPointless file to his message to 100+ > folks, including Friend. Friend err (rather you & I) paid a VERY > large phone bill for that braindeadness. So, why were they dialing international when ATT WorldNet is closer/cheaper? Could it be because they'd have had to have opened the server for relaying, from ATT, in order to do that? The anti-openrelay crowd raised your friend's cost there by $4.90 per minute +VAT, by FORCING them to use international dialup instead. They could have also used ATT and punched a tunnel through to their host (still have to allow ATT dial port access). I was in the same position (London) last year and had my servers ORBS listed, even though they were only exposed for two weeks and they never saw spam being relayed. ORBS listing is cheaper than international phone charges, VAT or no VAT. Two things I always get before going to EU; a GSM rental cell phone and an ATT WorldNet account (I bring my own telco-hacker kit). For phone calls state-side I use Dialpad or Net2Phone. MHSC has been doing some work in NZ and we regularly connect via NetMeeting. My telco bills are consistently very low. > B) I'm intrigued by the proposal for pseudo attachments. > Hmm, what's really needed? > > 1) User still points & clicks. > 2) MUA uploads attachment to its designated server. > 3) MUA attaches URL & password to message. > 4) Recipient gets mail and grabs attachment. > 5) Server knows who has gotten file, keeps track. > 6) 24 hours after last recipient has claimed it, or {say} > 1 week later, it deletes it. Replaces with "it's expired, > have it resent" for whenever. (Gee, this sounds like news > and history files...) > All this needs to work is for say Eudora and Mutt to both offer it. > Once a critical mass of sysadms deploy same, and crank down the > limit to 100K, more will. (I say Eudora because M$ will resist > anything that interoperates....) Key ingredient ... critical mass of sysadms. It will NEVER happen as long as neither Domino or Exchange are doing it. This list proves that you can't get any two sysadms to agree on the color of the sky on a sunny day. Further proof is found on the ICANN lists. > -- > A host is a host from coast to coast.................wb8foz(a)nrk.com > & no one will talk to a host that's close........[v].(301) 56-LINUX > Unless the host (that isn't close).........................pob 1433 > is busy, hung or dead....................................20915-1433 I still love this sig-line <g>.

2 1