Re: High volume WHOIS queries
How about caching the data from previous ARIN whois lookups? I do agree that the bulk data and high volume limitations on whois servers are silly... -joe On 2/28/05 1:30 PM, Dan Lockwood [EMAIL PROTECTED] wrote: I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to just make sense that you would do the processing using local data. That is all fine and good, but the problem comes when I distribute the software to users. ARIN's AUP for bulk whois states: Redistributing bulk ARIN WHOIS data is explicitly forbidden. It is permissible to publish the data on an individual query or small number of queries at a time basis, as long as reasonable precautions are taken to prevent automated querying by database harvesters. My original AUP application stated that I would transfer the data to the users using an XML file on a regular basis. Clearly in violation of the first point. Fine. But now after a phone conversation they are telling me that I can not operate a server to distribute the data on a per query basis too. Providing a server that answers whois queries just like ARIN seems to be clearly permissible based on the remaining AUP verbage. At this point the only thing I can get out of the guy/gal on the phone is NO!. Does anyone have any experience doing something like this? How about a sanity check? Am I completely wrong in how I'm interpreting the AUP? Thanks, Dan -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-213-1302 Cell: 650-207-0372 Fax: 650-969-2124
Re: High volume WHOIS queries
altho arguably its not up to arin to provide processing power for all these deployments. if you can get a local copy why not have your clients resolve back to that? Steve On Tue, 1 Mar 2005, joe mcguckin wrote: How about caching the data from previous ARIN whois lookups? I do agree that the bulk data and high volume limitations on whois servers are silly... -joe On 2/28/05 1:30 PM, Dan Lockwood [EMAIL PROTECTED] wrote: I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to just make sense that you would do the processing using local data. That is all fine and good, but the problem comes when I distribute the software to users. ARIN's AUP for bulk whois states: Redistributing bulk ARIN WHOIS data is explicitly forbidden. It is permissible to publish the data on an individual query or small number of queries at a time basis, as long as reasonable precautions are taken to prevent automated querying by database harvesters. My original AUP application stated that I would transfer the data to the users using an XML file on a regular basis. Clearly in violation of the first point. Fine. But now after a phone conversation they are telling me that I can not operate a server to distribute the data on a per query basis too. Providing a server that answers whois queries just like ARIN seems to be clearly permissible based on the remaining AUP verbage. At this point the only thing I can get out of the guy/gal on the phone is NO!. Does anyone have any experience doing something like this? How about a sanity check? Am I completely wrong in how I'm interpreting the AUP? Thanks, Dan
Re: High volume WHOIS queries
- Original Message - From: Stephen J. Wilcox [EMAIL PROTECTED] To: joe mcguckin [EMAIL PROTECTED] Cc: Dan Lockwood [EMAIL PROTECTED]; NANOG nanog@merit.edu Sent: Tuesday, March 01, 2005 4:53 AM Subject: Re: High volume WHOIS queries altho arguably its not up to arin to provide processing power for all these deployments. if you can get a local copy why not have your clients resolve back to that? that is the point of his post actually - arin told him that he can't do that without pointing out where this is prohibited in the aup. i can see their point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. perhaps asking arin if they would consent to you running a server open to registered users of your app behind authentication of some sort is worth a try? -p --- paul galynin
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone. Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model. The BGP peering model evolved over many years of people hashing out and modifying many bilateral peering agreements. I don't think we need to do this with email, because we the larger email providers can all sit down and together and based on the BGP experience, they can come up with a standard multilateral agreement that will suit most people. Or, more likely, two multilateral agreements. One for members of the email peering core, and the other for non-core operators. The reason this needs to be done in an association, in public, is because email is not BGP. BGP is an arcane piece of technology which does an arcane job in interconnecting networks. There is no significant public interest in BGP. Email, on the other hand, is an end user service and it is abundantly clear that the end users of the world are FED UP with the inability of Internet email providers to maintain and improve the quality of the service. Every year for the past 10 years the quality of Internet email has degraded. And while other services like instant messaging can take up some of the slack, they cannot fully replace a store and foreward email system. But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry. If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). There you go again, just like everyone else. You assume that the problem is somebody else and we just need to shoot that somebody else with big guns. Well, I have news for you. I HAVE SEEN THE ENEMY AND HE IS US! The problem is a fundamental shoddiness in the email services architecture which is compounded by a fundamental shoddiness in email service operations. Bandaid solutions abound. The whole thing is made out of bits of string and sealing wax. I recommend that you read Dave Crocker's draft on Internet email architecture. http://www.bbiw.net/specifications/draft-crocker-email-arch-03.html In order to understand what I am getting at you have to begin looking at the problem from a high level, not down in the greasy gearboxes. Dave's draft can be a bit inscrutable, but he is at least trying to document the overall architecture so that we can talk clearly about how to manage it in a way that provides a high quality email service to the end user. --Michael Dillon
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model. I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers. pgpLEkmUpjKFW.pgp Description: PGP signature
Re: Internet Email Services Association ( wasRE: Why do so few mail providers su
On Tue, Mar 01, 2005 at 05:44:26AM -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 27 lines which said: I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers. The agenda of the people who praise email peering is probably to change that. Should anyone be allowed to operate an email system? Perhaps not. AOL postmaster Carl Hutzler http://www.circleid.com/article/917_0_1_0_C/
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model. I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers. Well the way that I see this scaling is that you have a core of email service providers who are members of the Internet Mail Services Association. These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators. The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers. They essentially relay their email through a core provider, or possibly, they use some credential provided by their peer in the core to connect directly to other core members. The key thing here is that there is some kind of contractual agreement between the second tier and the core members. If the second tier breaks the agreement, their email flow is summarily cut off. You can do that with contracts. The mechanism for email transport and authentication is something that other people can work out. I know that relaying will work, but may not scale. However there are ways around this by separating the credentials/authentication from the mail flow. For instance, the 2nd tier provider connects to his peer in the core (CORE A) and asks for a credential to send mail to another core member (CORE B). CORE A hands him a magic cookie. He connects to CORE B and hands over the cookie. CORE B validates that this is a legitimate credential from CORE A. Email flows. And then there is the last layer which I call the end user. Of course this includes many organizations as well as individuals. It could even include someone who hosts mailing lists, i.e. someone who sources large volumes of mail. These people never talk to the core providers and submit all their email to a 2nd tier provider through the authenticated submission port. This group is the most important group because the entire system exists to serve their needs. Note that a large provider like AOL would be both a core email services provider and a 2nd tier provider at the same time. The 2nd tier deals with end users. In fact, AOL will also be an end user as will every other company. It is more useful to think of the functionality here rather than trying to map specific companies into a specific layer. I think that most people will agree that the architecture that I have described stands a good chance of scaling to a global level. And if there are some scaling issues that arise, they should be able to be solved within the core, i.e. the group with multilateral email peering agreements. They may decide to put some hierarchy within the core to match up with geography on a broad scale. --Michael Dillon
Re: AOL scomp
On Thu 24 Feb 2005 (12:40 -0500), [EMAIL PROTECTED] wrote: On Thu, 24 Feb 2005 12:28:58 EST, Matt Taber said: It's too bad that about 1/3 of the reported mails are valid opt-in lists. Proof that any network management or security or anti-spam scheme that implies end users with functional neurons is doomed from the get-go. I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. -- Jim Segrave [EMAIL PROTECTED]
RE: High volume WHOIS queries
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul G Sent: Tuesday, March 01, 2005 5:03 AM To: nanog@merit.edu Subject: Re: High volume WHOIS queries - Original Message - From: Stephen J. Wilcox [EMAIL PROTECTED] To: joe mcguckin [EMAIL PROTECTED] Cc: Dan Lockwood [EMAIL PROTECTED]; NANOG nanog@merit.edu Sent: Tuesday, March 01, 2005 4:53 AM Subject: Re: High volume WHOIS queries altho arguably its not up to arin to provide processing power for all these deployments. if you can get a local copy why not have your clients resolve back to that? that is the point of his post actually - arin told him that he can't do that without pointing out where this is prohibited in the aup. i can see their point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. -M
Re: Why do so few mail providers support Port 587?
On Mon, Feb 28, 2005 at 05:13:35PM -0500, [EMAIL PROTECTED] wrote: On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said: An interesting theory. What is the substantial difference? For me the security implications of allowing the user to bypass our mailsystem on port 25 and allowing the user to bypass our mailsystem on port 587 are not as obvious as they maybe are to you. The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 should be authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server. Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. If you're managing a corporate network, then yes, the distinction isn't that obvious, as you're restricting your own users. If you're running an ISP, you're being paid to *connect* people to other places, and making it more difficult than necessary is.. well... a Randy Bush quote. ;) I agree. Just as I said: If the ISP blocks (and I do not care which port he blocks), then it's time to go and look for another ISP. If I buy Internet I do not want a provider that decides for me which parts of it I am allowed to use today and which I am not. Wehret den Anfaengen is the german saying, I currently cannot find a good translation for. Nils
Re: High volume WHOIS queries
- Original Message - From: Hannigan, Martin [EMAIL PROTECTED] To: Paul G [EMAIL PROTECTED]; nanog@merit.edu Sent: Tuesday, March 01, 2005 9:17 AM Subject: RE: High volume WHOIS queries -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul G Sent: Tuesday, March 01, 2005 5:03 AM To: nanog@merit.edu Subject: Re: High volume WHOIS queries --- snip --- point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. well, the OP quoted a portion of the aup that requires bulk whois data recipients to take measures to prevent harvesting, so i presume that arin does care about that and, in fact, that consideration is likely the reason they declined to permit the OP to run *his own* whoisd off of his *local* copy of the data. -p --- paul galynin
Re: Why do so few mail providers support Port 587?
On Tue, Mar 01, 2005 at 09:18:19AM -0500, Nils Ketelsen wrote: 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. Here in Belgium, the two biggest end-user (broadband) ISPs block tcp/25. Are you going to tell your users: sorry, you should have taken another another access isp, take one of the very few ones left that don't block? Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: AOL scomp
At 08:17 AM 3/1/2005, Jim Segrave wrote: On Thu 24 Feb 2005 (12:40 -0500), [EMAIL PROTECTED] wrote: On Thu, 24 Feb 2005 12:28:58 EST, Matt Taber said: It's too bad that about 1/3 of the reported mails are valid opt-in lists. Proof that any network management or security or anti-spam scheme that implies end users with functional neurons is doomed from the get-go. I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. I can attest that we do not see the same here as you are seeing (1 in 100). I'd agree more with the 1/3 being stupid AOL users reporting regular messages that were either forwarded from their own account that we host to their AOL account or mailing lists that they signed up for as spam. In fact, I read an interesting email last night that was from AOL scomp because someone with an AOL email address was tired of arguing with someone else they know via email so they just reported it as spam... not realizing that we get a copy of it and are now privy to a personal feud among family members or friends. sigh The majority of them though, are messages from lists that they signed up for themselves and don't understand how to get off the list (despite the fact it's written at the bottom of every message to the list with a link). If you run some high volume lists you'll start seeing dumb reports from AOL scomp. My impression is that many AOL users think that feature is for deleting mail. I've not seen AOL software in years, but maybe if AOL put some sort of warning when they submit these messages... Maybe it's just the user base @ AOL that our mail servers deal with. :) Otherwise, I think that it can be helpful in identifying issues. Just my $0.02. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain
Send-Safe spam tool gang evicted by MCI...
The Register is reporting that: US telco MCI Worldcom has caved in to mounting pressure and booted a site that sells spamming software off its network. http://www.theregister.co.uk/2005/03/01/send-safe_evicted/ - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
On Tue, Mar 01, 2005 at 03:25:39PM +0100, Frank Louwers wrote: On Tue, Mar 01, 2005 at 09:18:19AM -0500, Nils Ketelsen wrote: 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. Here in Belgium, the two biggest end-user (broadband) ISPs block tcp/25. Are you going to tell your users: sorry, you should have taken another another access isp, take one of the very few ones left that don't block? I am in the lucky situation, where I decide, which providers my users get. Nils
RE: High volume WHOIS queries
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul G Sent: Tuesday, March 01, 2005 9:22 AM To: nanog@merit.edu Subject: Re: High volume WHOIS queries - Original Message - From: Hannigan, Martin [EMAIL PROTECTED] To: Paul G [EMAIL PROTECTED]; nanog@merit.edu Sent: Tuesday, March 01, 2005 9:17 AM Subject: RE: High volume WHOIS queries -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul G Sent: Tuesday, March 01, 2005 5:03 AM To: nanog@merit.edu Subject: Re: High volume WHOIS queries --- snip --- point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. well, the OP quoted a portion of the aup that requires bulk whois data recipients to take measures to prevent harvesting, so i presume that arin does care about that and, in fact, that consideration is likely the reason they declined to permit the OP to run *his own* whoisd off of his *local* copy of the data. The AUP also says for internet operational or research purposes only. Maybe they don't consider the use to fit in the defintion? There's an easier fix, IMO. Run a two stage query, 50 and 50, and then append the second 50 to the bottom of the first. -M -M
Re: Why do so few mail providers support Port 587?
On Tue, 01 Mar 2005 09:18:19 EST, Nils Ketelsen said: 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. That's not when you need a port 587 server... Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. Port 587 is for when you take your laptop along to visit your grandparents, and they have cablemodem from an ISP that blocks port 25. Now which do you do: 1) Whine at your grandparents about their choice of ISP? 2) Not send the mail you needed to send? 3) Make a long-distance (possibly international-rates) call to your ISP's dialup pool? 4) Send it back to your own ISP's 587 server and be happy? (Hint - there's probably a good-sized niche market in offering business-class mailhosting for people stuck behind port-25 blocks - they submit via 587/STARTTLS and retrieve via POP/IMAP over SSL). pgpxsNoXNRLZd.pgp Description: PGP signature
Re: High volume WHOIS queries
On Tue, 1 Mar 2005, Paul G wrote: point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. well, the OP quoted a portion of the aup that requires bulk whois data recipients to take measures to prevent harvesting, so i presume that arin does care about that and, in fact, that consideration is likely the reason they declined to permit the OP to run *his own* whoisd off of his *local* copy of the data. If memory serves, that restriction didn't appear until spam became a problem. The verbiage in the AUP is there to give ARIN recourse in the event that some spammer, and it has happened, runs a harvest against domain names or serialized NIC handles to seed a spam source. - billn
Re: Why do so few mail providers support Port 587?
On Tue, 1 Mar 2005 09:18:19 -0500, Nils Ketelsen [EMAIL PROTECTED] wrote: Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. I think you're right here.. There are a number of us who will endeavor to do it the right way, and then there are others who will either not have the technical know-how, or just plain don't care.. 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. For a commercial service, I agree. Commercial users are deemed more intelligent and should have the capability to set up services in a more secure manner. Residential users, however, are the general problem. Your average Joe User has no idea how email works other than merely clicking the send button and having the email appear magically at the other end. Most users don't have spyware or virus checkers either. All of this leads to a large group of general users who can be exploited and abused at-will. As an ISP, I find it necessary to block certain ports. I block port 25 outbound from my residential customers to prevent direct-to-mx spamming. Currently they can only use port 25 on my mailserver, but that will eventually change to only port 587 and port 25 will be completely blocked. I also block netbios and other similar services which were never intended as WAN protocols in the first place. And I haven't had a single complaint from any of my residential customers. I'm fairly confident that they're mostly unaware of these blocks even though they were announced in advance.. I agree. Just as I said: If the ISP blocks (and I do not care which port he blocks), then it's time to go and look for another ISP. If I buy Internet I do not want a provider that decides for me which parts of it I am allowed to use today and which I am not. You would be one of the smarter Joe Users who can handle the day-to-day nasties on the internet. Unfortunately, you're the minority... I wouldn't mind having an alternate service, with no change in pricing, that would allow users like you to have the freedom they want. In fact, if I had any demand for it at all, I'd set something up in a heartbeat. Wehret den Anfaengen is the german saying, I currently cannot find a good translation for. Nils -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
On Tue, 01 Mar 2005 09:36:35 EST, Nils Ketelsen said: I am in the lucky situation, where I decide, which providers my users get. Even when they're travelling? That's quite the Big-Brother operation you have ;) pgpkWGlqiZzuB.pgp Description: PGP signature
Re: AOL scomp
Once upon a time, Jim Segrave [EMAIL PROTECTED] said: I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. It is almost the reverse for us; a small number of valid complaints in a sea of false complaints. I've seen account info, half of private conversations (and I do mean private), hotel reservations, and more reported as spam on a regular basis. I also get complaints about confirmed opt-in mailing lists (majordomo and/or mailman lists with unsubscribe info at the bottom of each message) that the user apparently thinks the Spam button is the same as unsubscribe. That does not scale up; the whole point of using mailing list software is that so the mail server admin doesn't have to manually process subscribe/unsubscribe lists. Our mailing lists are set up to bulk mail (i.e. one message with multiple recipients), so since AOL filters out the complaining address, I can't manually unsubscribe those users. I haven't seen the AOL interface myself, but I've read that the Spam button is next to or near the Delete button, leading to mis-clicks. Even if that isn't so, there are definately a significant number of users that use the buttons interchangeably. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Internet Email Services Association
[EMAIL PROTECTED] wrote: | The key thing here is that there is some kind of contractual agreement | between the second tier and the core members. If the second tier breaks | the agreement, their email flow is summarily cut off. You can do that | with contracts. Yup. As you've mentioned, we already have a mechanism for peering between providers - it's called BGP. Is it too much to ask for BGP peering contracts to include requirements to deal with abuse ?
Re: Why do so few mail providers support Port 587?
Speaking on Deep Background, the Press Secretary whispered: Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. Well, is authenticated SMTP 587 going to be worse than open port 25? I doubt it, but... In fact, I think most folks will do way better. Call that blind faith in the inhabitants of Middle Earth ^H^H^H NANOG 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. So you will choose hotels, conferences, etc, by whether or not they block 25? And coming soon.. airlines! That's right: aisle seat, low-sodium meal and NO port 25 blocking... I do well to find out if the above has access at all, esp. if dealing through a reseller [hotels.com, etc]. -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
[off-list] Re: High volume WHOIS queries
On Tue, Mar 01, 2005 at 09:17:48AM -0500, Hannigan, Martin wrote: I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. Understood. So why not make it easy -- both for yourselves and for everyone else? Just publish all WHOIS data on static web pages -- not even marked up with HTML, just plain ASCII text -- whose URLs are easy to construct, a la www.verisign.com/foo/bar/blah/example1.com www.verisign.com/foo/bar/blah/example2.net and refresh them from backing store whenever the real data changes. (And yes, I realize I'm using an example based on domains, not networks, but I trust it's still applicable.) This makes the load on the servers about as small as it's going to get. (Heck, they could be served from a cut-down web server designed to serve static content only.) It also makes it trivially easy for people to look things up without worrying about rate-limiting. Heck, once the search engines indexed it, it'd be even easier. As to ...then the spammers will mass-harvest it...: they already HAVE. They're busy selling it to each other on CD/DVD and via other means. This has been going on for years, and however-they're-doing-it, they're doing it well enough to acquire recently-modified data. So that toothpaste is completely out of the tube and there's no way to put it back in. I don't think any substantive purpose is served by pretending/wishing that it's otherwise: there's a demand for this data, and plenty of money to be made by those who will supply it, therefore it's going to be acquired and sold. But the people who *can't* access the data -- not without taking measures to evade the rate-blocking that's in place -- are abuse victims who are trying to track down those responsible. So I view the problem of overload on WHOIS servers as self-inflicted damage, easily fixed by giving up the pretense that restricting access to the data has any real value for anyone. (Well, it *does* benefit those selling it, but I trust that ensuring their profits isn't a goal that anyone's particularly worried about. ;-) ) ---Rsk
Re: Multihoming for the small ISP ( search engine) ala 2005
On Mon, 28 Feb 2005, Geoff White wrote: 2) What is the preferred or correct way for a relatively small outfit (a small search engine) to implement Multihoming? Especially when most of the machines are a VLS cluster so we are not talking about a large address space here. It seems the outfit is having difficulty getting blocks that they can even run BGP with, (I know I'm missing a lot here) They can't even fill a /24, let alone anything greater :) As long as they have a /24 that they can announce, two or more upstreams that are able and willing to establish BGP sessions with them and a router with enough memory to hold at least 2 full views (for a Cisco, you probably want 256MB or more these days), they can multi (or dual) home. I don't think Verio, Sprint or any other major ISP is filtering out /24s from any part of IP4 any more. I don't think there are many ISPs willing to establish BGP sessions for customers that aren't spending at least T1 prices with them. Verizon is going to be rolling out cheap, multimegabyte fiber connections to business and residential customers around here soon. Since I'm paying ~$2k/mo for 2 T1s (with longish loops and a /21), it's tempting to see if I could get ahold of somebody over there willing to talk about BGP :) James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Why do so few mail providers support Port 587?
On Tue, 1 Mar 2005 [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 09:18:19 EST, Nils Ketelsen said: 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. That's not when you need a port 587 server... Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. Port 587 is for when you take your laptop along to visit your grandparents, and they have cablemodem from an ISP that blocks port 25. Now which do you do: 1) Whine at your grandparents about their choice of ISP? 2) Not send the mail you needed to send? 3) Make a long-distance (possibly international-rates) call to your ISP's dialup pool? 4) Send it back to your own ISP's 587 server and be happy? E) Log into the webmail service my ISP provides. Opening another port can too easily turn into a whack-a-mole game between you, the spammers and ISPs. There are myriad ways to allow roaming/emergency E-mail activities. Let's not get pigeon-holed here. Finally, after a week or so of reading this thread, I'm inclined to believe it's officially a holy war. Nobody's changing anybody's minds here it seems. It's two stationary camps arguing. Can it stop now? --Gar (Hint - there's probably a good-sized niche market in offering business-class mailhosting for people stuck behind port-25 blocks - they submit via 587/STARTTLS and retrieve via POP/IMAP over SSL).
Re: Multihoming for the small ISP ( search engine) ala 2005
As long as they have a /24 that they can announce, two or more upstreams that are able and willing to establish BGP sessions with them and a router with enough memory to hold at least 2 full views (for a Cisco, you probably want 256MB or more these days), they can multi (or dual) home. They many not need anything near 2 full tables. A default plus providers own and customer routes could do, and would require less memory/smaller router. James H. Edwards Routing and Security Administrator At the Santa Fe Office: Internet at Cyber Mesa [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cybermesa.com/ContactCM (505) 795-7101
Re: Internet Email Services Association
| The key thing here is that there is some kind of contractual agreement | between the second tier and the core members. If the second tier breaks | the agreement, their email flow is summarily cut off. You can do that | with contracts. Yup. As you've mentioned, we already have a mechanism for peering between providers - it's called BGP. Is it too much to ask for BGP peering contracts to include requirements to deal with abuse ? Yes, I think that it is too much to ask for. Abuse has little to no impact on peering beyond minor traffic increments. Why should a BGP peering contract place a lot of importance on this? Certainly, BGP peering contracts do include some mention of abuse contacts and so on, but it is a side issue. However, when you consider email services, it is a different story. Whether it is abuse or whether it is shoddy email operations or whether it is misconfigured email server software, it WILL create major impacts on the quality of the email service. Most of this isn't even noticed by the NOC because they only care that packets flow smoothly. In order to improve the quality of Internet email service, we need more than the smooth flow of packets. We need the right packets in the right place at the right time, and only the right packets. --Michael Dillon
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
On Tue, 1 Mar 2005 [EMAIL PROTECTED] wrote: I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers. Well the way that I see this scaling is that you have a core of email service providers who are members of the Internet Mail Services Association. The business world simply doesn't work that way. Ever heard of the phrase Standards are great -- there's so many of them to choose from!? These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators. The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers. Contrary to what you said before, this *IS* the UUCP model in a nutshell. It has been done before, it does not scale, and it does not fit the way business works today. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Heads up: Long AS-sets announced in the next few days
Hi, as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654. We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them. The proposed timetable of the test announcements is as follows. 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal and, if there are no problems: 2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively. For questions/comments, please contact [EMAIL PROTECTED] or [EMAIL PROTECTED] Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group [1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html
Re: Why do so few mail providers support Port 587?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nils Ketelsen wrote: On Mon, Feb 28, 2005 at 05:13:35PM -0500, [EMAIL PROTECTED] wrote: On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said: An interesting theory. What is the substantial difference? For me the security implications of allowing the user to bypass our mailsystem on port 25 and allowing the user to bypass our mailsystem on port 587 are not as obvious as they maybe are to you. The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 should be authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server. Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. I truly hope this isn't the case, I don't trust any mail server that I didn't personally configure. 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner. Chris - -- Chris Horry KG4TSM You're original, with your own path [EMAIL PROTECTED] You're original, got your own way PGP: DSA/2B4C654E-- Leftfield -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJM9FnAAeGCtMZU4RAvsFAKC5SvTVLS2VffMq2rcp7ZZZt4IGVwCgqbHO 2mSmy8GWV+l3xEzFsBBXp1o= =0wKT -END PGP SIGNATURE-
Re: Why do so few mail providers support Port 587?
Chris Horry wrote: Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner. I completely agree, which is why if alternative SMTP injection ports are being used, some measure of authentication be used to authorize (or, in case of abuse, block) access. It isn't the magic bullet, and won't work forever, but in regards to the mail systems I maintain, it will do for now. -- Stephen Fulton.
Re: Why do so few mail providers support Port 587?
Speaking on Deep Background, the Press Secretary whispered: Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner. Chris Well, I'm no player in this league and ask... Why will ISP's wise up and block 587? If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...) If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS. In either case, why will the clued ISP's want to block 587? -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Why do so few mail providers support Port 587?
On Tue, 2005-03-01 at 15:55 -0500, David Lesher wrote: In either case, why will the clued ISP's want to block 587? It's not the clueful ISPs that you need worry about. -Jim P.
[ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05)]
perhaps more relevant to nanog-futures list but i'll assume everyone cares. k - Forwarded message from Bob Braden [EMAIL PROTECTED] - Date: Mon, 28 Feb 2005 08:50:30 -0800 (PST) From: Bob Braden [EMAIL PROTECTED] Subject: [e2e] ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) To: [EMAIL PROTECTED] --- Call for papers ** ** * SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) * ** * (to be held with SIGCOMM 2005, Aug 20-26, Philadelphia, USA) * ** * http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html * ** Today's IP networks are extensively instrumented for collecting a wealth of information including traffic traces (e.g., packet or flow level traces), control (e.g., router forwarding tables, BGP and OSPF updates), and management (e.g., alarms, SNMP traps) data. The real challenge is to process and analyze this vast amount of primarily unstructured information and extract structures, relationships, and higher level knowledge embedded in it and use it to aid network management and operations. The goal of this one day workshop is to explore new directions in network data collection, storage, and analysis techniques, and their application to network monitoring, management, and remediation. The workshop will provide a venue for researchers and practitioners from different backgrounds, including networking, data mining, machine learning, and statistics, to get together and collaboratively approach this problem from their respective vantage points. We are soliciting original/position papers on topics (including, but not limited to) listed below. - Collection, storage access infrastructure: platform instrumentation (e.g. multi-modal, multi-resolution sensors), collection techniques (e.g. event sampling, filtering, aggregation, etc.), storage and access (e.g. retention policy, indexing techniques etc.). - Network data analytics techniques tools: network stream mining, network graph mining, micro-clustering, temporal and statistical correlation, causality tracking, machine learning. - Applications to network operations management: network problem determination, network reliability and performance, root-cause analysis, security, emerging phenomenon detection (e.g. DDoS, virus/worm, spam etc.), traffic classification. Of particular interest are (i) new solution techniques as well as applications of existing techniques from data mining, machine learning and statistics to IP network problems, (ii) experiences with the use of such techniques for IP networks, and (iii) open networking problems and challenges that would benefit from the use of such techniques. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Submission Instructions --- Papers should be at most 6 pages long, in standard ACM format (single-spaced, double column, at least 10pt font). Accepted papers will appear in the workshop proceedings. Authors of accepted papers are expected to present their work at the workshop. Detailed submission guidelines will be available soon at http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html. Important Dates --- Submission Deadline: Wed, April 6, 2005, 9.00 PM EST Notification Deadline: May 10, 2005 Camera Ready Deadline: May 30, 2005 Workshop Date: Aug 26, 2005 Workshop Organizing Chairs -- Subhabrata Sen, ATT Research Chuanyi Ji, Georgia Tech Debanjan Saha, IBM Research Joe McCloskey, Dept. of Defense Technical Program Committee Constantinos Dovrolis, Georgia Tech. Chuanyi Ji, Georgia Tech. Nick Koudas, Univ. of Toronto Vipin Kumar, Univ. of Minnesota Joe McCloskey, Dept. of Defense Robert Novak, Univ. of Wisconsin-Madison Rajeev Rastogi, Lucent Bell Labs John Reumann, IBM Research Jennifer Rexford, Princeton Univ. Mathew Roughan, Univ. of Adelaide Debanjan Saha, IBM Research Subhabrata Sen, ATT Research William Szewczyk, Dept. of Defense Walter Willinger, ATT Research Zhi-Li Zhang, Univ. of Minnesota - End Included Message - - End forwarded message -
Re: Why do so few mail providers support Port 587?
On 03/01/05, David Lesher [EMAIL PROTECTED] wrote: Well, I'm no player in this league and ask... Why will ISP's wise up and block 587? If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...) If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS. In either case, why will the clued ISP's want to block 587? I think the anti-587 logic here seems to be that we (we being the Internet community at large) shouldn't encourage anyone to ever act more responsibly than the worst operator because that worst operator will continue to be irresponsible. (I am only translating, not agreeing.) In any case, nobody has expressed any new ideas around this topic for about a week, so I'd suggest we let it drop before somebody mis-represents Godwin's Law. -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: High volume WHOIS queries
On 2/28/05 1:30 PM, Dan Lockwood [EMAIL PROTECTED] wrote: I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to just make sense that you would do the processing using local data. Not exactly what you are looking for, but how about ftp://ftp.arin.net/info/asn.txt Lists AS number, the whois AS name, and POC handle for each AS. Jeff -- Jeff Bartig | University of Wisconsin - Madison [EMAIL PROTECTED] | Division of Information Technology (608) 262-8336 | Network Services/WAN Engineering
Re: High volume WHOIS queries
On Tue, 2005-03-01 at 16:40 -0600, Jeff Bartig wrote: On 2/28/05 1:30 PM, Dan Lockwood [EMAIL PROTECTED] wrote: I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to just make sense that you would do the processing using local data. Not exactly what you are looking for, but how about ftp://ftp.arin.net/info/asn.txt Lists AS number, the whois AS name, and POC handle for each AS. Jeff If you are also interested in AS info outside the ARIN region, the following file may be of interest -- http://bgp.potaroo.net/as1221/asnames.txt -Larry
Re: Why do so few mail providers support Port 587?
J.D. Falk wrote: On 03/01/05, David Lesher [EMAIL PROTECTED] wrote: Well, I'm no player in this league and ask... Why will ISP's wise up and block 587? If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...) Exactly. If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS. Ditto. In either case, why will the clued ISP's want to block 587? It makes no sense for clued ISPs to block 587. That 587 should be provisioned for unauthorized connections, or that clued ISPs should block 587 are both suggestions that make no sense. I think the anti-587 logic here seems to be that we (we being the Internet community at large) shouldn't encourage anyone to ever act more responsibly than the worst operator because that worst operator will continue to be irresponsible. (I am only translating, not agreeing.) I'm not sure that I agree with this translation. I don't see *any* logic, just FUD as an excuse for failing to become educated about which problems 587 can help solve, the reduced problems that will exist when 587 is properly implemented by most networks, learning how easy it is to properly implement 587, educating your users about the benefits of using 587, etc. We saw all these same types of arguments (arguments due to implementation ignorance and fear of the support costs)10 years ago when we were trying to get networks to close open relays. In any case, nobody has expressed any new ideas around this topic for about a week, so I'd suggest we let it drop before somebody mis-represents Godwin's Law. Or take this topic to spam-l - where I feel it belonged in the first place. jc
Fwd: Impending publication: draft-iab-dns-assumptions-02.txt
Of imminent interest to the operations community FYI, - ferg -- Forwarded Message -- The IAB is ready to ask the RFC-Editor to publish What's in a Name: False Assumptions about DNS Names draft-iab-dns-assumptions-02 as an Informational RFC. This document reviews the potential assumptions that may be made based on domain names, as well as the potential implications (and pitfalls) of those assumptions. The IAB solicits comments by March 29, 2005. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-assumptions-02.txt From the Abstract: The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, URIs, and other application layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. A danger of this trend is that the humans and automata which consume and use these identifiers will make assumptions about the services that are or should be provided by the hosts associated with these identifiers. This document discusses this problem in more detail and makes recommendations on how it can be avoided. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
not operationally relevant until it's used in the wild
but in the interest of full and early disclosure, etc k - Forwarded message from k claffy [EMAIL PROTECTED] - Date: Tue, 1 Mar 2005 17:34:27 -0800 From: k claffy [EMAIL PROTECTED] Subject: [Caida] yoshi's study on remote physical device fingerprinting To: [EMAIL PROTECTED] Cc: Tadayoshi Kohno [EMAIL PROTECTED] Yoshi Kohno (doctoral student in UCSD's CSE program) just released an eye-opening paper demonstrating methods for remotely fingerprinting a physical device without any modification to or known cooperation from the fingerprintee. At a high level, these techniques exploit microscopic deviations in device hardware: clock skews. Specifically, they exploit the fact that most modern TCP stacks implement the TCP Timestamps Option (RFC 1323). When this option is enabled, outgoing TCPs packets leak information about the sender's clock. Yoshi's results further confirm a fundamental reason why securing real-world systems is so difficult: it is possible to extract security-relevant signals from data canonically considered to be noise. The equally disturbing corrolary is that there remain fundamental properties of networks that we have yet to integrate into our security models. please don't forward to any bad guys. /cough k paper and abstract available here: === http://www.cse.ucsd.edu/users/tkohno/papers/PDF/ [mirror site] http://www.caida.org/outreach/papers/2005/fingerprinting/ Our abstract: We introduce the area of remote physical device fingerprinting, or fingerprinting a physical device, as opposed to an operating system or class of devices, remotely, and without the fingerprinted device's known cooperation. We accomplish this goal by exploiting small, microscopic deviations in device hardware: clock skews. Our techniques do not require any modification to the fingerprinted devices. Our techniques report consistent measurements when the measurer is thousands of miles, multiple hops, and tens of milliseconds away from the fingerprinted device, and when the fingerprinted device is connected to the Internet from different locations and via different access technologies. Further, one can apply our passive and semi-passive techniques when the fingerprinted device is behind a NAT or firewall, and also when the device's system time is maintained via NTP or SNTP. One can use our techniques to obtain information about whether two devices on the Internet, possibly shifted in time or IP addresses, are actually the same physical device. Example applications include: computer forensics; tracking, with some probability, a physical device as it connects to the Internet from different public access points; counting the number of devices behind a NAT even when the devices use constant or random IP IDs; remotely probing a block of addresses to determine if the addresses correspond to virtual hosts, e.g., as part of a virtual honeynet; and unanonymizing anonymized network traces. ___ Caida mailing list [EMAIL PROTECTED] http://rommie.caida.org/mailman/listinfo/caida - End forwarded message -
Re: Heads up: Long AS-sets announced in the next few days
On Wed, Mar 02, 2005 at 01:27:31AM +, James A. T. Rice wrote: What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away: route-map peers-in deny 5 match as-path 109 AS-Sets, not AS-Paths... Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Is there anything more to say on this subject? (was RE: Why do so few mail providers support Port 587?)
I've seen this thread go on for quite a while, and have been getting lots of when are you going to shut that thread down? types of queries. While not particularly off-topic, a lot of the responses do look pretty repetative. Therefore, I'd like to suggest that, unless you have something to say on this topic that hasn't already been said by somebody else, somewhere in this thread, and that's so important that the thousands of people on the NANOG list will want to see it, this thread should be brought to an end. This isn't a threat of censorship. It's a request for self control. -Steve Speaking for myself; not for the rest of the list administrators On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote: It's time to take this thread to SPAM-L or some other spam oriented list. I strongly disagree. This thread has not been about spam. For the most part it has dealt with technical operational issues of email services and therefore it is right on track for this list. --Michael Dillon Steve Gibbard [EMAIL PROTECTED] +1 415 717-7842 (cell) http://www.gibbard.org/~scg +1 510 528-1035 (home)
Re: AOL scomp
On March 1, 2005 at 14:17 [EMAIL PROTECTED] (Jim Segrave) wrote: I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. Here about 99% are not valid or interesting. Which is to say, I had one small burst once caused by an infected customer machine which we got shut off fast and fixed. The rest are virtually all just people on mailing lists hosted here sending each and every completely on-topic posting to TOS. I suppose I should figure out some way to track them so I can boot them off those lists since AOL removes all identifying information. -- -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: AOL scomp
Barry Shein wrote: On March 1, 2005 at 14:17 [EMAIL PROTECTED] (Jim Segrave) wrote: I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. Here about 99% are not valid or interesting. Which is to say, I had one small burst once caused by an infected customer machine which we got shut off fast and fixed. The rest are virtually all just people on mailing lists hosted here sending each and every completely on-topic posting to TOS. I suppose I should figure out some way to track them so I can boot them off those lists since AOL removes all identifying information. Apparently the ratio of valid/invalid AOL notifications is a usefull indicator on the cleanliness of the relevant network. Some might suggest that large amounts of untrackable inaccurate complaints are themselves abuse.
Re: AOL scomp
It's too bad that about 1/3 of the reported mails are valid opt-in lists. I find it's a lot more than that, but my network is small and I know most of my users so the amount of spam we emit is tiny. Since my list mail is all VERPed and AOL only removes the address from the To line (they know it's silly, their lawyers made them do it), it took me only a few minutes to write a perl script that picks the list name, domain, and subscriber address out of the bounce address and reformats it into an unsubscribe message to mj2. Works great. Now I have a new problem of AOL users asking where their list mail went. Sigh. I tell them that if they want to resubscribe, they're welcome to do so, and when they hit the spam button again they'll be off the list again. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly.
Re: AOL scomp
On Tue, 01 Mar 2005 09:28:31 -0500, Vinny Abello [EMAIL PROTECTED] wrote: I can attest that we do not see the same here as you are seeing (1 in 100). I'd agree more with the 1/3 being stupid AOL users reporting regular messages that were either forwarded from their own account that we host to Well - there's a way out, sort of. 1. Route .forwarded email out a separate IP (besides cutting down on accepting and forwarding spam) or 2. Find some way - like an X-Forwarded-For header, that AOL can tag on. --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Internet Email Services Association ( wasRE: Why do so few mail providers su
On Tue, 1 Mar 2005 12:01:35 +0100, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: The agenda of the people who praise email peering is probably to change that. Should anyone be allowed to operate an email system? Perhaps not. AOL postmaster Carl Hutzler Where does that advocate email peering? As long as you have 1. A static IP 2. Reasonable technical competence (clue being such a rare beast) I dont see Carl, or anybody else, objecting Cue rants about how some people shouldnt be allowed to have root, enable or whatever on etch a sketches, let alone production machines. You've seen such people and so have I ... -- Suresh Ramasubramanian ([EMAIL PROTECTED])
