- NANOG - lists.nanog.org

RE: Road Runner refusing us, others?
by Michel Py 04 Feb '04

04 Feb '04

Looks like your IP 24.92.226.159 is listed at block.blars.org http://www.blars.org/errors/block.html -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Jeftovic Sent: Wednesday, February 04, 2004 6:49 AM To: nanog(a)merit.edu Subject: Road Runner refusing us, others? Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0

Re: Road Runner refusing us, others?
by Brent_OKeeffe＠asc.aon.com 04 Feb '04

04 Feb '04

I just sent an email from a Yahoo account to me roadrunner account. Worked fine. Brent Mark Jeftovic <markjr(a)easydns.com> Sent by: owner-nanog(a)merit.edu 02/04/2004 09:48 AM To: nanog(a)merit.edu cc: Subject: Road Runner refusing us, others? Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0

Road Runner refusing us, others?
by Mark Jeftovic 04 Feb '04

04 Feb '04

Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0

Re: Poor connectivity to new b.root-servers.net address?
by sthaug＠nethelp.no 04 Feb '04

04 Feb '04

> the problem seems to be in the level3/cenic/losnettos path. > > juniper -ge- gsr -ge- foundary -ge- foundary -ge- foundary -100m- 7513 > > the IP path is: > > juniper - 7513 > > more as we unearth the problems... What I didn't mention in my original post is that this problem has existed, as far as I can see, since B was moved to a new address. Anyway - it seems things are fixed now. DNS lookup, traceroute and ping work from AS 2116 (source address 193.71.2.2) and AS 3307 (source address 194.19.15.2). There are still timeouts at the router hop before 130.152.181.66, which looks like it should be 67.30.130.66, traceroute'ing from 193.71.2.2 and 194.19.15.2: 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 188.092 ms so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 188.118 ms 187.955 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.112 ms 177.141 ms 177.202 ms and 13 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 188.861 ms 188.604 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 188.947 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 187.970 ms 187.573 ms 187.399 ms The missing hop here is visible as 67.30.130.66 coming from 129.241.1.16 (AS 224). I'm not going to worry too much about the traceroute timeouts, even if it would be nice if that could also be fixed. The main point is that DNS lookups are now working as they should. Thanks! Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

antivirus in smtp, good or bad?
by Stephen J. Wilcox 04 Feb '04

04 Feb '04

Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit... Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivirus service on that other account. So we get the mail, spool it and try to forward it but then we get a "550 Error: Suspected W32/MyDoom@MM virus" after DATA and our server freezes the mail. Surely this is an incorrect way to do this as there will be lots of similar MXs like ours backing this mail up? They should accept the mail and then bounce it? Thoughts? Steve

4 5

Re: Unbelievable Spam.
by Michael.Dillon＠radianz.com 04 Feb '04

04 Feb '04

>> Spam Hosting - from 20$ per mounth. >> Fraud Hosting - from 30$ per mounth. >> Stoln Credit Cards, Fake ID, DL's. >This is known as "Rule #3" on n.a.n-a.e... Spammers are stupid. Stupid!? These spammers are not stupid. There are very few legitimate businesses which can actually turn a profit from spamming. Most of the money to be made is in selling spam related software and services to suckers. The problem is, how do you identify people who are dumb enough to think that spam services are worth paying for? Simple. You send lots of spam which, by definition, only goes to people who know something about the Internet and might be willing to spend money on an Internet-related service. Then you wait for responses which, by definition, are only going to come from grade A suckers. Then you pounce on these hapless marks, rip them off and move on. Spammers are not stupid. They are smart criminal gangs which have not only managed to keep their schemes running for several years in the face of great public animosity, they have also managed to sabotage the efforts that supposedly work against them. A favorite trick is for them to go into a forum like NANAE and support a flawed anti-spam effort because they know that it keeps people from focusing on real solutions. The net effect of all of these flawed technical attacks on spam is that it has filtered out the naive spammers from the spamming community and left spamming in the control of criminal gangs. When will we realize that SPAM is a social problem and it needs a social solution? When will the major email providers sit down around a table and agree to some guidelines for email exchange that make it impossible for rogue users to inject large volumes of email into the system? The existing non-hierarchical email exchange network is not scalable. I hope that everyone on this list can understand what the email exchange overlay network is and recognize that it is subject to similar scaling rules as the underlying IP network. --Michael Dillon

7 6

Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

We're starting to take complaints from folks who have installed the latest IE patch about various broken website functionality. The complaints are not related to folks trying to use the username:password@ functionality that was removed by the patch. Is anyone taking similar calls / seeing similar issues? Herman Harless Director, Advanced Data Network Engineering and Operations NTELOS, Inc. herman(a)ntelos.net

9 8

RE: Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

Sorry - Mostly non-password encoded forms that don't refresh when you hit submit. After Submitting 3 or 4 times they seem to work. Like most ISP's, we take calls when somebody's web site doesn't work, even if we don't even host it. On Tue, 2004-02-03 at 12:24, Conrad Golightly wrote: > Can you give us some more detail about what they ARE seeing? > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Herman Harless > Sent: Tuesday, February 03, 2004 11:27 AM > To: nanog > Subject: Latest IE patch breaking non username:password@encoded > websites? > > > > We're starting to take complaints from folks who have installed the > latest IE patch about various broken website functionality. The > complaints are not related to folks trying to use the username:password@ > functionality that was removed by the patch. > > Is anyone taking similar calls / seeing similar issues? > > Herman Harless > Director, Advanced Data Network Engineering and Operations NTELOS, Inc. > herman(a)ntelos.net > > > > > --- > [This E-mail scanned for viruses] > > >

2 1

Re: Poor connectivity to new b.root-servers.net address?
by Simon Waters 03 Feb '04

03 Feb '04

NANOG Digest wrote: > > 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms > 14 * * * > 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms > 16 * * * I see something similar to this coming out of Level3 from Demon's direction. The was mentioned in comp.protocols.dns.bind, where some additional traceroutes and information is available, although it is clearly(?) a routing issue and I suggested here was a good place to ask for help. Still we have enough root servers to be going on with while it is fixed, lets just hope no one hijacked it.

5 7

Re: Strange public traceroutes return private RFC1918 addresses
by Kevin Oberman 03 Feb '04

03 Feb '04

> From: "Terry Baranski" <tbaranski(a)mail.com> > Date: Tue, 3 Feb 2004 16:42:55 -0600 > Sender: owner-nanog(a)merit.edu > > > Leo Bicknell wrote: > > > Since most POS is 4470, adding a jumbo frame GigE edge makes > > this application work much more efficiently, even if it doesn't > > enable jumbo (9k) frames end to end. The interesting thing > > here is it means there absolutely is a PMTU issue, a 9K edge > > with a 4470 core. > > This brings up the question of what other MTUs are common on the > Internet, as well as which ones are simply defaults (i.e., could easily > be increased) and which ones are the result of device/protocol > limitations. > > And why 4470 for POS? Did everyone borrow a vendor's FDDI-like default > or is there a technical reason? PPP seems able to use 64k packets (as > can the frame-based version of GFP, incidentally, POS's likely > replacement). 4470 was, as you surmised, to allow a full sized FDDI packet to be packed into a single POS packet. At the time FDDI was using larger packets than anything else. Now the recommendation for research and education networks (Abilene, ESnet, NASA, and many Asian and European R&Es) is 9000 and, within that community, is almost universally adopted when the hardware will support it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 0