December 2003 - NANOG - lists.nanog.org

Re: AOL rejecting mail from IP's w/o reverse DNS ?
by Michael.Dillon＠radianz.com 03 Dec '03

03 Dec '03

>What about speaking plain old smtp, but with transport / mailertable >rules routing all mail for domain X (say AOL or MSN) to "special >access" servers that have firewall ACLs allowing only connections from a >restricted set of IPs? If it's behind a firewall, then it's not on the Internet. Since NIMTP is a proposal for improving Internet email, then I think a new port number is in order. However, anyone is free to implement NIMTP peering by using a firewall to redirect new-port-number traffic to port 25 on some existing mail servers if that suits their purposes. NIMTP is lightweight technically, i.e. no new code needed, just reconfigure things a bit. The real solution resides in the agreements and the AUP that they will enforce and that has to be hashed out by the people who run mail services at the large ISPs. Not by the BGP peering folks and not by the IETF and not by the anti-spammer brigade. --Michael Dillon

1 0

RE: AOL rejecting mail from IP's w/o reverse DNS ?
by Jeffrey Paul 03 Dec '03

03 Dec '03

Perhaps I'm being naïve, but this seems like a very good way to cause spammers to suddenly start having valid PTR RRs. Thoughts? -j -- Jeffrey Paul - jeffreypaul(a)diamondcard.com - (877) 748-3467 Senior Network Administrator, Diamond Financial Products

3 2

Re: AOL rejecting mail from IP's w/o reverse DNS ?
by Greg Maxwell 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003 Michael.Dillon(a)radianz.com wrote: [snip] > Peering relationships work for BGP (lots of rules) and they worked > for USENET (not many rules). Why can't the same principles be applied > to email or IM services? Where is NickC when you need him... this sounds like something out of his layer4 nap idea... Seriously, do we really need SMTP peering agreements? I don't know of too many places that are UUCPing their email... SMTP traffic already crosses (BGP) peering agreement controlled links. If putting contractional obligations there fails to work why should we believe some new and less understood system would be any more effective?

2 1

Re: AOL rejecting mail from IP's w/o reverse DNS ?
by Michael.Dillon＠radianz.com 03 Dec '03

03 Dec '03

>The system exactly like you describe already exists. It´s based on the >standard >X.400 protocol and is available across the world. Wrong. X.400 is immensely more complex than a federation of ISPs using SMTP on another port number. >Or in some parts, used to >be. If that approach would be highly successful, why would it not prosper >instead of SMTP today? X.400 didn't work for a variety of reasons such as incomprehensible email addresses, too much complexity, the need to run X.500 directory services, the high cost of registering an X.500 organization identifier and the lack of open-source software. Internet mail systems have borrowed good bits from X.400 in the past such as the lighweight variant of X.500 known as LDAP. But peering agreements are not something that was invented by the X.400 committee. Lots of people now realize that there needs to be some system for incoporating "trust" into the Internet mail system so that mail servers can make decisions on whether or not to trust incoming messages. I think that X.400 is the wrong way to go when we can solve the problem more simply by shifting large amounts of SMTP traffic onto another port number based on one-to-one peering agreements between the organizations using that port number. Example. Lets say that AOL, Verizon and MSN agree to try this approach. On day one, they would only reroute email originating with their customers to the NIMTP port. On day 2 they would start to certify some of the ISPs who send large amounts of email to AOL, Verizon or MSN. Those ISPs would only divert email from their own customers to NIMTP. Then on day 3, these smaller ISPs would begin to certify some of their peers and smaller local ISPs for NIMTP. On day 3 these smaller ISPs will divert AOL-destined email to the NIMTP relay of the day 2 ISPs who will then pass it on to AOL, Verizon or MSN. If SPAM shows up somewhere, AOL knows who to call because they exchanged that info as part of the peering agreement. The Day 2 ISP fixes the problem by cutting off the NIMTP peering with the culprit and then getting them to cut off the spammers. This can all happen within a couple of hours of a spam email appearing. Ideally, this mesh of NIMTP peers will only have 4 or 5 relay hops between the smallest mail servers and the biggest ones. In today's world that means it might take 5 times as long to deliver a message, i.e. it will take five minutes rather than one minute. The NIMTP peers will no doubt hone the system to include various forms of automated checks and notifications but that's not important on day 1. The important thing is to set down the ground rules for NIMTP peering and that can only be done by human beings working for some of the larger users of email. --Michael Dillon

1 0

DS-3 test equipment
by Rick Ernst 03 Dec '03

03 Dec '03

I've searched the archives and find some hits on DS-1 test gear, but I'm looking for opinions/experience with DS-3 test gear. We've started bringing up more DS-3 circuits, both directly to customers and also for Frame/ATM/DSL aggregation. Telco used to do all provisioning and testing for us, but we are looking to be able to more troubleshooting in-house. Any recommended gear for basic functional testing (clock, loop, insert patterns and errors)? It would be nice if the test gear could do T-1 testing, too. I'm seeing a fair number of hits on eBay for TTC/Acterna gear, but I don't know what I'm looking at/for. I've done BERT testing many lifetimes ago, but don't have any current knowledge/experience. Thanks, Rick

1 1

2MB transatlantic feed enquiry
by paul＠oninit.com 03 Dec '03

03 Dec '03

I'm looking for a company whom can deliver a 2mb SDH, MPLS VPN, ATM or 10mb EoMPLS connection between Oregon/Salem and Telehouse North, London Please contact me off list. -- Paul Watson # Oninit Ltd # Growing old is mandatory Tel: +44 1436 672201 # Growing up is optional Fax: +44 1436 678693 # Mob: +44 7818 003457 # www.oninit.com #

1 0

NETCONF checkpoint
by Eliot Lear 03 Dec '03

03 Dec '03

[replies to either the netconf list if you are a member or to me, and I will forward them *directly* to the netconf list unless instructed NOT to do so.] Dear NANOG folk, The NETCONF working group of the IETF is currently developing a collection of protocol specifications for the configuration of network elements. This work originated from a roadshow that many of us went on to learn what operators of different types want in such a protocol. Now we would like to checkpoint with you on some of the contents of those specifications. What follows a highlight of two issues I believe are important to NANOG. There are, however, many unresolved issues with NETCONF, some more important than others, that have been posted by the chair today to the netconf mailing list. They can be viewed by going to http://ops.ietf.org/lists/netconf/netconf.2003. The working group solicits your opinion on as many of these issues as you care to comment on. The protocol itself is split into two parts: an abstract set of functions, and a binding to specific protocols, including SSH, BEEP, and SOAP over HTTP(s). Each protocol has its pluses and minuses. As envisioned, the base protocol supports an option for notifications. The idea is that a manager would be notified of configuration-related events, such as a card insertion or removal, and act appropriately to configure the element. The envisioned format of notifications is either reliable syslog from RFC 3195 or something similar. Because notifications are asynchronous, one writes code that implements a dispatch mechanism that discriminates on the type of event. Notifications would be an option that not all managers would have to implement. Our first question is whether or not you are interested in receiving such notifications? Related, do you use such a mechanism today? The working group is attempting to determine whether notifications should remain as part of the base specification. Here are the choices facing the group: Option A. Leave them in as currently specified, and require all protocol mappings to support them. Option B. Allow them to be asynchronous, but don't use RFC 3195, and require all mappings to support them. Option C. Remove them entirely from the specification and let vendors implement RFC 3195 or other notification mechanisms as they see fit (for instance, existing syslog). Do you have an opinion on which of these options you would like? Related, the NETCONF base protocol currently makes use of the notion of channels. Channels are a basic concept in the BEEP protocol, and they exist in SSH as well. However, use of multiple channels in SSH is not supported in common SSH applications. They are completely absent in HTTP, and so the notion of a session would have to be introduced in the mapping. Channels are a means of maintaining multiple communication streams within a single session. In NETCONF, there are three types of streams: management, operations, and notifications. Channels allow these different message types to be multiplexed within the same session without the need to interleave the messages in a way that preserves their integrity (e.g. valid XML instance documents). NETCONF utilizes channels to separate asynchronous messages (notifications or RPC progress reports) from normal operations, as well as separate high priority operations (RPC abort) from normal operations. The working group has three choices: Option A. Keep channels in the base document and require each mapping to support them. Option B. Make channels optional. Option C. Remove channels from the base protocol and allow their use in the protocol bindings. Which option do you prefer? Again, these are important protocol issues that will affect your ability to build tools. There are others. If you would like to read the entire set of documents, you will find them by going to the NETCONF working group charter page: http://www.ietf.org/html.charters/netconf-charter.html. If there is sufficient interest we will seek another BOF at Miami. Thanks for your help, Eliot

1 0

OT: Level 3 Secrets to Contact? Very OT! Please Ignore!
by Brennan_Murphy＠NAI.com 03 Dec '03

03 Dec '03

Does anyone know the secret to contacting a dark fiber salesperson at Level 3? The website directs a prospect to their toll free number 1-877-2LEVEL3 but the voicemail decision tree has some very dead limbs. It's not always easy to convey one's frustration in email. But the mugshot in this story seems to capture my general disposition: http://www.denverpost.com/Stories/0,1413,36~33~1765189,00.html# Just hoping to get some quick answers to easy questions so I'll be on my way to feeling like this: http://www.columbia.edu/cu/record/record2011.19c.gif ...but if the wait goes on much longer, I'll be left in this state: http://images.usatoday.com/money/_photos/2001-04-16-buffett.jpg Thanks, BM PS hope the employee-owners over there have a sense of humor....their contact apparatus is costing them money...is my guess. PPS You'd be surprised how many images there are of Warren Buffet on the web. And come to think of it, why should that rich (*&%$#$ ever have a grumpy look on his face?! The man should be walking around with a smile that makes his ears itch.

1 0

AOL postmaster (new request)
by Derrick Bennett 03 Dec '03

03 Dec '03

I really hate doing this but after 5 days and no one at AOL's helpdesk can even tell me why our subnets are being blocked. Can someone with the Postmaster helpdesk level 2 or higher please contact me. I have a ticket, I have followed all the rules, and I am still being told that no one knows why the block is there and no one knows when I will get a phone call or an email. Yes I accept mail for postmaster and root @ServerIP. No there is nothing in either mailbox. I am not listed on any other blacklists so I am really quite confused as to why this is so difficult. Thanks, Derrick <End of List Noise>

2 1

RE: WLAN shielding
by Erik Amundson 03 Dec '03

03 Dec '03

I have been looking into the Cisco Aironet solution recently for a project I'm working on. They seem to have some great security features, if you want to take the time to configure it. Oh, another caveat is that you have to use Cisco's wireless adapter as well, otherwise, good ol' WEP for you! I haven't thought of the VPN idea that others have spoken of on the NANOG list yet...that's a good idea too...hmm.... - Erik -----Original Message----- From: Andy Grosser [mailto:andy@sugar.meniscus.org] Sent: Wednesday, November 26, 2003 11:02 AM To: nanog(a)merit.edu Subject: WLAN shielding Apologies in advance if this may not quite be the proper list for such a question... My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? Feel free to reply off-list. Thanks! Andy --- Andy Grosser, CCNP andy at meniscus dot org ---

2 1