FYI: CIDR Report changes
Hi, As most of you know, the CIDR Report was conceived by Tony Bates in 1995 as a means to monitor and inform the community about the amount of CIDRisation activities being carried out by Internet Service Providers. The CIDR Report has been highly successful, much referred to and well respected snapshot of the growth in the Routing Table, as well as providing information on the level of aggregation being carried out in our community. In recent years it has become more of a challenge to maintain the software to keep up with the rapid growth in the Internet. Philip Smith, who has produced a widely published Routing Table Report since late 1998, has helped to keep the Report up to date with current allocation and assignment information. But with the large number of views of the routing table, and with the numerous requests many individuals and organisations have been making for enhancements to the CIDR Report, we have agreed that the future of the CIDR Report now rests alongside the very comprehensive BGP Table Analysis which Geoff Huston has been running for the last year. This Friday's CIDR Report (23rd August) was the last one posted from Tony's original system. As from the coming Friday (30th August), the CIDR Report will come from Geoff Huston's new implementation. The e-mail will go to the same operations mailing lists, will look very similar in layout, and will have greatly updated information compared with the original. Furthermore, the routing table view will be the summary from the RouteViews project. The supporting website for the CIDR Report has been vastly improved, with greater detail, the ability to search on aggregation effort per AS, and so on. A snapshot of Geoff's implementation can be found at http://bgp.potaroo.net/cidr/. Regular users of the information contained in the CIDR Report should check out the website and the new features in the report. As ever, comments and feedback are most welcome; these should be sent to [EMAIL PROTECTED]. Tony Bates, Geoff Huston, Philip Smith
Re: Traffic Threshold monitoring?
Rob Mitzel wrote: So my question is...what's out there that will allow us to check thresholds on traffic, and notify us if needed? RMON alarms and events for one. These are available on pretty much all recent versions of IOS. You can set a rising or falling threshhold on any MIB variable you like, and period of time between polls. This will generate a trap to a network management station, and you can choose to do what with you will the alarms. If you want to tie this stuff into scripts you can use the net-snmp trap daemon to call various trap handlers that could do something keep track of the duration of the spike or send an alert. Another thing that is out there in later releases is the EVENT MIB. This is probably overkill for what you want, and the only way to configure it is through SNMP. For all of this stuff there is documentation on CCO. For RMON alarms and events, see: http://www.cisco.com/warp/public/477/RMON/18.shtml For the EVENT MIB see: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtevent.htm The net-snmp package is available at SourceForge: http://sourceforge.net/projects/net-snmp Eliot
Re: Traffic Threshold monitoring?
## On 2002-08-25 23:54 -0700 Rob Mitzel typed: RM RM Hi everyone, RM RM Quick question. We're currently using MRTG to monitor traffic on a RM number of cisco switches connected to various customers. Now, this is RM all great and everything, except there's no real way to monitor if a RM customer's traffic goes completely out of whack (i.e. they start RM hammering 20 mbps instead of 300kbps) without manually checking MRTG RM every few minutes (and that'd be kinda time-consuming, you'd think.) We RM also show individual MRTG pages to our customer base via some handy mods RM we made. Try searching http://people.ee.ethz.ch/~oetiker/webtools/mrtg/reference.html for THRESHOLD CHECKING at which point (hopefully ;-) you can RTFM .. -- Rafi
Bush's Cyber-Security Plan Targets E-Mail
Here's Big brother...now we're all going to be spies on our fellow citizens. http://www.eweek.com/article2/0,3959,481112,00.asp August 23, 2002 By Caron Carlson and Dennis Fisher In an effort to bolster the nation's cyber-security, the Bush administration has plans to create a centralized facility for collecting and examining security-related e-mail and data and will push private network operators to expand their own data gathering, according to an unreleased draft of the plan. The proposed cyber-security Network Operations Center is included in a draft of The National Strategy to Secure Cyberspace, which was developed by the president's Critical Infrastructure Protection Board with input from the private sector and is due to be released Sept. 18. The call for expanded data collection and analysis results from administration concerns that efforts to secure cyber-space are hampered by the lack of a single point of data collection to detect cyber-security incidents and issue rapid warnings, according to the draft strategy, obtained by eWEEK. Critics, however, worry that such a system would be expensive and difficult to manage, and would allow government agencies to expand their surveillance powers. Other recommendations include restricting the use of wireless technologies by government agencies; requiring corporations to disclose their IT security practices; establishing a test bed for multivendor patches; creating a certification program for security personnel; and mandating certifications for all federal IT purchases. Howard Schmidt, vice chairman of the PCIPB, said that the center would consolidate threat data from the country's collection end points, such as the FBI's National Infrastructure Protection Center, the Critical Infrastructure Assurance Office, the Department of Energy and commercial networks. Private companies would be encouraged to increase the amount of data collected and share it with the government. Major companies generally report this information internally, Schmidt told eWEEK. We're looking for that to come back to a central location. According to the draft strategy, the public/private initiative would involve the major ISPs, hardware and software vendors, IT security companies, and Computer Emergency Response Teams, in addition to law enforcement and other agencies. Some feel that the government's internecine rivalries and information-sharing rules will hamstring any attempt at centralized collection and analysis. There are such high barriers in government to being able to disseminate information and adjusting the environment to react to threats, I don't think it will have much impact, said William Harrod, director of investigative response at TruSecure Corp. in Herndon, Va., and a former FBI computer forensic specialist. They'll have different information coming in from different analysts, and they'll have to weed through it. The proposed strategy recommends that the center be partially federally funded, but it would inevitably impose new costs on the private sector without commensurate benefits, critics charged. Government doesn't have a good track record when it comes to collecting and disseminating massive volumes of data, said Kevin Baradet, network systems director at Cornell University's Johnson Graduate School of Management in Ithaca, N.Y. We could be drowning in data, most of it noise. Then there are the privacy concerns. Whatever the federal government wants to do with its own data is OK with me as long as it doesn't waste my personal and corporate tax dollars, said Karl Keller, president of custom software developer IS Power Inc., in Thousand Oaks, Calif. The privacy aspects, however, concern me greatly. This sounds like a dramatic and evil expansion of Echelon and Carnivore. The strategy also calls on the FBI, Secret Service and Federal Trade Commission to establish a single system for corporations to report Internet fraud and extortion, illegal hacking, and unauthorized network intrusions. It recommends that the federal government systematically collect data on cybercrime victims and cyber-intrusions from businesses. The administration hopes to assuage industry fears by recommending legislative changes--including exemptions from Freedom of Information Act requirements and exemption from antitrust laws--that would reduce liability for companies turning over communications to law enforcement.
Re: IETF SMTP Working Group Proposal at smtpng.org
Brad Knowles [EMAIL PROTECTED] writes:
At 11:40 AM +0100 2002/08/23, Martin Cooper wrote:
How does it break mailing-lists? If the list sets the envelope sender
to [EMAIL PROTECTED] creating a MAIL-FROM shouldn't
be a problem.
You may be surprised to discover this, but most mailing lists are
not proper mailing lists and are not managed with proper mailing list
management software. Most mailing lists are actually handled as
aliases, and therefore do not modify the envelope sender address.
The only problem I can see is what to do about bounces
(i.e. with a null envelope sender) - guess you could use header From
instead maybe.
Actually, this is one area that the paper addresses.
repudiated(mailfrom, ipsource) = {
(lhs, rhs) = parse_addr(mailfrom);
// handle MAIL FROM: somehow
mxset = get_mx(MAIL-FROM . rhs);
if (mxset == NULL)
return nonrepudiated;
OK - but unconditionally permitting null-return paths means that
spammers can drive a coach and horses through the hole it leaves. :-(
Martin
Re: IETF SMTP Working Group Proposal at smtpng.org
[EMAIL PROTECTED] (Martin Cooper) writes: OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( that's how the proposal is optional. spammers who lie about their source/return addresses using nonexistent domain names are not the subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm trying to address the issue of spammers who lie about _existing_ source/return domain names. -- Paul Vixie
Re: Traffic Threshold monitoring?
Yo Rob! On Sun, 25 Aug 2002, Rob Mitzel wrote: So my question is...what's out there that will allow us to check thresholds on traffic, and notify us if needed? I use Nagios: http://www.nagios.org. It used to be called Netsaint. If it does not do exactly what you want then you can easily right a plug-in to do it. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Paul Vixie wrote: [EMAIL PROTECTED] (Martin Cooper) writes: OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( that's how the proposal is optional. spammers who lie about their source/return addresses using nonexistent domain names are not the subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm trying to address the issue of spammers who lie about _existing_ source/return domain names. This indeed will fix a lot of problems, and force people to use their mail upstreams mail-relays. ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. This will force people to use their upstreams email address though when sending email outbound. And this isn't always what someone wants. But because especially the big U has many 'users' who simply take a dailup account, spew spam to all kinds of taiwanese, chinese, etc servers those 'users' aren't hard to block out unfortunatly. IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed. Unfortunatly that will take some time, installing a tool like spamassasin/razor etc is much more effective even though those tools won't stop spammers. At least it will help a bit against one of the bigger internet problems. Greets, Jeroen
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Mon, 26 Aug 2002 21:12:40 +0200, Jeroen Massar [EMAIL PROTECTED] said: IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed. Given the number of providers who seem to think ingress and/or rfc1918 filtering shouldn't be done, what makes you think that all servers will be upgraded to support THIS proposal? (If you don't want to re-start the RFC1918 war, feel free to substitute ANY OTHER thing that most people think is a Good Thing, but we've seen some sizable minority not deploy for reasons they consider perfectly valid). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04746/pgp0.pgp Description: PGP signature
sprint biz dsl provisioning contact
Hello, If anyone from sprint who can remove a route can contact me off line I would appreciate it. Trying to switch providers since sprintbiz dsl is being discontinued I need to have an announcement stopped. Thanks, Michael...
Re: sprint biz dsl provisioning contact
[EMAIL PROTECTED] is NOT [EMAIL PROTECTED] go call or email sprint. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 26, 2002 4:35 PM Subject: sprint biz dsl provisioning contact Hello, If anyone from sprint who can remove a route can contact me off line I would appreciate it. Trying to switch providers since sprintbiz dsl is being discontinued I need to have an announcement stopped. Thanks, Michael...
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal atsmtpng.org)
On Mon, 2002-08-26 at 13:43, Jeroen Massar wrote: Read my sentence again, because I really won't see everybody install/use it. One can also simply see so by the problems related to the fact of installing security updates. Some 'companies' and individuals are simply too sleezy/lousy or whatever to do it. And thus open spam relays will be kept alive which is why there are RBL's. This will only help a bit, and tools like SpamAssasin/Razor will keep a load of stuff of your servers. Paul's proposal doesn't require battening down every mail server out there either. The particularly useful aspect of this approach is that clueful administrators of more visible mail servers can cut down on being spoofed. This would also be specifically effective against Klez and similar annoyances. It doesn't matter if the spammer/virus is cooperating with the system or not. If the final destination contacts the mailfrom callback server, and it says This definitely isn't legitimate then even with a small adoption rate, there will still be a significant decrease in cruft, and the mail system being spoofed has something better to point at when they get flooded with complaints from people who actually trust the mail from field. But then, all this is fairly clear in the draft. I can't figure out why it hasn't been more widely accepted as a Good Idea. The presumably appropriate topic for discussion on this list is why a system such as this would be a problem for network operators who choose not to implement such a callback feature. So far the only objection I've seen is It won't make any difference and that seems to be a flimsy argument. Please correct me if I'm missing something. Making it harder to get into your house is better than putting the doors wide open... Every bit helps... Exactly. -dvd
Re: Measuring BGP routes
On Thu, Aug 22, 2002 at 04:07:11PM -0700, Dr. Mosh wrote: Wonder if anyone of you have come across the need for this. They have. Ask your vendor to implement the BGP MIB version 2. If useful things are missing from this MIB, now is a good time to ask for them. http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-02.txt I'm basically looking for a Cisco IOS MIB that tells me the number of BGP routes a router currently has, for graphing purposes to keep track over time. Anyone know the mib handy? Thanks private reply works -- Jeff Haas NextHop Technologies
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
David Van Duzer [EMAIL PROTECTED] writes: [...] The presumably appropriate topic for discussion on this list is why a system such as this would be a problem for network operators who choose not to implement such a callback feature. So far the only objection I've seen is It won't make any difference and that seems to be a flimsy argument. Please correct me if I'm missing something. The problems with it are clearly laid out within the document itself: 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if [EMAIL PROTECTED]'s account has a .forward file pointing at [EMAIL PROTECTED], then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as multistage inbound relays. This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) No real solution is proposed for the above; if you remail with a new envelope, how does the original sender get the bounce? And if you don't, the proposal isn't workable without refusing to support forwarding at all, which would just encourage mail service providers to enforce an annoying restriction. 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back home may become a necessary first hop for mobile e-mail. The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. ScottG.
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal atsmtpng.org)
Point of Information: Every single purely technical approach to stopping spam has been a complete loser. I understand the old adage that when all you have is a hammer the whole world looks like a nail. And that all many people on this list have is a technical hammer, some ability to hack around with cisco access lists or similar, so they tend to hold out hope that some new access list formula might be the one that saves the day (or similar, don't quibble the example!) But spam is as much a socio-legal problem as a technical one which is why, I'd claim, it's been so completely resistant to all purely technical approaches thus far. What we need are technical solutions which help with concomitant socio-legal solutions. If you haven't noticed, the spammers are winning completely, the waters are rising rapidly. More and more legitimate-sounding companies and products are spamming, and by and large the public perception in the non-anointed* business community are coming to the conclusion that they receive all this spam so it must be a legitimate form of advertising. Let me throw out the following to show how blind the technical community has been: There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. (before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964) However, we expect lawmakers to recognize and define the problem and get it right when the engineers who understand the technology and problem, in nearly a decade of whining, can't even be bothered to provide them with robust definitions of what it is the whining is about. Food for thought, that's all. But, personally, I'm hesitant to spend my time trying to study the merits of yet another anti-spam miracle cure, even if it seems at first glance (like so many before) that it might foil some particular flavor of spam which has been prevalent in the past. Now, after sitting through this extended, multi-day discussion of spam someone can send me the standard discussion of spam is not a subject for nanog! because I'm not a member of the amen crowd. * non-anointed: not a member of the technical community hence indoctrinated into a particular ethical view of what's right and wrong on the net. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal atsmtpng.org)
On Mon, 2002-08-26 at 15:47, Scott Gifford wrote: The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. Precisely. It's only an issue for those who implement the feature. Another thought that came to mind was a sort of hybrid between this and the central registry of trusted servers. Rather than maintain a central registry, the mail-from server could provide its own registry of trusted keys for its own domain. Granted, this is probably just as complicated as widely implementing SMTP AUTH, but it does give a little more flexibility for those complaining that this would break home-grown mail servers. What I am mostly curious about is if there are any potential problems with those who choose to ignore the feature entirely. -dvd
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
David Van Duzer [EMAIL PROTECTED] writes: On Mon, 2002-08-26 at 15:47, Scott Gifford wrote: The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. Precisely. It's only an issue for those who implement the feature. Another thought that came to mind was a sort of hybrid between this and the central registry of trusted servers. If a large ISP, say AOL, implements this, and I operate the mailserver with users who send (relay through me) mail with a from address of their (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me and my users. If a large ISP, say AOL, implements this, and I'm an end-user trying to send mail with a from address at my (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me. I know this isn't what you're looking for, but individual domains aren't so isolated that you can implement this sort of thing without zero effect on other mailservers. You really have to solve the whole problem before it becomes usable at all. I'm not saying it's an unsolvable problem, just that these two issues need to be better addressed before it's a usable suggestion. ScottG.
Re: Paul's Mailfrom (Was: IETF SMTP Working GroupProposal at smtpng.org)
At 9:12 PM +0200 2002/08/26, Jeroen Massar wrote: ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. Agreed. This will force people to use their upstreams email address though when sending email outbound. Yup. IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed. I still think that it causes problems for mailing lists. Moreover, you need to know the complete outbound path for all e-mail, from soup to nuts, so that you can add all those machines to the list of known mail-from MX entries for your domain. I'm sorry, complete information like this just doesn't exist anymore. Knowledge like this did exist twenty or more years ago, back when there were only a few UUCP nodes. But even then, things quickly got to a point where people couldn't possibly know all possible paths between any two points, and people just listed their address from a small set of well known nodes. Unfortunatly that will take some time, installing a tool like spamassasin/razor etc is much more effective even though those tools won't stop spammers. I disagree that it would stop spammers. Even if everything else worked, all it would require is that they get more creative in faking e-mail addresses. They just have to make sure that when the mail is delivered to you, it comes through a machine that is on the list of MXes for the mail-from entry for the domain. Put a simple wildcard MX in there (and nothing else), and it should match anything. Moreover, even if all servers on the Internet were secured in this manner and there were no open relays, it would also require perfect reverse DNS because the MXes are listed by name and not IP address -- that's assuming you do a reverse lookup on the IP address and require that the returned name is on the list. If you do a forward lookup (taking each of the listed MXes for mail-from and looking up their IP address), that would require that no one use DNS-based or geographical-based load-balancing, because then the forward lookup on the name might not match the IP address of the sending relay. At least it will help a bit against one of the bigger internet problems. I agree with the overall IETF approach of implementing something and seeing if it works (as opposed to talking things to death), but this is a case where I fear that the proposed solution could only work in a perfect world, and even then it would have some serious problems. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: IETF SMTP Working Group Proposal at smtpng.org
At 3:26 PM +0100 2002/08/26, Martin Cooper wrote: return nonrepudiated; OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( IIRC, the RFCs require that you accept mail from the null envelope sender. Yes, it does open a hole, but spammers have avoided using this address for a long time, for reasons I still don't understand. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Paul's Mailfrom (Was: IETF SMTP Working GroupProposal at smtpng.org)
ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. Agreed. why not do it to port 80 as well? what the hell, why not do it to all ports? who the hell needs an internet anyway, let's all have a telco walled garden. string of expletives can we get back to operating the internet, not killing it? another, even longer, string of expletives randy
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal atsmtpng.org)
On Mon, 26 Aug 2002, Greg A. Woods wrote: As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, whether the destination port of those TCP segments is 25 or something else. Well, you might be able to pay your ISP for that kind of service, but not all ISPs need supply such service and certainly not many users really _need_ such a level of service. So now I have to justify the kind of services I want to use? What's next, me having to register the words I'd like to say over the phone with my phone company? I'll tell you what. I'll filter port 25 for the entire world on my routers, and you mail guys go back to running UUCP like in the good old nearly-spam-free days.
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Randy Bush wrote: ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. Agreed. why not do it to port 80 as well? what the hell, why not do it to all ports? who the hell needs an internet anyway, let's all have a telco walled garden. string of expletives can we get back to operating the internet, not killing it? another, even longer, string of expletives Nice rant Randy, but if you even ever wondered why the wording Mail Relay exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam addresses as a source and only allowing through configured addressess it would save you, me and the rest a load of crap which maybe could kill the internet... We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on EVERY single node on the internet. Indeed it limits your clients, just like a NAT does, just like firewalling does, but it also saves a load of problems. And maybe your view is operating the internet but some people have a too busy spam/abuse mailbox to be able to do usefull stuff like tracing ddosses, which is yet another thing people should do but aren't doing: egress filtering. If (and if) everybody did that, we wouldn't be seeing spoofed addresses, rfc1918's and other stuff on the internet either now would we? So pointing these facts out *HAS* something to do with operating the internet. hint http://as112.net/ /hint Greets, Jeroen
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Brad Knowles [EMAIL PROTECTED] writes: [...] Moreover, even if all servers on the Internet were secured in this manner and there were no open relays, it would also require perfect reverse DNS because the MXes are listed by name and not IP address -- that's assuming you do a reverse lookup on the IP address and require that the returned name is on the list. The proposal suggests that you get all of the A records for all of the accepted names, then make sure that one of the A records matches the address that the connection came from. See sec. 2.3. Even if it did require good reverse DNS, that would only be needed for domains that chose to implement this, and only for addresses that are allowed to send mail from that domain. ScottG.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, 27 Aug 2002 00:59:49 +0200 Jeroen Massar [EMAIL PROTECTED] wrote: Nice rant Randy, but if you even ever wondered why the wording Mail Relay exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam The point is that 25 is just a number. You'll eventually be blocking all numbers sooner or later (and re-inventing dumb terminals). John
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On August 27, 2002 at 00:59 [EMAIL PROTECTED] (Jeroen Massar) wrote: We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on EVERY single node on the internet. Actually, I think we did. Unfortunately it turned out to be a really, really, bad decision. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On 03:07 PM 8/26/02, Barry Shein wrote: Let me throw out the following to show how blind the technical community has been: There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. (before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964) I guess you haven't read RFC 3098 yet then. http://www.geektools.com/rfc/rfc3098.txt How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $ MAKE ENEMIES FAST! $ Table of Contents 1. Introduction .. 2 2. Image and Perception of the Advertiser. 4 3. Collateral Damage . 5 4. Caveat Mercator ... 5 5. Targeting the Audience 7 6. Reaching the audience . 8 A. Dedicated website or web page 8 B. Shared Advertising website . 9 C. Netnews and E-Mailing list group postings 10 D. Compiled E-Mail Lists 11 7. Opt-In Mailing Lists .. 12 A. Privacy 13 B. Integrity .. 13 C. Protection . 16 8. Irresponsible Behavior 16 9. Responsible Behavior .. 17 10. Security Considerations ... 19 Appendices 20 A.1 The classic Pyramid 20 A.2 What about Ponzi? .. 22 A.3 So all multi-levels are evil? .. 22 B.1 Why Web Privacy? ... 23
Anyone home at swbell.net?
-- Forwarded message -- Return-Path: [EMAIL PROTECTED] Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by cliff.mfn.org (8.11.1/8.9.3) with ESMTP id g7R0XNc65241 for [EMAIL PROTECTED]; Mon, 26 Aug 2002 19:33:23 -0500 (CDT) (envelope-from [EMAIL PROTECTED]) Received: from vm1-ext.prodigy.net (vm1-int.prodigy.net [192.168.240.84]) by pimout5-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id g7R0XMW72264 for [EMAIL PROTECTED]; Mon, 26 Aug 2002 20:33:22 -0400 Received: (from root@localhost) by vm1-ext.prodigy.net (8.11.0/8.11.0) id g7R0XM970768 for [EMAIL PROTECTED]; Mon, 26 Aug 2002 20:33:22 -0400 From: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: Mon, 26 Aug 2002 20:33:16 -0400 Subject: Returned mail: SPAM: remailer, Increase your breast size. 100% safe! (fwd) To: [EMAIL PROTECTED] User's mailbox is full: [EMAIL PROTECTED] Unable to deliver mail.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, 27 Aug 2002 01:54:39 +0200 Jeroen Massar [EMAIL PROTECTED] wrote: SMTP is a protocol which is based on relaying messages from one mailserver to another. An endnode (especially workstations) don't need to run SMTP. I'm not sure how to truly disable an SMTP server from running on an end host. You can block or force forward port 25, but that is just a number. Be prepared to start doing that for all ports, then protocols, then IP addresses, then protocols again. Furthermore, a forced relay, while perhaps helping to solve the immediate spam problem is most definitely interfering on other things with potentially harmful long term effects. Two of those are end-to-end transparency and the fixing of the real problem. You may not care about either of those, but I would argue they shouldn't be dismissed without very serious thought. So what's so bad about forwarding all tcp/25 traffic over that relay and letting that relay decide if the MAIL FROM: is allowed to be relayed? And if a client wants to mail from another domain which isn't There are some potential problems. Don't bother answering them, I'm sure they can be disputed, but I'm also sure there are plenty of other examples an SMTP expert could think of: What if there is a new SMTP specification that doesn't work through the forced relay? What about simply not trusting a relay to do the right thing or for fear of a forced relay adding/changing/snooping/delaying the traffic? What about when SMTP starts going over something other than TCP port 25? The whole problem is yet again that a small amount of people (this time spammers) make a whole lot of problems for a lot of people (we). Maybe some different thinking is called for. Here are some other suggestions, take them or leave them. They aren't perfect either (don't try and answer these either, I'm sure they can be disputed :-): Force forward by default, but allow anyone who wants to use TCP port 25 the ability to do so. They must sign an non-abuse agreement or whatever. Then they get their host/link put into the TCP port 25 open path. Do some rate-limiting by default. Perhaps coupled with the above? Start offering spam blocking and filtering services for end users. Get better at monitoring and incident response. This will pay dividends for lots of other areas as well. ...and finally to quote Randy, send code. :-) John
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Force forward by default, but allow anyone who wants to use TCP port 25 the ability to do so. They must sign an non-abuse agreement or whatever. Then they get their host/link put into the TCP port 25 open path. Every ISP I have ever worked for and every ISP I have ever used has eventually been convinced by me to come around to this policy. Do whatever you want by default, but let trusted/clueful people opt out of it and just get their IP datagrams from point A to point B. I personally wouldn't sign an agreement with an ISP that allowed them to molest my traffic in this manner unless it allowed me to opt out of it. I've seen the headaches such assumptions about what everybody else needs/wants to do can cause. DS
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Surely your not a spammer looking for tips are you? :-) John
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Martin Sent: August 26, 2002 10:15 PM To: [EMAIL PROTECTED] Subject: Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org) but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Well, it must specify it somewhere, since at least a couple of times a week we have our users ask how to stick a port number in an MX record. :) Where they got this idea is beyond me (unfortunately), but it's quite a common question... Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, ... ...and, occasionally, your ISP's abuse desk. If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. If they want to do some simple things to keep the slacker cutoff point at those numbers rather than other numbers which are 90% smaller, you'll understand the economics. If one of those simple things is blocking outbound TCP/25, then I hope you have alternatives including changing ISP's... ...but if you don't, then it's between you and your ISP, and best of luck. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
Every single purely technical approach to stopping spam has been a complete loser. In the fullness of time, the universe itself will die of heat. So what? What matters more is what use is made of time before it gets so full. A number of purely technical approaches to stopping spam have been quite successful... in the short term... which not the same as being a complete loser in the long term. (Everything's a complete loser if you measure it right.) There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. Someone else already quoted an RFC from geektools that contains such a definition. http://www.mail-abuse.org/standard.html, on the other hand, is something I cowrote back when I still had an operational role at MAPS, and still seems pretty careful and pretty professional (and pretty public.) -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
$author = John Kristoff ; On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Surely your not a spammer looking for tips are you? :-) hardly. just someone who has tried blocking traffic to dialup pools with DST port 25 and forced relay on all outbound traffic with DST port 25. it worked... for some values of worked. as most would know we broke smtp-auth for a small handful of people that were trying to use it. as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? marty -- My Everest is not in Nepal, She's sleeping in the bedroom second right down the hall. Ed Hiliary couldn't crack this nut, He'd be hiding in the lounge room with the rest of us. My Everest - Lazy Susan
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
On 27 Aug 2002, Paul Vixie wrote: As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, ... ...and, occasionally, your ISP's abuse desk. If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. I don't disagree with what I believe to be the goal of you offering the numbers you are (encourging provider to reduce to a minimum level the theft of service that their customers may be perpetrating a.k.a. spamming while balancing the costs of such a function,) but you're offering very definitive figures/labeling, and I'm curious as to what you are basing your calculations/labels on, and what the linearity of the scaling is in your opinion. Your own experience at MAPS? At MFN? Wishful thinking? Personally, I'd much rather try to justify a FTE for 1000 T-1s than I would for 10,000 dialup users. It's hard to imagine any ISP with 100,000 dialup customers succesfully justifying 10 individuals dedicated to abuse to the powers that be. I'm aware of ISPs with 1,000,000+ dialup customers that have an *admin* team of that size and seem to have a relatively good control on spam issues. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. ... you're offering very definitive figures/labeling, and I'm curious as to what you are basing your calculations/labels on, and what the linearity of the scaling is in your opinion. Your own experience at MAPS? At MFN? Wishful thinking? those numbers are very round. i've seen folks do 1 FTE per 50,000 dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, i.e., full ANI with filtering, full verification of credit cards (charge and refund before opening the account), nonrefundable deposit if terminated for spamming, and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. Personally, I'd much rather try to justify a FTE for 1000 T-1s than I would for 10,000 dialup users. like i said, the numbers were very round. as long as you understand that there IS a ratio and that the cost of dealing with outbound traffic does not end at the demarc point where it's handed to a peer or transit, then what the actual nonzero abuse desk costs actually are is a detail. this seems like something isp/c or cix should do a survey on.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
On Mon, 2002-08-26 at 21:08, Paul Vixie wrote: ...and, occasionally, your ISP's abuse desk. If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. If Not to try to undercut the general point, but that would imply that Earthlink, AOL, and MSN (for examples) should have a combined abuse department of roughly 1500 employees. Well, perhaps those were poor examples then. It would be wonderful if it were the case, and while it seems like laziness when we talk about the big guys, most middle sized providers just don't have the operating budgets to not slack at least a little bit. The simple things you referred to would be designed to make the function of abuse personnel / subscribers look more logarithmic, but this whole thread and all the other arguments stem from the fact that it really isn't that simple. Spam is a social problem, but no one seems to think that solving it socially (a la paying for well staffed abuse departments) is the answer. So as you suggest, the solution is a combination of social and technical answers, keeping that personnel ratio manageable. But this debate (I'm not debating with *you*) keeps coming around full circle. Perhaps the real social problem is convincing whatever standards bodies and vendors necessary that it is a technical problem. There seems to be far too much apathy (FUD?) rather than just designing a partial solution, however imperfect, and implementing it. -dvd
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? actually it would be _smtp._tcp.$DOMAIN but it's not in use for e-mail. or web, even though that's the example that appears in the rfc. the only users i'm aware of are Microsoft and Apple for their respective service discovery systems, and MIT Kerberos iff your domain name and your realm name are the same. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
On Tue, 27 Aug 2002, Paul Vixie wrote: If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. ... you're offering very definitive figures/labeling, and I'm curious as to what you are basing your calculations/labels on, and what the linearity of the scaling is in your opinion. Your own experience at MAPS? At MFN? Wishful thinking? those numbers are very round. i've seen folks do 1 FTE per 50,000 dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, i.e., full ANI with filtering, full verification of credit cards (charge and refund before opening the account), nonrefundable deposit if terminated for spamming, and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. All good additions, thanks for the clarification. Personally, I'd much rather try to justify a FTE for 1000 T-1s than I would for 10,000 dialup users. like i said, the numbers were very round. as long as you understand that there IS a ratio and that the cost of dealing with outbound traffic does not end at the demarc point where it's handed to a peer or transit, then what the actual nonzero abuse desk costs actually are is a detail. this seems like something isp/c or cix should do a survey on. Unfortunately, both organizations seem to be defunct for all intents and purposes, much to my disappointment. The only *active* independent ISP organization I'm aware of is the American ISP Association (http://www.americanisps.com) (disclaimer I know very little about this organization, and it's obviously U.S.-centric.) Perhaps the Spamcon Foundation(http://www.spamcon.org) would be well-suited to this task... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Barry, I have a wrench :) Everything looks like a nut to me. But in all seriousness. I have to agree with Barry's statement here. Spam is very much a social, political, ethical, and financial issue. Filters are static things, that have to be updated, and can't see every case that comes thru. Even the Habeas idea, while novel and interesting, requires people to do quasi technical things. The average user isn't going to do those things. Much spam comes from relay servers outside of north america, but is targetted towards us yanks. Until we make the social or financial impact real enough to stop the spammers, they will continue. Enough people respond to spam, that its worth it to them to sell there warez via this method. I think we geeks would spend better time, trying to help adjust the social and financial changes, instead of smashing on the the bolt with the hammer... A stab at defining SPAM: The sending of email to a person, where there is a financial gain (directly or indirectly) to the sender, and where the receiver did not expressly request such email. Please DO NOT reply to my definition on the NANOG list, else the NANOG police will get you. john brown speaking for me On Mon, Aug 26, 2002 at 06:07:46PM -0400, Barry Shein wrote: Point of Information: Every single purely technical approach to stopping spam has been a complete loser. I understand the old adage that when all you have is a hammer the whole world looks like a nail. And that all many people on this list have is a technical hammer, some ability to hack around with cisco access lists or similar, so they tend to hold out hope that some new access list formula might be the one that saves the day (or similar, don't quibble the example!) But spam is as much a socio-legal problem as a technical one which is why, I'd claim, it's been so completely resistant to all purely technical approaches thus far. What we need are technical solutions which help with concomitant socio-legal solutions. If you haven't noticed, the spammers are winning completely, the waters are rising rapidly. More and more legitimate-sounding companies and products are spamming, and by and large the public perception in the non-anointed* business community are coming to the conclusion that they receive all this spam so it must be a legitimate form of advertising. Let me throw out the following to show how blind the technical community has been: There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. (before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964) However, we expect lawmakers to recognize and define the problem and get it right when the engineers who understand the technology and problem, in nearly a decade of whining, can't even be bothered to provide them with robust definitions of what it is the whining is about. Food for thought, that's all. But, personally, I'm hesitant to spend my time trying to study the merits of yet another anti-spam miracle cure, even if it seems at first glance (like so many before) that it might foil some particular flavor of spam which has been prevalent in the past. Now, after sitting through this extended, multi-day discussion of spam someone can send me the standard discussion of spam is not a subject for nanog! because I'm not a member of the amen crowd. * non-anointed: not a member of the technical community hence indoctrinated into a particular ethical view of what's right and wrong on the net. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
