- NANOG - lists.nanog.org

s.o. out there from Finland's ISPs
by frank＠try-us.de 02 Dec '03

02 Dec '03

Hello list, Need a contact to an isp in Finland / Scandinavia. Please contact me off list. -- Best regards, Frank Kuempel mailto:frank@try-us.de If it's there and you can see it - it's REAL If it's there and you can't see it - it's TRANSPARENT If it's not there and you can see it - it's VIRTUAL If it's not there and you can't see it - it's GONE

1 1

RR Abuse contact
by sowens＠epik.net 02 Dec '03

02 Dec '03

Could someone from Road Runner's abuse department contact 407-482-8487 or ghadlock<at>epik(dot>net please. Shane

1 0

Re: incorrect spam setups cause spool messes on forwarders
by Suresh Ramasubramanian 02 Dec '03

02 Dec '03

Michael.Dillon(a)radianz.com wrote: > Why on earth would Verizon need to do the lookup once per > incoming email? If they need to verify that a given MX > does indeed exist and is reachable and is running an > SMTP server, then why not cache that info for some Er.. they are not looking for "MX exists". If MX and A didn't exist or were bogus (pointing at rfc1918 space or the loopback IP for instance) the mail could be rejected without going through all this song and dance about SMTP callbacks. Consider a domain like (say) email.com <- that's one of ours, btw, that is extensively forged into spam. What they are trying to do is to connect back to email.com's MXs and ensure that the user <sgswretyshsdhtest(a)email.com> who is trying to send them mail really does exist, and is not just a figment of some spambot's imagination. It does tend to cut down on the amount of spam, but fails in several ways which have been discussed upthread (the most common being: the MX has an smtpd listener with no view of the userdb, like a cisco pix appliance with "smtp fixup", or a qmail smtpd instance). It is also a major headache for the operators of other mailserver clusters, especially the operators who host domains that are extensively forged into spam. SMTP verification callbacks are a major nuisance, over and above the usual flood of forged spam. And it can set off all kinds of alarms when a NOC tech finds the same address (say imail(a)verizon.net) sending out thousands of emails to a whole lot of unknown addresses on your system. Said tech went ahead and blocked that address. By the time I could investigate, Verizon was rejecting a bunch of valid mail as well ... their sender verify process was failing because our NOC tech had blocked the address they used for verification. [Beats me why they don't use something like verify(a)security.verizon.net] > reasonable time period, say an hour, to avoid disrupting > everyone else's Internet. Coupled with that caching, they They could cache information about that particular envelope sender, sure. But spammers send with extensively randomized and bogus addresses in the same spam run, so even that caching doesn't really help. > And if they are going to do something like this which > imposes a requirement on other ISPs, i.e. your MX > must point to a live SMTP server, and which impacts That it must. No argument about that. > other ISP's mail operations, i.e. we will send you An ISP whose domain's MX points to a dead or nonexistent server would notice a severe impact on their mail operations, I assure you. > 450s, then why can't they *PUBLISH* what they are > doing. NANOG seems an appropriate place for this. Glad somebody realizes this. NANOG, according to the list FAQ, is not really the place to discuss spam, particularly as spam is not an operational problem. The reason that I disagree with this line of reasoning is that spam is just as much of an operational problem as some other topics that are considered fit for discussion here (or at any rate, are regularly discussed here). Especially as most if not all spam these days has a network security angle to it (trojans, compromised machines, hijacked /16s ...) Of course, most other operators meetings have whole conference tracks and tutorials on spam... in fact nanog seems to have had at least one or two of them in the past (with Paul Vixie speaking about spam). Yes, lists like spam-l and spamtools exist (and so do several other lists, some of them semi-secret and by invitation only, even). But * Quite a few nanog people don't read those * Quite a few issues are often better discussed in the focused and clued atmosphere of nanog than in the tower of babel (aka news.admin.net-abuse.email) --srs -- srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

4 7

WLAN shielding results
by Andy Grosser 02 Dec '03

02 Dec '03

Thanks to all who responded to my query. I suppose I should have added that the brass in my company are somewhat loathe to work a little harder at things like using SecurID tokens, firing up VPN software, etc. "I want a single login solution" is a common mantra on the top floor. OK, OK, we're working on it... <exasperated sigh> The majority of the respondents suggested software solutions - VPN tunneling, strong crypto, not broadcasting SSIDs, etc. I've been somewhat successful in relating to the higher-ups that they can either have security or convenience, and the mileage and pricing will vary. Our VPN boxes seldom hit 10% CPU utilization, even with 2000 users, so why not still use them? Thanks again, and my apologies for decreasing the S/N ratio. Andy

1 0

APRICOT 2004 : Speakers for Peering and Internet Exchange Track
by William B. Norton 02 Dec '03

02 Dec '03

Hi all - You may have heard that there will be a new one-day track on Peering and Internet Exchanges at the upcoming APRICOT in Kuala Lumpur in February. I'd like to describe the track in brief and solicit a few more Peering Coordinators / Network Architects / Network Engineers as speakers for the track. (See http://www.apricot2004.net/ for information on the broader APRICOT 2004 conference). This Peering and Internet Exchange Track is intended to facilitate regional ISP Peering by providing a forum for Peering Coordinators to meet each other and share information about Asia Pacific peering. We will facilitate this with several panels, each one focused on peering in a particular country. If you are a Peering Coordinator with experience peering in the AP Region, please send me an e-mail answering the questions below. I will use this information to match panelists together into panels focused on certain AP countries. Thanks! Bill --------------------------- Speaker Questionnaire ------------------------------------ If you are able and willing to speak at the Feb 2004 APRICOT Peering and Internet Exchange Track, please fill out the following form and e-mail to William B. Norton at wbn(a)umich.edu: Name: __________________ Title: ___________________ Company: _______________ AS # _________________ In what country do you live? _________________ Email Address: __________________ We will select a set of panelists based on the answers to the questions below: 1) In what countries do you peer? 2) In which AP Country do you have peering experiences that you can share with the audience? 3) Answer as many of the questions below as applicable, as you would present as part of your presentation a) We are looking for speakers that have found interesting or unique country peering ecosystem characteristics. Have you uncovered any unexpected or interesting/unique peering ecosystem characteristics in any of the countries where you peer? Please give a few examples. b) We are also looking for unusual or unexpected traffic patterns. For example, a large amount of Japan traffic is ultimately destined to and from Brazil! Identifying and explaining this type of inter-country traffic would be a good set of data to launch a presentation. Do you have any of this type of data that you can share? c) What are the problems and challenges that you face as you build peering infrastructure into various AP countries? d) If other Peering Coordinators follow your footsteps into regions in which you now peer, what would you tell them: · is information that you would have liked to have had? · Are unexpected problems that you faced? e) What are the emerging trends that you see in the peering ecosystems in which you operate (transit and transport prices going up or down and the implications as you see them). /* William B. Norton <wbn(a)equinix.com> 650.315.8635 Co-Founder and Chief Technical Liaison Equinix, Inc. */

1 0

incorrect spam setups cause spool messes on forwarders
by Randy Bush 02 Dec '03

02 Dec '03

is the following a general problem, or just one i am seeing? note 2821 says 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) randy From: Randy Bush <randy(a)psg.com> To: foo(a)psg.com Subject: broken mail server Date: Mon, 1 Dec 2003 10:02:34 -0800 you have a .forward on psg.com pointing to foo.user(a)verizon.net. like all mail accounts these days, you get spam. but the forward, as opposed to rejecting it with a 5xx is deferring with a 450 (see below), which is not proper. this means that the spam stays in the queue here, which is just not reasonable. please do one of the following: o see that the verison server is fixed (good luck), o set your forward to a properly working server, or o tell me so i can kill your mail account here. randy 2003-12-01 10:09:05 1APbBa-000Ork-DY == foo.user(a)verizon.net <foo(a)psg.com> R=lookuphost T=remote_smtp defer (0): SMTP error from remote mailer after MAIL FROM:<nikkiadamczyk(a)gerbangmail.com> SIZE=5365: host relay.verizon.net [206.46.170.12]: 450 Requested mail action not taken-Try later:sc004pub.verizon.net

13 24

objective performance tests - broadwing, cogent
by matthew zeier 02 Dec '03

02 Dec '03

Does anyone have some objective performance tests of Cogent and Broadwing? Or any insight into eithers peering and peer relationships or ideas of how they route traffic? Thanks. -- matthew zeier - "Curiosity is a willing, a proud, an eager confession of ignorance." - Leonard Rubenstein

1 0

APNIC delegation change
by Eric Germann 02 Dec '03

02 Dec '03

Just a heads up for those who use http://ftp.apnic.net/stats/apnic/apnic-latest .... It moved. If you have scripts that slurp APNIC ASN or IPv4 allocations, they probably broke this morning. The new correct link is at http://ftp.apnic.net/stats/apnic/new/delegated-apnic-latest ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 603 825 5893 "The fact that there are actually ways of knowing and characterizing the extent of one’s ignorance, while still remaining ignorant, may ultimately be more interesting and useful to people than Yarkovsky" -- Jon Giorgini of NASA’s Jet Propulsion Laboratory

2 1

Re: incorrect spam setups cause spool messes on forwarders
by Suresh Ramasubramanian 02 Dec '03

02 Dec '03

" John Brown (CV)" <jmbrown(a)chagresventures.com> wrote: > telling spammers 4xx or 5xx doesn't matter, they don't listen. The goal is to keep your spool clear, and your mailservers operational. At least, that is, if you are running a production server and not a hobbyist / family and friends type setup. -- srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

1 0

Re: incorrect spam setups cause spool messes on forwarders
by Michael.Dillon＠radianz.com 02 Dec '03

02 Dec '03

>Also imagine your domain being joe-jobbed. You, as an innocent bystander, >then get hammered by Verizon as they try to do a lookup on possibly >millions of incoming mails. Why on earth would Verizon need to do the lookup once per incoming email? If they need to verify that a given MX does indeed exist and is reachable and is running an SMTP server, then why not cache that info for some reasonable time period, say an hour, to avoid disrupting everyone else's Internet. Coupled with that caching, they could reasonably make a few tries over the space of 3 to 5 minutes before giving up on the incoming email by sending 450s. And if they are going to do something like this which imposes a requirement on other ISPs, i.e. your MX must point to a live SMTP server, and which impacts other ISP's mail operations, i.e. we will send you 450s, then why can't they *PUBLISH* what they are doing. NANOG seems an appropriate place for this. --Michael Dillon

1 0