Wireless Pt-Pt in Washington DC ?
Thanks to all who replied to my original request for Orlando. I'm looking for the same info now for Washington DC. I need to organise temporary Internet connectivity via fixed wireless at DS3 or higher rates. Preferably microwave link, and I can provide necessary equipment for the duration of the link (about one month) if need be. For those who made LOS queries, my end of the link would be Connecticut Avenue NW, 20009, about 11 stories up. It would be extremely advantageous if the far end can give me native IPv6 connectivity also. As last time I welcome both positive and negative experience with these kind of ventures and local companies. Many thanks ! Ben.
Re: SMTP relaying policies for Commercial ISP customers...?
On Fri, 13 Feb 2004 at 5:14pm [EMAIL PROTECTED] wrote: > > What about http://www.nanog.org/mtg-0402/gauthier.html > > After seeing that presentation, I wondered if an ISP could get > away with something similar. Eric has the advantage of being > the monopoly service provider for the dorms. I know of at least one ISP that does similar, Onramp.net in Austin TX. I'm a corporate IT Mgr and one of my remote users is an Onramp customer that had ancient NAV on his personal PeeCee and caught whatever worm was in vogue a few months back. He is not a particularly computer savvy person, but he is not a luser either. He was quite pleasantly surprised at the service, once he realized what was going on. -- Joseph F. Noonan Rigaku/MSC Inc. [EMAIL PROTECTED]
RE: SMTP relaying policies for Commercial ISP customers...?
On 2004-02-13T15:30-0600, Ejay Hire wrote: ) You could use AOL's tactic and transparent proxy all ) outbound port 25 traffic. Then it'd be a relatively simple ) matter to add mr. spammer's ip to a hosts.deny. If you were You may also need to filter inbound packets with a source port of 25, or any other ports you capture. As I believe has been mentioned here before, some spammers may use a dialup account just for its IP address, collecting return packets on the dialup interface but sending the actual content through some higher-bandwidth, unfiltered pipe. Filtering what goes out over the dialup account would be largely ineffective in this case, as nothing actually needs to be sent through that interface for the transmissions to succeed. -- Daniel Reed <[EMAIL PROTECTED]> http://naim-users.org/nmlorg/ http://naim.n.ml.org/ "True nobility lies not in being superior to another man, but in being superior to one's previous self."
Re: SMTP relaying policies for Commercial ISP customers...?
On Fri, 13 Feb 2004, Leo Vegoda wrote: > You wrote: > > [...] > > > Yes, that is a little bit stickier of an issue, IFF your goal is to > > somehow continue to provide the would-be spammer with the ability to send > > traffic to the net, provided it doesn't transit your mail server. I feel > > that you're overlooking the simple solution. Blocking the entire account > > so they can't access anything is the proper response to a spamming > > incident. > > If you block the entire account then the user can't use the account > to download the updates your Abuse Team will responsibly want to > point him/her at. If you want to lose the customer then that's your > business. If you want to keep the customer, helping them fix their > mistakes is probably a painful and thankless task - but important > and useful to the whole Internet community. RFC1918 is your friend, as is making internal copies of windowsupdate patches and virus removal tools. But even then, I would block 100% of access until we establish customer contact and are sure that the issue will be dealt with. Then, I would re-enable them on RFC1918 space, assist them in rectifying their problem, and then re-enable the rest of their account. This doesn't result in lost customers. This results in appreciative customers, even if they were blocked when they had the problem. If you don't block them, most people will never know until they've spewed gigs. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: SMTP relaying policies for Commercial ISP customers...?
On Fri, 13 Feb 2004, Leo Vegoda wrote: > > Yes, that is a little bit stickier of an issue, IFF your goal is to > > somehow continue to provide the would-be spammer with the ability to send > > traffic to the net, provided it doesn't transit your mail server. I feel > > that you're overlooking the simple solution. Blocking the entire account > > so they can't access anything is the proper response to a spamming > > incident. > > If you block the entire account then the user can't use the account > to download the updates your Abuse Team will responsibly want to > point him/her at. If you want to lose the customer then that's your > business. If you want to keep the customer, helping them fix their > mistakes is probably a painful and thankless task - but important > and useful to the whole Internet community. What about http://www.nanog.org/mtg-0402/gauthier.html After seeing that presentation, I wondered if an ISP could get away with something similar. Eric has the advantage of being the monopoly service provider for the dorms. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SMTP relaying policies for Commercial ISP customers...?
Leo Vegoda wrote: If you block the entire account then the user can't use the account to download the updates your Abuse Team will responsibly want to point him/her at. If you want to lose the customer then that's your business. If you want to keep the customer, helping them fix their mistakes is probably a painful and thankless task - but important and useful to the whole Internet community. It is probably worth mentioning that numerous malware today make an effort to block an user from accessing AV or windowsupdate sites after infection. Also, if you mirror the software as a courtesy, you´ll run into interesting copyright issues. Pete
Re: SMTP relaying policies for Commercial ISP customers...?
You wrote: [...] > Yes, that is a little bit stickier of an issue, IFF your goal is to > somehow continue to provide the would-be spammer with the ability to send > traffic to the net, provided it doesn't transit your mail server. I feel > that you're overlooking the simple solution. Blocking the entire account > so they can't access anything is the proper response to a spamming > incident. If you block the entire account then the user can't use the account to download the updates your Abuse Team will responsibly want to point him/her at. If you want to lose the customer then that's your business. If you want to keep the customer, helping them fix their mistakes is probably a painful and thankless task - but important and useful to the whole Internet community. Regards, -- leo vegoda RIPE NCC Registration Services Manager
RE: SMTP relaying policies for Commercial ISP customers...?
You could use AOL's tactic and transparent proxy all outbound port 25 traffic. Then it'd be a relatively simple matter to add mr. spammer's ip to a hosts.deny. If you were really big-brother, you could do real-time Beaysean scanning to identify "suspicious" hosts. -Ejay > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Ellis > Sent: Friday, February 13, 2004 11:55 AM > To: Andy Dills > Cc: [EMAIL PROTECTED] > Subject: RE: SMTP relaying policies for Commercial ISP customers...? > > > 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:[EMAIL PROTECTED] > > Sent: Friday, February 13, 2004 12:35 PM > > To: Dan Ellis > > Cc: [EMAIL PROTECTED] > > 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
Cisco Secure ACS Solution Engine-a 1-RU
Hello All , Is anyone using this product in in production ? I have a customer who is in a crunch for time & is unable to put any sugnificant resources together to build one from scratch . Please reply off list & I'll summarize . Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | 3542 Broken Yoke Dr. | Give me Linux | | [EMAIL PROTECTED] | Billings , MT. 59105 | only on AXP | +--+
Re: SMTP relaying policies for Commercial ISP customers...?
on Fri, Feb 13, 2004 at 12:35:17PM -0500, Andy Dills wrote: > 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. I beg to differ (though you did qualify your statement with "responsible", so maybe this critique doesn't apply). Yes, anyone providing Internet services such as inbound mail has to deal with spam. But to assume that all spam goes through your outbound mail servers is simply not commensurate with the facts. Since 1/1/04, we've rejected many email messages on our servers as having originated from hosts with generic rDNS symptomatic of dynamic/broadband/dialup/etc. IP assignment. Of those that were rejected, here is a quick summary, showing the domain or ccTLD of the originating host for those representing 20 or more attempts. 585 comcast.net46 co.uk 402 rr.com 46 tiscali.nl 188 attbi.com 43 yahoo.com 175 pacbell.net41 rogers.com 165 ameritech.net 40 mchsi.com 130 shawcable.net 38 cgocable.net 128 adelphia.net 36 snet.net 125 optonline.net 35 mindspring.com 106 wanadoo.fr 34 interbusiness.it 105 verizon.net32 surfer.at 103 bellsouth.net 30 telus.net 89 charter.com30 go2lnk.com 88 dsl-verizon.net30 com.br 80 t-dialin.net 29 net.au 79 swbell.net 28 rima-tde.net 63 ne.jp 27 wideopenwest.com 61 videotron.ca 24 bbtt.de 58 net.il 22 nuvox.net 51 proxad.net 21 com.hk 48 com.tw 21 bbtec.net 48 a2000.nl 20 telia.com 20 charter-stl.com These are not messages originating through known ISP mail servers, which we have to a large extent "offwhitelisted" - meaning we don't reject, but rather add a header to, such messages so that the header can be used as part of a quarantine strategy. Any large ISP mailhost we've received spam through (such as the freemail providers who are the greatest source of Nigerian 419/lottery scams) is "offwhitelisted" and may be subject to further blocking on a case by case basis, or to further filtering. Some of the messages aggregated above may well have been virus or worm delivery attempts; I haven't analyzed the day-to-day breakdown, but I'd be surprised if MyDoom doesn't figure in to a large extent in the cases documented above. But that is of no consequence; spam or virus messages both constitute abuse by out-of-band, often compromised, hosts. The problem of abusive mail originating from dynamic and otherwise non-sanctioned sources is real; viruses such as SoBig are suspected of being used in a vast net of compromised hosts, to evade other filtering strategies. Sobig.a and the Spam You Receive Today - LURHQ http://www.lurhq.com/sobig.html Sobig.e - Evolution of the Worm - LURHQ http://www.lurhq.com/sobig-e.html Sobig.f Examined - LURHQ http://www.lurhq.com/sobig-f.html In an eight-minute window on one of my servers yesterday, I saw the following: -- WKS Q 12:12:54 (9351) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 68.59.188.188 (pcp02265132pcs.batlfl01.tn.comcast.net) -- WKS Q 12:13:23 (9356) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 81.9.232.163 (cmr-81-9-232-163.telecable.es) -- WKS Q 12:15:21 (9513) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 200.55.72.231 (200-55-72-231.dsl.prima.net.ar) -- WKS Q 12:15:49 (9519) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 142.169.46.107 (c142.169.46-107.clta.globetrotter.net) -- WKS Q 12:15:51 (9520) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 142.165.147.216 (hsdbsk142-165-147-216.sasknet.sk.ca) -- WKS Q 12:15:56 (9521) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 141.158.119.119 (pool-141-158-119-119.pitt.east.verizon.net) -- WKS Q 12:17:03 (9556) to: [EMAIL PROTECTED] from: <[EMAIL PROTECTED]> at 81.59.87.42 (dslam42-87-59-81.dyndsl.zonnet.nl) ---
RE: SMTP relaying policies for Commercial ISP customers...?
On Fri, 13 Feb 2004, Dan Ellis wrote: > 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. Yes, that is a little bit stickier of an issue, IFF your goal is to somehow continue to provide the would-be spammer with the ability to send traffic to the net, provided it doesn't transit your mail server. I feel that you're overlooking the simple solution. Blocking the entire account so they can't access anything is the proper response to a spamming incident. > 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. I'm almost positive they would. Hell, many providers will give you a free NNTP feed if you want it. The goal is to maximize the use of the link between you and the customer while minimizing the use of the links between you and other networks. Services like SMTP and NNTP are great for that. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
RE: SMTP relaying policies for Commercial ISP customers...?
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:[EMAIL PROTECTED] > Sent: Friday, February 13, 2004 12:35 PM > To: Dan Ellis > Cc: [EMAIL PROTECTED] > 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 > ---
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 ---
Re: SMTP authentication for broadband providers
--On 13 February 2004 09:27 -0500 [EMAIL PROTECTED] wrote: Y-Haw! A return to the Old West of bangbaths and pathalias. *Not* that I think bilateral peering for SMTP is a great idea, but: a web of trust (A trusts B, B trusts C) does not necessarily mean the mail has to traverse the route of the web of trust (i.e. if A can establish B trusts C, then why not accept the mail directly from C if all B is going to do is forward it in essence unaltered). Perhaps this is no different from having someone DNS sign some form of inverse MX record saying "this is my customer and they shalt not spam you or lo the wrath of my abuse department shall descend on them and cut them off", and people not accept mail from those without that an inverse MX record signed by someone they trust, someone who someone they trust trusts (etc.). Alex
Re: SMTP authentication for broadband providers
--On 13 February 2004 08:47 -0500 Carl Hutzler <[EMAIL PROTECTED]> 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
Re: SMTP authentication for broadband providers
--On 13 February 2004 09:27 -0500 [EMAIL PROTECTED] wrote: Y-Haw! A return to the Old West of bangbaths and pathalias. No thanks. That's absolutely the issue with emerging resignation to "e-mail peering" and the like being the only solution to the spam problem. Folks who've been around long enough to remember UUCP maps or ADMD=/PRMD= know how huge the cost and support overhead of unreliability per e-mail sent is relative to SMTP delivery. Before we drop into that particular trap I'd like to think that one more attempt could be made at using PKI to do MTA identification. Maybe I'm a dreamer, but a world in which I only accept mail from MTA's that present a certificate from a CA I trust seems way better than one where I need an offline contract with a necessarily few people, and the world has to work out how to reach me through them. This won't stop spam at all levels, but neither will e-mail peering as it will still be possible to inject SPAM into a provider's network and therefore get it transited through their peering links. It's much easier to kill a black-hat or just careless MTA by locally blacklisting an individual public key, CN=, O=, or even C= if I'm minded to. -- Rob.
Nortel Optera 5200's
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, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: SMTP authentication for broadband providers
On Fri, Feb 13, 2004 at 11:05:16AM +, [EMAIL PROTECTED] 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. > > We, as network operators don't need to attack spam. We need > to ignore spam itself and get to work securing the network > that enables spammers to do their dirty work. Much talk about using SMTP AUTH, but nothing about using STARTTLS? Alone, SMTP AUTH is somewhat better, but requires that the passwords be stored plain-text on the server (CRAM-MD5 or DIGEST-MD5), or that the password traverse the wire in plain-text (PLAIN or LOGIN). So by requiring STARTTLS for SMTP AUTH the transmission can be encrypted and the passwords on the server encrypted as well. Furthermore, if mail server admins step up and enable STARTTLS on their systems it opens up the possibilities of using certificate verification and PKI. -- Some days it's just not worth chewing through the restraints... Mark Foster <[EMAIL PROTECTED]> http://mark.foster.cc/ pgp0.pgp Description: PGP signature
Re: SMTP authentication for broadband providers
On Fri, 13 Feb 2004 11:05:16 GMT, [EMAIL PROTECTED] said: > go a step further and require SMTP AUTH for every single > SMTP session on port 25 as well. That means that AOL's mailservers > would have to authenticate their sessions on Hotmail's servers > before sending email and vice versa. It means that you cannot > operate a mailserver without having a bilateral agreement in > place with some set of email peers. It provides a chain of 40 million .coms... > Yes, this probably means that we need to have some DNS > related changes so that a domain can publish a list of > their email peers and so that MTA software can figure out > where to forward a particular email to reach its destination. Y-Haw! A return to the Old West of bangbaths and pathalias. No thanks. pgp0.pgp Description: PGP signature
SMTP relaying policies for Commercial ISP customers...?
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
Re: SMTP authentication for broadband providers
> 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. We, as network operators don't need to attack spam. We need to ignore spam itself and get to work securing the network that enables spammers to do their dirty work. > 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. I wouldn't go quite so far as that. Yes, broad consensus of the network operator community would help us to secure the architecture of the email system. That's why I have suggested that large email operators should be meeting regularly in a forum where they can discuss and agree upon *BEST PRACTICES*. But it also helps for people to implement best practices in a piecemeal fashion because that provides the real-world operational experience to prove that a particular practice is feasible. >From recent conversations on the list it appears that the BCPs for email include using the submission protocol for all end-user sending of email. But I would like to see this go a step further and require SMTP AUTH for every single SMTP session on port 25 as well. That means that AOL's mailservers would have to authenticate their sessions on Hotmail's servers before sending email and vice versa. It means that you cannot operate a mailserver without having a bilateral agreement in place with some set of email peers. It provides a chain of trust through those bilateral agreements that makes it easier to block SPAM and catch spammers. Yes, this probably means that we need to have some DNS related changes so that a domain can publish a list of their email peers and so that MTA software can figure out where to forward a particular email to reach its destination. But none of this is rocket science. And all of it could be accomplished by sitting the major email operators around a table to hash it out. NANOG could help here by devoting the next meeting to the various technical operational email issues and by extending to an additional day for the email operators forum. There is plenty of BCP material that could be presented and even though some of the operators like AOL have presented this in the past, an update would be useful to a lot of us. --Michael Dillon
The Cidr Report
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 PrefixesCIDR Agg
06-02-04130549 91173
07-02-04130555 91204
08-02-04130702 91246
09-02-04130759 91319
10-02-04130872 91396
11-02-04130759 91492
12-02-04131091 91537
13-02-04131225 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 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 131255915013975430.3% All ASes
AS4323 685 203 48270.4% TW-COMM Time Warner
Communications, Inc.
AS6197 732 298 43459.3% AS6197
AS7018 1371 963 40829.8% ATT-INTERNET4 AT&T WorldNet
Services
AS701 1343 951 39229.2% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 506 128 37874.7% ADELPHIA-AS Adelphia Corp.
AS27364 382 33 34991.4% ACS-INTERNET Armstrong Cable
Services
AS6198 545 214 33160.7% BATI-MIA BellSouth Network
Solutions, Inc
AS4134 652 329 32349.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS22909 340 20 32094.1% DNEO-OSP1 Comcast Cable
Communications, Inc.
AS22773 342 34 30890.1% CCINET-2 Cox Communications
Inc. Atlanta
AS1239 950 665 28530.0% SPRINTLINK Sprint
AS4355 385 101 28473.8% AS4355
AS9583 341 77 26477.4% SATYAMNET-AS Satyam Infoway
Ltd.,
AS17676 294 41 25386.1% GIGAINFRA Softbank BB Corp.
AS1221 902 650 25227.9% ASN-TELSTRA Telstra Pty Ltd
AS6347 330 83 24774.8% DIAMOND SAVVIS Communications
Corporation
AS6140 357 127 23064.4% IMPSAT-USA ImpSat
AS25844 243 16 22793.4% SKADDEN1 Skadden, Arps, Slate,
Meagher & Flom LLP
AS6478 260 38 22285.4% ATT-INTERNET3 AT&T WorldNet
Services
AS209723 511 21229.3% ASN-QWEST Qwest
AS14654 2143 21198.6% WAYPORT Wayport
AS13083 2168 20896.3% AS13083 Mannesmann
Datenverarbeitung Autonomes
System
AS11305 242 41 20183.1% INTERLAND-NET1 Interland
Incorporated
AS2386 419 231 18844.9% INS-AS AT&T Data
Communications Services
AS20115 612 424 18830.7% CHARTER-NET-HKY-NC Charter
Communications
AS5668 345 158 18754.2% AS-5668 CenturyTel Internet
Holdings, Inc.
AS4519 203 20 18390.1% MAAS Maas Communications
AS6327 207 29 17886.0% SHAW Shaw Communications Inc.
AS9929 203 31 17284.7% CNCNET-CN China Netcom Corp.
AS15270 210 39 17181.4% AS-PAETEC-NET PaeTec.net -a
division of
PaeTecCommunications, Inc.
Total 14554 6466 808855.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.
6
Re: SMTP authentication for broadband providers
--On 12 February 2004 18:13 -0500 [EMAIL PROTECTED] wrote: Since when was anything sent over port 25 confidential? Since Phil Zimmerman decided to do something about it. Well if you are considering the plain-text of an encrypted mail, it doesn't much matter whether port 25 is intercepted by whatever governmental agency, or relayed through however many servers with questionable operators. And quite frankly, he was right - that's the only way to do it right. Oh I agree. My point to the original poster was that supposed security of port 25 communications was not a good reason to avoid using relays on the way. If you want security of you communications a good first step is PGP (et al.). (Note that this does still leak To:/From:/Subject: lines, but they be read via wire-tap just as they can be read via intercept at a relay). Alex
