February 2004 - NANOG - lists.nanog.org

Re: Anti-spam System Idea
by W.D.McKinney 15 Feb '04

15 Feb '04

>-----Original Message----- >From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] >Sent: Sunday, February 15, 2004 01:21 AM >To: 'Tim Thorpe' >Cc: nanog(a)merit.edu >Subject: RE: Anti-spam System Idea > > >On Sat, 14 Feb 2004, Tim Thorpe wrote: > >> If these exist then why are we still having problems? > >Because the spammers are creating proxies faster than any of the anti-spam >people can find them. Evidence suggests, at least on the order of 10,000 >new spam proxies are created and used every day by spackers >(spammer/hackers). > >The relative insecurity of windows and ignorance of the average internet >user has created an incredibly target rich environment for the spackers. > >> Why do we let customers who have been infected flood the networks with >> traffic as they do? Should they not also be responsible for the security >> of their computers? Do we not do enough to educate? > >Economics, and convenience outweighing security. We're big, and slow to >change. They're small and mobile. > > The Barracuda Networks Firewall helped us and especially recently. Realize it's an edge solution, but seems about all we can do right. Some of the users still are using other accounts are getting spacked. Dee Alaska Wireless Systems

3 2

RE: Anti-spam System Idea
by Tim Thorpe 14 Feb '04

14 Feb '04

I am trying to find all of the rouge relays out there created by the more recent worms that have spread throughout the internet, and improve the speed at which it is done, instead of say a list that updates daily with SOME of the relay changes, this list would be rebuilt daily from the ground up and made available daily to be grabbed. For current personal SPAM control I use cloudmark's spamnet, I have yet to find anything better, but it does cost a couple bucks a month. > -----Original Message----- > From: Brian Sneddon [mailto:B.Sneddon@metrologic.com] > Sent: Saturday, February 14, 2004 12:45 AM > To: 'Tim Thorpe' > Subject: RE: Anti-spam System Idea > > Hi, Tim. > A couple of the RBL (real-time black hole listing, in case > you're not already familiar with them) providers already do > something like this. SORBS and NJABL stick out in my mind as > examples. Is there something about their method that you're > seeking to improve? > > Also as far as anti-spam software is concerned my personal

2 1

Wireless Pt-Pt in Orlando FL ?
by Ben Crosby 14 Feb '04

14 Feb '04

Hi all, If anyone knows of a company who can provide internet connectivity via fixed wireless in Orlando, please contact me off-list. I'm looking for DS3 or higher. I welcome any experiences anyone may have had with this type of service. Ben.

1 1

RE: SMTP relaying policies for Commercial ISP customers...?
by Dan Ellis 13 Feb '04

13 Feb '04

Andy, These are exactly my concerns, and exactly what I feel I'm going to hear from the staff and the customers. I am going to go back and make sure there isn't a "better" solution. Thanks for the input. The issue we have as a dynamic IP broadband provider is that it's a royal pain to shutdown a user - especially in regards to just mail. Lets say we have a spammer and a script detects it. We then have to track him back to the MAC address of the modem, lookup that MAC in the customer DB, shutdown his access and then reset the modem. And at the end, he loses all access, not just mail. With AUTH we can just stop mail access. Yeah, sure we could try to push some access list to the modem itself, blocking mail, but those modems are so flaky to start, it'll never work reliably. Can't just block the IP on the mail server because the user will or could just get a new IP, and then you are blocking a legit user. I'm still not sure if the norm is for providers to let t1+ customers relay. I have multiple OC3's and 12's from AT&T, MCI,... Will they let me relay off their servers without SMTPAUTH? Probably not. As always, comments welcome. -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay > -----Original Message----- > From: Andy Dills [mailto:andy@xecu.net] > Sent: Friday, February 13, 2004 12:35 PM > To: Dan Ellis > Cc: nanog(a)merit.edu > Subject: Re: SMTP relaying policies for Commercial ISP customers...? > > > On Fri, 13 Feb 2004, Dan Ellis wrote: > > > 1) Residential Policy: Enable SMTPAUTH and disallow relaying > > unless the customer has a valid username/password. If you're not paying > > for a mailbox, you don't get to relay outbound. This should not break > > anything except those residential accounts that *should* be commercial > > anyway. > > > > 2) Broadband commercial: This is the difficult one. These are the > > customers that aren't big enough to rightfully run their own mailserver, > > but they are big enough to have roaming users on their networks (coffee > > shops, branch offices, hotels, SOHO....). They expect relaying service > > for either their mailserver or for all their various PC's. At the same > > time, they don't have many, if any mailboxes through the ISP. My > > thought is that they should ONLY be allowed to relay via SMTPAUTH by > > using a residential mailbox login/pass OR they need to purchase a > > commercial relay service (expensive because of the openness of it) for > > their IP space. > > > > 3) T1+ : These customers should not be allowed to relay unless > > they purchase (expensive) relay services for their IP space. Of course, > > they can always use a residential mailbox, but will have to use SMTPAUTH > > for it and will be restrained by the same policies residential mailboxes > > have (low tolerance tarpitting,...). > > While the amount of effort you put into this so far is commendable, I > really think you're barking up the wrong tree. > > At the end of the day, what have you done, besides annoy your customers > and increase the load on your support staff? > > I don't really see what you're suggesting being anything other than a huge > effort, solving the wrong problem. > > For any responsible ISP, the problem is the spam coming into your > mailservers, not leaving. As long as you quickly castrate the people who > do relay spam through you, you're not going to have an egress spam > problem. > > Since you seem to have countless hours to invest in this problem, you'd be > better off writing a log parser to identify WHEN somebody is relaying spam > through you, so you can react. > > Something else I've seen implemented is rate limiting. Keep track of the > number of messages sent by an IP over a variable amount of time and > implement thresholds. > > > I'd love to hear some of the conversations you have with your leased line > customers, when you tell them they have to pay for "(expensive) relay > services" to send mail through your mail server. How many times will they > laugh before hanging up on you? :) > > That's like the IRS trying to charge you for the forms... > > And I'd also like to see the looks on your technical support staff's faces > when you tell them they need to assist your ENTIRE USER BASE in switching > to authenticated SMTP :) > > And then you have to deal with the customers who have MTAs that don't > support authenticated SMTP...and on and on. > > Whenever the solution is more expensive than the problem, you need to go > back to the drawing board. > > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > ---

8 8

SMTP relaying policies for Commercial ISP customers...?
by Dan Ellis 13 Feb '04

13 Feb '04

My apologies for another annoying SMTP thread. So, while considering enabling SMTPAUTH for all our customers, I'm planning on placing firm policy on relaying. We're a regional broadband ISP/MSO that also serves a significant number of educational and commercial cable/DSL connections as well as a large number of T1/T3/OC3/Ethernet customers. That leaves with me needing to define how we will handle 3 situations: 1) Residential (a few dynamic IP computers) 2) Broadband Commercial (Static IP and a few forwarded IP's, a dozen end user PC's) 3) Dedicated commercial customers (t1/ds3/Ethernet/oc3) HISTORY: Old school thought was that as long as you are on an ISP's IP space, you can use them to relay. This made it easy for roamers as everyone would use the ISP's mailserver for outbound, and their mailserver for inbound. Yes - there was always a fuzzy line for t1/ds3/oc3 customers because some ISP's allowed their space to relay and some did not. I'm trying to determine what the "new school" thoughts are. Below are my thoughts and concerns on each. I'm interested in hearing what others have implemented regarding policy, what the large NSP's have implemented, and what your thoughts are. 1) Residential Policy: Enable SMTPAUTH and disallow relaying unless the customer has a valid username/password. If you're not paying for a mailbox, you don't get to relay outbound. This should not break anything except those residential accounts that *should* be commercial anyway. 2) Broadband commercial: This is the difficult one. These are the customers that aren't big enough to rightfully run their own mailserver, but they are big enough to have roaming users on their networks (coffee shops, branch offices, hotels, SOHO....). They expect relaying service for either their mailserver or for all their various PC's. At the same time, they don't have many, if any mailboxes through the ISP. My thought is that they should ONLY be allowed to relay via SMTPAUTH by using a residential mailbox login/pass OR they need to purchase a commercial relay service (expensive because of the openness of it) for their IP space. 3) T1+ : These customers should not be allowed to relay unless they purchase (expensive) relay services for their IP space. Of course, they can always use a residential mailbox, but will have to use SMTPAUTH for it and will be restrained by the same policies residential mailboxes have (low tolerance tarpitting,...). As always, thanks in advance. --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293

4 3

Re: SMTP authentication for broadband providers
by Alex Bligh 13 Feb '04

13 Feb '04

--On 13 February 2004 08:47 -0500 Carl Hutzler <cdhutzler(a)aol.com> wrote: > Is this what is commonly referred to as STARTTLS? That would be good, but doesn't work when port 25 is blocked unless it's STARTTLS on submission. Alex

1 0

Nortel Optera 5200's
by Alex Rubenstein 13 Feb '04

13 Feb '04

I am looking for a folk or two who has operational experience on the above, and who can give me a couple pointers. Much appreciated. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

The Cidr Report
by cidr-report＠potaroo.net 13 Feb '04

13 Feb '04

This report has been generated at Fri Feb 13 21:47:46 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-02-04 130549 91173 07-02-04 130555 91204 08-02-04 130702 91246 09-02-04 130759 91319 10-02-04 130872 91396 11-02-04 130759 91492 12-02-04 131091 91537 13-02-04 131225 91526 AS Summary 16536 Number of ASes in routing system 6635 Number of ASes announcing only one prefix 1371 Largest number of prefixes announced by an AS AS7018 : ATT-INTERNET4 AT&T WorldNet Services 73517312 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Feb04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 131255 91501 39754 30.3% All ASes AS4323 685 203 482 70.4% TW-COMM Time Warner Communications, Inc. AS6197 732 298 434 59.3% AS6197 AS7018 1371 963 408 29.8% ATT-INTERNET4 AT&T WorldNet Services AS701 1343 951 392 29.2% ALTERNET-AS UUNET Technologies, Inc. AS7843 506 128 378 74.7% ADELPHIA-AS Adelphia Corp. AS27364 382 33 349 91.4% ACS-INTERNET Armstrong Cable Services AS6198 545 214 331 60.7% BATI-MIA BellSouth Network Solutions, Inc AS4134 652 329 323 49.5% CHINANET-BACKBONE No.31,Jin-rong Street AS22909 340 20 320 94.1% DNEO-OSP1 Comcast Cable Communications, Inc. AS22773 342 34 308 90.1% CCINET-2 Cox Communications Inc. Atlanta AS1239 950 665 285 30.0% SPRINTLINK Sprint AS4355 385 101 284 73.8% AS4355 AS9583 341 77 264 77.4% SATYAMNET-AS Satyam Infoway Ltd., AS17676 294 41 253 86.1% GIGAINFRA Softbank BB Corp. AS1221 902 650 252 27.9% ASN-TELSTRA Telstra Pty Ltd AS6347 330 83 247 74.8% DIAMOND SAVVIS Communications Corporation AS6140 357 127 230 64.4% IMPSAT-USA ImpSat AS25844 243 16 227 93.4% SKADDEN1 Skadden, Arps, Slate, Meagher & Flom LLP AS6478 260 38 222 85.4% ATT-INTERNET3 AT&T WorldNet Services AS209 723 511 212 29.3% ASN-QWEST Qwest AS14654 214 3 211 98.6% WAYPORT Wayport AS13083 216 8 208 96.3% AS13083 Mannesmann Datenverarbeitung Autonomes System AS11305 242 41 201 83.1% INTERLAND-NET1 Interland Incorporated AS2386 419 231 188 44.9% INS-AS AT&T Data Communications Services AS20115 612 424 188 30.7% CHARTER-NET-HKY-NC Charter Communications AS5668 345 158 187 54.2% AS-5668 CenturyTel Internet Holdings, Inc. AS4519 203 20 183 90.1% MAAS Maas Communications AS6327 207 29 178 86.0% SHAW Shaw Communications Inc. AS9929 203 31 172 84.7% CNCNET-CN China Netcom Corp. AS15270 210 39 171 81.4% AS-PAETEC-NET PaeTec.net -a division of PaeTecCommunications, Inc. Total 14554 6466 8088 55.6% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax Cable Ltd. 63.0.0.0/8 AS705 ALTERNET-AS UUNET Technologies, Inc. 64.62.126.0/23 AS25700 SWIFTDESK SWIFTDESK VENTURE 66.114.0.0/19 AS16526 BIRCH-TELECOM Birch Telecom, Inc. 66.114.28.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.29.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.30.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.31.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 69.8.128.0/17 AS7260 NORLIGHT Norlight Telecommunications 132.0.0.0/10 AS568 SUMNET-AS DISO-UNRRA 137.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 138.136.0.0/13 AS568 SUMNET-AS DISO-UNRRA 156.246.0.0/16 AS9317 ITISNET-AS Inha University 158.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.16.0/20 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.32.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.64.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.96.0/22 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.100.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.119.135.0/24 AS270 PSCNI-AS National Aeronautics and Space Administration 192.124.252.0/22 AS680 AS680 DFN-IP service G-WiN 192.135.50.0/24 AS7018 ATT-INTERNET4 AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 SUMNET-AS DISO-UNRRA 192.172.0.0/19 AS568 SUMNET-AS DISO-UNRRA 192.188.208.0/20 AS568 SUMNET-AS DISO-UNRRA 192.243.32.0/23 AS2044 PALIN-AS Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM Bell Atlantic, Inc. 198.97.72.0/21 AS568 SUMNET-AS DISO-UNRRA 198.97.80.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.88.0/24 AS89 NUSC-CSTLNET-AS Naval Underwater Systems Center 198.97.192.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.240.0/20 AS568 SUMNET-AS DISO-UNRRA 198.101.4.0/22 AS568 SUMNET-AS DISO-UNRRA 198.136.32.0/20 AS19329 MCNET Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET CityNet, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM GT Group Telecom Services Corp. 198.161.165.0/24 AS852 ASN852 Telus Advanced Communications 198.163.155.0/24 AS684 MBNET-AS Manitoba Regional Network 198.167.0.0/16 AS7456 INTERHOP Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ALLST-15290 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASKTEL SaskTel 198.232.133.0/24 AS23075 SKOTOS-AS Skotos Tech, Inc 199.10.0.0/16 AS568 SUMNET-AS DISO-UNRRA 199.60.0.0/20 AS271 BCNET-AS University of British Columbia 199.84.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 199.114.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.114.0.0/21 AS568 SUMNET-AS DISO-UNRRA 199.114.128.0/18 AS568 SUMNET-AS DISO-UNRRA 199.114.130.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.132.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.136.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.138.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 DISA/UNRRA 199.114.142.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.144.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.148.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.150.0/24 AS721 DLA-ASNBLOCK-AS DoD Network Information Center 199.114.152.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.154.0/24 AS1733 CENTAF-SWA AF DDN PMO 199.114.156.0/24 AS1913 DLA4 Defense Logistics Agency 199.114.160.0/24 AS1733 CENTAF-SWA AF DDN PMO 199.120.32.0/19 AS16582 NEXTLEVELINTERNET NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 SUMNET-AS DISO-UNRRA 199.123.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.123.16.0/20 AS568 SUMNET-AS DISO-UNRRA 199.123.80.0/21 AS568 SUMNET-AS DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST-AS IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HPT-ASN Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 loxley-th Loxley Information Co., Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.143.56.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.248.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 203.32.4.0/23 AS7617 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.86.2.0/23 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.111.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 204.69.144.0/22 AS5668 AS-5668 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBIT Exobit Networks Inc. 205.150.0.0/15 AS701 ALTERNET-AS UUNET Technologies, Inc. 206.41.32.0/19 AS14824 NEWSOUTH NewSouth Communications Corp. 206.81.187.0/24 AS19194 JOVITA Sentris Network LLC 206.108.34.0/24 AS852 ASN852 Telus Advanced Communications 206.108.35.0/24 AS852 ASN852 Telus Advanced Communications 206.167.57.0/24 AS376 RISQ-AS Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ALLST-15290 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 AS11194 208.81.187.0/24 AS19194 JOVITA Sentris Network LLC 209.169.219.0/24 AS189 GENUITY-AS189 Genuity 209.169.223.0/24 AS189 GENUITY-AS189 Genuity 209.213.32.0/19 AS10629 INTERPAC Inter-Pacific Network Services 209.213.50.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.51.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.55.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.56.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL Telesat International Ltd. 209.240.96.0/19 AS10815 KCNET KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM SISCOM, Inc 209.251.64.0/19 AS10266 NETWAY-AS MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS IMBRIS, INC. 216.36.46.0/24 AS7176 GENUITY-AS7176 Genuity 216.36.47.0/24 AS7176 GENUITY-AS7176 Genuity 216.96.128.0/18 AS7018 ATT-INTERNET4 AT&T WorldNet Services Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: SMTP authentication for broadband providers
by Miquel van Smoorenburg 13 Feb '04

13 Feb '04

In article <cistron.20040212023825.GA77062(a)metron.com>, Lou Katz <lou(a)metron.com> wrote: > >On Wed, Feb 11, 2004 at 03:13:30PM -0500, Sean Donelan wrote: >> >> On Wed, 11 Feb 2004 Valdis.Kletnieks(a)vt.edu wrote: >> > On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said: >> > > what about port 25 blocking that is now done by many access providers? >> > > this makes it impossible for mobile users, coming from those providers, >> > > to access your server and do the auth. >> > >> > Port 587. >> > >> >> So is it time for ISPs to start blocking port 587 too? >> >> If the complaints are going back to the IP address anwyay, why shouldn't >> an ISP force it subscribers to go through the ISPs mail servers so it can >> control any messages sent by its subscribers? > > >Because, maybe, I don't think it is a good idea for someone else to CONTROL >any messages I might send. Who will control the controllers? As if they don't yet CONTROL the messages you receive ? Where, exactly, is your POP3/IMAP mailbox located ? Ah, you run your own mailserver for your own domain. So, you can use the submission port on your own mailserver, right ? Mike.

4 4

Re: SMTP authentication for broadband providers -- A MODEST PROPOSAL
by Dr. Jeffrey Race 13 Feb '04

13 Feb '04

On Thu, 12 Feb 2004 22:58:18 -0800, Dave Crocker wrote: > To attack spam, we need to attack it at its core, not at some secondary or > tertiary side-effect, with a mechanism that also hurt legitimate users. > So, what, exactly, _is_ that core? > Unless and until there is broad community consensus that answers that > question in concrete and practical terms, then all our efforts are > losing and stop-gap. A concrete and practical solution, which has been proven to work in hours, engineered from well-known principles of human behavior: <http://www.camblab.com/misc/univ_std.txt> derived from <http://www.camblab.com/nugget/spam_03.pdf>. Suggestions welcome. When I get some time (maybe in April) I may get to put this into the RFC-draft hopper. Needs a day of reformatting I've not gotten to yet. Anyone who has done this and could volunteer to help, contact me offlist. Kind regards to all, Jeffrey Race, today in Bangkok Thailand ---------------------------------------- USA tieline (rings at Bangkok residence) TIME ZONE GMT +7 -------------+1 617 395-4111------------ Tel +66 2 291-2235 Fax +66 2 688-4540 Tel +66 6 709-7645 (mobile -- 24 hours) Tel +66 6 563-5682 (mobile -- odd times) ADVENTURES IN THAI JUSTICE Cautionary real-life case studies for potential investors or visitors <http://pws.prserv.net/studies/>

1 0