Re: your mail
At 12:32 AM 8/21/2002 -0400, David Lesher wrote: Unnamed Administration sources reported that N. Richard Solis said: If you haven't worked in an environment where you had to turn in your cellphone and pager at the front desk, show a badge to a camera around every corner, and get your office keys from a vending machine you dont know what real security looks like. You missed the places w/ real security. That's where the very polite Marine Security Guard with the 870 shotgun asks to see your badge again... Can we all stop talking shit for a moment? Real security is when nobody can talk about it. Regards, -- Martin Hannigan[EMAIL PROTECTED]
Re[2]: your mail
On Wed, 21 Aug 2002 00:32:24 -0400 (EDT) David Lesher [EMAIL PROTECTED] wrote: Unnamed Administration sources reported that N. Richard Solis said: If you haven't worked in an environment where you had to turn in your cellphone and pager at the front desk, show a badge to a camera around every corner, and get your office keys from a vending machine you dont know what real security looks like. You missed the places w/ real security. That's where the very polite Marine Security Guard with the 870 shotgun asks to see your badge again... or you're standing in the parking lot, and suddenly find yourself surrounded by men in suits carrying mac-10s. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security
RE: your mail
Who did you think held the cellphone and the pager? :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lesher Sent: Wednesday, August 21, 2002 12:32 AM To: nanog list Subject: Re: your mail Unnamed Administration sources reported that N. Richard Solis said: If you haven't worked in an environment where you had to turn in your cellphone and pager at the front desk, show a badge to a camera around every corner, and get your office keys from a vending machine you dont know what real security looks like. You missed the places w/ real security. That's where the very polite Marine Security Guard with the 870 shotgun asks to see your badge again... -- 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: Shared facilities (was Re: your mail)
Sean, For a lot of people, these locations are a place to store an entire web presence. That might include order information or private email or credit card records for an entire day's transactions. My feeling is that the general purpose of security at these locations is to make sure that no one is tampering with any equipment in any way, to include unauthorized removal. That was the point of my previous email. The connections to those machines and the data stored on them is what is of value in those locations, not the physical security of the people. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sean Donelan Sent: Wednesday, August 21, 2002 2:03 AM To: [EMAIL PROTECTED] Subject: Shared facilities (was Re: your mail) On Wed, 21 Aug 2002, David Lesher wrote: Unnamed Administration sources reported that N. Richard Solis said: If you haven't worked in an environment where you had to turn in your cellphone and pager at the front desk, show a badge to a camera around every corner, and get your office keys from a vending machine you dont know what real security looks like. You missed the places w/ real security. That's where the very polite Marine Security Guard with the 870 shotgun asks to see your badge again... Sigh, and in places with real security you rarely find enemies/competitors sitting in the same room. Exchange points are like the United Nations, not high security military bases. AMS-IX, Equinix, Linx/Telehouse, PAIX, etc provide a neutral facility for competitors to exchange network traffic. The facility operators provide a reasonable level of security, and try to keep the diplomats from punching each other. Its in all (most?) the competitors' self-interest to follow the rules. Let's not lose sight of the purpose of colocation/exchange points. If we start requiring you to be a US citizen and have top secret clearance in order to enter a colocation facility, we've probably decreased the usefulness of the exchange points.
Re: IETF SMTP Working Group Proposal at smtpng.org
what are the more basic problems you're trying to fix? I'd like to be able to publish DNS records announcing my domain's *outbound* mail servers, with nice abbreviated forms to say they're the same as my inbound (MX) records or any IP in x.y.z/24. Then cooperative ISPs (like say America Online) could refuse any email from my domain that originated from some random cable modem, instead of accepting it and then flooding me with 2 bounce messages. Spam? Yeh, but it would also help with things like KLEZ.
RE: IETF SMTP Working Group Proposal at smtpng.org
I'd like to be able to publish DNS records announcing my domain's *outbound* mail servers, with nice abbreviated forms to say they're the same as my inbound (MX) records or any IP in x.y.z/24. Then cooperative ISPs (like say America Online) could refuse any email from my domain that originated from some random cable modem, instead of accepting it and then flooding me with 2 bounce messages. It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. If the IP space is NOT SWIP, it would need to be registered by the customer ISP or via owners rwhois server. Just my $.02; for what it's worth -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] When all else fails, let a = 7. If that doesn't help, then read the manual.
Re: your mail
Sounds like a nuclear power plant I used to work at. Except the nuke plants don't trust the marines to do the job. They hire and train their own security teams. I had to go through more screening to work there than anything I've gone through re security clearances and the government. The scary thing is, (IMHO) the nuclear industry is being held up as the model for all other industries re security. Of course, there isn't the issue of many companies sharing one facility, which makes things far more interesting. A colo is no place for guns, imho. Jane David Lesher wrote: Unnamed Administration sources reported that N. Richard Solis said: If you haven't worked in an environment where you had to turn in your cellphone and pager at the front desk, show a badge to a camera around every corner, and get your office keys from a vending machine you dont know what real security looks like. You missed the places w/ real security. That's where the very polite Marine Security Guard with the 870 shotgun asks to see your badge again... -- 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: IETF SMTP Working Group Proposal at smtpng.org
On Wed, Aug 21, 2002 at 10:00:02AM -0400, [EMAIL PROTECTED] wrote: what are the more basic problems you're trying to fix? I'd like to be able to publish DNS records announcing my domain's *outbound* mail servers, with nice abbreviated forms to say they're the same as my inbound (MX) records or any IP in x.y.z/24. Then cooperative ISPs (like say America Online) could refuse any email from my domain that originated from some random cable modem, instead of accepting it and then flooding me with 2 bounce messages. What about this email from you which came to me from Merit and not your mail server? Would break mailing lists and listserves unless the from field is overwritten. -ron
Eliminating physical colocation (was Re: Shared facilities)
On Wed, 21 Aug 2002, Martin Hannigan wrote: Since Sept 11, my experience probably doesn't cut the mustard, but that's how it has been to this point. Consider the various public statements on colocation security. http://www.state.ma.us/dpu/catalog/6688.htm Verizon MA believes that the most effective means of ensuring network safety and reliability is to eliminate physical collocation entirely in all its COs, converting existing physical collocation arrangements to virtual and requiring that all future collocation arrangements be virtual only. Of course, this is a very different colocation model than used by companies such as Equinix. Just because they use the same terms doesn't make them the same thing.
Re: Eliminating physical colocation (was Re: Shared facilities)
LOL, heck of a way to make it so they never have to sell another unbundled network element. Mike. On Wed, 21 Aug 2002, Sean Donelan wrote: On Wed, 21 Aug 2002, Martin Hannigan wrote: Since Sept 11, my experience probably doesn't cut the mustard, but that's how it has been to this point. Consider the various public statements on colocation security. http://www.state.ma.us/dpu/catalog/6688.htm Verizon MA believes that the most effective means of ensuring network safety and reliability is to eliminate physical collocation entirely in all its COs, converting existing physical collocation arrangements to virtual and requiring that all future collocation arrangements be virtual only. Of course, this is a very different colocation model than used by companies such as Equinix. Just because they use the same terms doesn't make them the same thing. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
QWest internet the 1996 Telecom Act
[Searching the NANOG archives, I haven't found this topic yet] Can anyone confirm either of the following: -the 1996 Telecom Act restricts baby bells from exchanging internet traffic directly to each other. -that any other baby bell besides QWest is claiming this restriction. The new QWest addition to our internet feeds is restricted to their 14 state operating region. Traffic outside of the region has to traverse qwest.net, then tamerica.net, then uswest.net before it gets out. Personally, I do not see where in the 96TA restrictions apply to internet traffic - only to long distance. It feels to me they are using this to pressure FCC/PSC leadership. QWest's [271] filing to have 4 of their 14 states join long-distance suggests their 'regional' network will be getting even smaller. --- Andy Dalrymple XMission Telecom Mgr. (8/21/02)
Re: IETF SMTP Working Group Proposal at smtpng.org
Yo Avleen! On Wed, 21 Aug 2002, batz wrote: Spam is very much a security problem. Spam would not exist if both MUA's and MTA's had adequate policy enforcement features on them, so that users could set granular controls on what was allowed into their mailboxes. Nice try, but not close enough. Spam is a LEGAL problem. There are many cases where spammers negotiated a service contract with out anti-spamming clauses. Then when the ISP figures out they have a bulk spammer for a custmoer they can not shut down the spammer because the spammer gets a court order to enforce the service agreement. Same goes on the other side. Many BLs have been sued, AND LOST, for putting spammers on their BLs. Put those two together and no technical solution will fix the problem. If legislatures say Pi is equal to 3 then there is not much we can do to fix it except fight the legislature. 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
DNS entries for infrastructure equipment
Title: Message Does anyone have a resource that has recommendations about how to name interfaces in a DNS name space? Is there a standard that is used? TIA Dan Lockwood
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002, Gary E. Miller wrote: : Spam would not exist if both MUA's and MTA's had adequate policy : enforcement features on them, so that users could set granular : controls on what was allowed into their mailboxes. : :Nice try, but not close enough. : :Spam is a LEGAL problem. Actually, I'm bang on. :) It's not a legal problem, yet. The reason for this is that there is no legal definition of spam that is applicable outside a small number of jurisdictions. In fact, there is no single comprehensive definition of spam other than that its most consistent attribute, which is users inability to filter it without losing legitimate mail. Look at CAUCE, Brightmail, SpamAssassin. None of them provide a comprehensive definition of all spam, rather, they define it by some of its effects, or deal with it as a matter of heuristic scoring. By looking at its one unique attribute, we see that it is a direct leveraging/exploitation of the openness of the SMTP protocol and the culture of the Internet SMTP was designed to serve. That openness used to be the social contract of email, now it is simply a lack of enforcable policy and tools. :There are many cases where spammers negotiated a service contract with :out anti-spamming clauses. Then when the ISP figures out they have :a bulk spammer for a custmoer they can not shut down the spammer because :the spammer gets a court order to enforce the service agreement. Yes, but that does not give the end recipient any direct recourse, and also defines spam as a contract violation between an ISP and its client, and has no regard for the messages themselves. :Put those two together and no technical solution will fix the problem. Actually it will. The model that TMDA uses (whitelists and confirmed corespondant registration with the recipient) is partial example of a solution that will make all spam an explicit case of unauthorized access, which can then be a legal issue. One of the most basic principles of computer security is: No Policy = No Crime. Until users have adequate tools and protocol support to control of what comes into their mailboxes, there will be spam. Cheers, -- batz
RE: IETF SMTP Working Group Proposal at smtpng.org
Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Life would be much easier if I had the source code.
Re: DNS entries for infrastructure equipment
Dan Lockwood([EMAIL PROTECTED])@2002.08.21 12:16:20 +: Does anyone have a resource that has recommendations about how to name interfaces in a DNS name space? Is there a standard that is used? TIA Dan Lockwood I'm certain there are some good resources available, but f m my experience, the most important thing is to work your convention to integrate with you exising or proposed management systems. If your managment system only works from a set domain (i.e. xyz.abc.net--abc being your company and xyz being a subsection) then that label xyz should only have dashes and not periods, otherwise they become a domain themselves. So, it may depend on the size of your network: primary device: r1.company.net interface name: pos1-2-r1.company.net or pos1-2.r1.company.net or if you're there is need primary device: r1.area-or-function.company.net ...ect... There may be some customization involved with using domain subsets, but using insert lang scripts you can parse at either - or . do retrieve information. So, unless size demains creating subsections I would keep the whole name in the top label by using dashes. sig=$header
.mil domain root only hosted by one server??
I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more. These are the results I got when I queried A.ROOT-SERVERS.NET: ; DiG 9.2.1 @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN A ;; AUTHORITY SECTION: mil.86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400 ;; Query time: 390 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 15:38:58 2002 ;; MSG SIZE rcvd: 90 I'd like comments from anyone with more information on this. I'm just curious as to why it is this way and what the reasoning behind it is. Maybe I'll email hostmaster.nic.mil and ask. ;) 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
RE: IETF SMTP Working Group Proposal at smtpng.org
I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Righto, that would all be part of a registration process. As well as things like forward and reverse DNS matching for the mail server, etc. But whos to say that once they pass the test they just open up things. As well as the registrar, there would have to be a complaint and investigation department. But going that far legally tends to destroy good ideas. The most important things is the legal handling of exceptions and complaints and the actual steps on getting someone shut off. We all know how people are sue happy... -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: IETF SMTP Working Group Proposal at smtpng.org
I'd seen back in the mid 1990s a user that got banned from all the isps on his island (or fairly close to it) due to abuse of services. obviously when you have a set of only 3-4 isps to choose from this makes it a lot easier to keep the guy from doing anything evil. but these days everyone that can negotiate a bulk-dial agreement with someone and run a radius server can sign up users and make the abuse a bit harder to track ... i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. - jared On Wed, Aug 21, 2002 at 03:29:46PM -0400, Robert Blayzor wrote: Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Life would be much easier if I had the source code. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: IETF SMTP Working Group Proposal at smtpng.org
I'm not a company, I'm Joe Blow private citizen - do you expect me to pay $100 just to sign up with AOL? If you are Joe Blow private citizen, why would you need to run a mail server? Would you not use your ISP's, at least as a smart relay? If running a mail server is that important to you, just like registering a domain, you'll pay it. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Profanity is the one language all programmers know best.
Re: .mil domain root only hosted by one server??
On Wed, 21 Aug 2002 15:46:22 EDT, Vinny Abello [EMAIL PROTECTED] said: I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than The fact that you only see one doesn't mean there's only one. And note that the .MIL domain perhaps has a vested interest in *NOT* having a fully redundant view of the world accessible from outside. Sure, it's one point of failure - but if you're battening down the hatches because of an attack, it's also a one-stop place to cut yourself off -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04612/pgp0.pgp Description: PGP signature
Re: .mil domain root only hosted by one server??
Ooops... My apologies (before I get slammed). I forgot the query type of NS in my dig. ; DiG 9.2.1 @a.root-servers.net ns mil. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 11 ;; QUESTION SECTION: ;mil. IN NS ;; ANSWER SECTION: mil.86400 IN NS E.ROOT-SERVERS.NET. mil.86400 IN NS PAC2.NIPR.mil. mil.86400 IN NS CON1.NIPR.mil. mil.86400 IN NS B.ROOT-SERVERS.NET. mil.86400 IN NS A.ROOT-SERVERS.NET. mil.86400 IN NS EUR1.NIPR.mil. mil.86400 IN NS PAC1.NIPR.mil. mil.86400 IN NS H.ROOT-SERVERS.NET. mil.86400 IN NS G.ROOT-SERVERS.NET. mil.86400 IN NS CON2.NIPR.mil. mil.86400 IN NS EUR2.NIPR.mil. ;; ADDITIONAL SECTION: E.ROOT-SERVERS.NET. 360 IN A 192.203.230.10 PAC2.NIPR.mil. 86400 IN A 199.252.155.234 CON1.NIPR.mil. 86400 IN A 199.252.175.234 B.ROOT-SERVERS.NET. 360 IN A 128.9.0.107 A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 EUR1.NIPR.mil. 86400 IN A 199.252.154.234 PAC1.NIPR.mil. 86400 IN A 199.252.180.234 H.ROOT-SERVERS.NET. 360 IN A 128.63.2.53 G.ROOT-SERVERS.NET. 360 IN A 192.112.36.4 CON2.NIPR.mil. 86400 IN A 199.252.173.234 EUR2.NIPR.mil. 86400 IN A 199.252.143.234 ;; Query time: 500 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 16:07:56 2002 ;; MSG SIZE rcvd: 412 That's better. :) Go back to your regularly scheduled threads. At 03:04 PM 8/21/2002 -0500, you wrote: On Wed, Aug 21, 2002 at 03:46:22PM -0400, Vinny Abello wrote: I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more. These are the results I got when I queried A.ROOT-SERVERS.NET: ; DiG 9.2.1 @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN A ;; AUTHORITY SECTION: mil.86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400 U. The SOA MNAME field is always a single server. bastet[~]$ dig +short mil ns @g.root-servers.net PAC1.NIPR.mil. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. CON2.NIPR.mil. EUR2.NIPR.mil. E.ROOT-SERVERS.NET. PAC2.NIPR.mil. CON1.NIPR.mil. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. EUR1.NIPR.mil. bastet[~]$ -Pete 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
RE: IETF SMTP Working Group Proposal at smtpng.org
What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. If the IP space is NOT SWIP, it would need to be registered by the customer ISP or via owners rwhois server. Just my $.02; for what it's worth Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
RE: IETF SMTP Working Group Proposal at smtpng.org
What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 2002-08-21 at 14:50, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. Actually, it's swip'ed to me (I work for said ISP), but I also run a SMTP server on my laptop which bounces usually between two addresses (one at home, one at work), and I suppose that the work address (NOT swip'ed) would have a problem under this proposal. I DO understand the reasoning, but it is a **BIG** culture change, and would take a year or two or more to implement network wide. I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. (I have 3 boxes + the laptop that do SMTP regularly). Ideas given this? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: IETF SMTP Working Group Proposal at smtpng.org
If there were some sort of smtp callback pki, as long as you controled your dns and server you could do something useful on that front. here's an example i gave last night in a private e-mail: -- snip -- There is an important need to perform callback but allow for the ability to protect information from possible spammers for harvesting/verificiation. eg: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 451 try again, pending callback vs: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 550 no such user here there's also the need to do some sort of pki to allow callback to be secure. eg: the dns record for nether.net should have some public-key in it and then some other stuff like possibly mail from:[EMAIL PROTECTED] callback=validate.hotmail.com;key=alkjsdfj then pass the 'key' through the public-key availble via dns to provide back an authentication system to allow for more secure callback. but this can still be abused depending... just some thoughts, -- snip -- - jared On Wed, Aug 21, 2002 at 02:38:31PM -0500, Larry Rosenman wrote: What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. If the IP space is NOT SWIP, it would need to be registered by the customer ISP or via owners rwhois server. Just my $.02; for what it's worth Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: .mil domain root only hosted by one server??
the .mil domain has an master source, just like .com or your tld here it has a list of authoritative servers, just like .com or your tld here You are reading your response incorrectly. your dig query ask for the default, which is an A record. .MIL has no A rr at the apex. The authority for .MIL, according to a.root-servers.net, is g.root-servers.net. the NSlist for mil is: $ dig mil. ns ; DiG 8.3 mil. ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 11 ;; QUERY SECTION: ;; mil, type = NS, class = IN ;; ANSWER SECTION: mil.2D IN NSCON1.NIPR.mil. mil.2D IN NSCON2.NIPR.mil. mil.2D IN NSEUR1.NIPR.mil. mil.2D IN NSEUR2.NIPR.mil. mil.2D IN NSPAC1.NIPR.mil. mil.2D IN NSPAC2.NIPR.mil. mil.2D IN NSA.ROOT-SERVERS.NET. mil.2D IN NSH.ROOT-SERVERS.NET. mil.2D IN NSG.ROOT-SERVERS.NET. mil.2D IN NSB.ROOT-SERVERS.NET. mil.2D IN NSE.ROOT-SERVERS.NET. - all over the world. Some inside the military, some out. I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more. These are the results I got when I queried A.ROOT-SERVERS.NET: ; DiG 9.2.1 @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN A ;; AUTHORITY SECTION: mil.86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400 ;; Query time: 390 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 15:38:58 2002 ;; MSG SIZE rcvd: 90 I'd like comments from anyone with more information on this. I'm just curious as to why it is this way and what the reasoning behind it is. Maybe I'll email hostmaster.nic.mil and ask. ;) 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
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002 15:51:36 EDT, Jared Mauch said: i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. The fact that you can call back in no way means that bounces won't double-bounce into the postmaster mailbox. I'm sure that yahoo.com would buy into a callback scheme, but it wouldn;t have done squat for this double-bounce: - Transcript of session follows - ... while talking to mx1.mail.yahoo.com.: DATA 554 delivery error: dd Sorry, your message to [EMAIL PROTECTED] cannot be delivered. This account is over quota. - mta461.mail.yahoo.com 554 5.0.0 Service unavailable (OK, so THIS double-bounce was a W32/Klez-H generated one, but I get enough of the same thing for spam with a Yahoo return adress). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04621/pgp0.pgp Description: PGP signature
Re: IETF SMTP Working Group Proposal at smtpng.org
IMHO I don't think it would be that horrible of an idea with the right amount of notification and education to state something such as register your mail servers by this date or risk service interruption. ] but I also run a SMTP server on my laptop which bounces usually between two ] addresses (one at home, one at work) Actually, I don't care too much about the rest of you, nothing would force you to publish your outbound mail servers. As long as a few big sites (spam targets) honor the white list I publish for *my* own domain, great. It's voluntary, and to your advantage both as a sender and a receiver to adopt it (assuming the mailing list thing is resolvable). Domains like pobox.com wouldn't be able to use this, so it shouldn't be a requirement. Of course this period would be several months, if not a year+ . Planned obsolescence is another interesting idea, but a sure way to implement it isn't coming to mind. Basically I want my MTA to refuse deliveries from MTAs 'X' years/days older than itself. Years older vs absolute age is important, so that an isolated enterprise network somewhere could continue to inter-operate with itself no matter how old it grew. How about: use the skey style unrolling (or is that pre-rolled?) passwords to generate cookies. Someone we trust creates the 'generation 0' cookie, one-way encrypts it one thousand times, and tells us all the 'generation 1000' cookie, which we put into our MTA configs. At the next tick of the clock (one year later), the authority releases the cookie for 'generation 999', and some of us update our configs (or Microsoft and Sendmail update their new distributions - but NOT Windows Update?). You can go 'X' years without updating your configs if you want - for whatever 'X' you think most of the Internet has chosen. Talking to MTAs newer than me: If my MTA is setup with cookie 'generation 950' and an MTA connects to me offering cookie 'generation 948', then I should be able to one-way encrypt the offered cookie twice and compare it to my cookie and verify that they really are two generations ahead of me, and allow the connection. The skey trick means I don't need to know future cookies to accept email from them. Talking to MTAs older than me: I don't talk to machines 'X' generations older than me. I have the last 'X' cookies hard coded in my configs, or I just (at start time) one-way encrypt my current cookie a maximum of 'X' times to generate all of the valid old cookies I'll accept. The idea isn't to take live humans (including spammers) out of the loop, just the no-admin Windows/Solaris/Linux/whatever machines that haven't been patched in 'X' years. This year's cookie isn't a secret, just next year's and the year after's, so an admin can't setup a box with 'generation 0' and leave it alone for a thousand years to annoy the rest of us.
Re: .mil domain root only hosted by one server??
% dig +norec a.root-servers.net. mil. ns ; DiG 9.3.0s20020722 +norec a.root-servers.net. mil. ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17626 ;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 11 ;; QUESTION SECTION: ;mil. IN NS ;; ANSWER SECTION: mil.86400 IN NS PAC1.NIPR.mil. mil.86400 IN NS H.ROOT-SERVERS.NET. mil.86400 IN NS G.ROOT-SERVERS.NET. mil.86400 IN NS CON2.NIPR.mil. mil.86400 IN NS EUR2.NIPR.mil. mil.86400 IN NS E.ROOT-SERVERS.NET. mil.86400 IN NS PAC2.NIPR.mil. mil.86400 IN NS CON1.NIPR.mil. mil.86400 IN NS B.ROOT-SERVERS.NET. mil.86400 IN NS A.ROOT-SERVERS.NET. mil.86400 IN NS EUR1.NIPR.mil. ;; ADDITIONAL SECTION: PAC1.NIPR.mil. 86400 IN A 199.252.180.234 H.ROOT-SERVERS.NET. 360 IN A 128.63.2.53 G.ROOT-SERVERS.NET. 360 IN A 192.112.36.4 CON2.NIPR.mil. 86400 IN A 199.252.173.234 EUR2.NIPR.mil. 86400 IN A 199.252.143.234 E.ROOT-SERVERS.NET. 360 IN A 192.203.230.10 PAC2.NIPR.mil. 86400 IN A 199.252.155.234 CON1.NIPR.mil. 86400 IN A 199.252.175.234 B.ROOT-SERVERS.NET. 360 IN A 128.9.0.107 A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 EUR1.NIPR.mil. 86400 IN A 199.252.154.234 ;; Query time: 104 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net.) ;; WHEN: Wed Aug 21 13:15:28 2002 ;; MSG SIZE rcvd: 412 % doc -p -w mil Doc-2.2.3: doc -p -w mil Doc-2.2.3: Starting test of mil. parent is . Doc-2.2.3: Test date - Wed Aug 21 13:19:12 PDT 2002 Summary: No errors or warnings issued for mil. Done testing mil. Wed Aug 21 13:19:21 PDT 2002
Re: IETF SMTP Working Group Proposal at smtpng.org
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
Re: .mil domain root only hosted by one server??
[jabley@peppermill]% for n in a b c d e f g h i j k l m; do
for dig ${n}.root-servers.net ns mil. | egrep -qi '^mil.*NS' \
for cmdand echo ${n}.root-servers.net provides a delegation for MIL.
for done
man doc
randy
RE: .mil domain root only hosted by one server??
Perhaps the military has more interest in controlling access than in making sure John Q. Public is able to reach their sites? There's also little commercial interest in making sure they're available. I'm willing to bet the important stuff doesn't rely on DNS anyway. ;) Just my 2¢ Best regards, _ Alan Rowland USAF, Ret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Vinny Abello Sent: Wednesday, August 21, 2002 12:46 PM To: [EMAIL PROTECTED] Subject: .mil domain root only hosted by one server?? I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more. These are the results I got when I queried A.ROOT-SERVERS.NET: ; DiG 9.2.1 @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN A ;; AUTHORITY SECTION: mil.86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400 ;; Query time: 390 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 15:38:58 2002 ;; MSG SIZE rcvd: 90 I'd like comments from anyone with more information on this. I'm just curious as to why it is this way and what the reasoning behind it is. Maybe I'll email hostmaster.nic.mil and ask. ;) 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
RE: IETF SMTP Working Group Proposal at smtpng.org
Then the question becomes, Is running your own mail server worth some registration cost? Very similar to the I want my own special part of the Internet (web server). Okay, pay your $70 for two years (or whatever). BTW, just curious, who announces your MX records? Best regards, _ Alan Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Larry Rosenman Sent: Wednesday, August 21, 2002 12:39 PM To: Derek Samford Cc: 'Mark Segal'; 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. If the IP space is NOT SWIP, it would need to be registered by the customer ISP or via owners rwhois server. Just my $.02; for what it's worth Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: IETF SMTP Working Group Proposal at smtpng.org
I'm not saying it's a solution for all problems but that lets-say-for-example, AOL probally gets a lot of mail with forged yahoo,hotmail, btamail.net.cn or smiliar MAIL FROM:'s Lets say AOL, hotmail, yahoo all today had a way they could say we would like to cooperate in validating source addresses as at least somewhat more valid than today and had a mechanisim to do this with a patch to sendmail/qmail/postfix/zmailer. This would allow for while a few extra commands and bytes per smtp-transaction the ability to authenticate such data. You could also then start keeping statistics and rate-limit the callback mechanisim. AOL (and i'm sure others) have done so, you want to bulk-mail aol users, sign here. Including this ability to increase customer satisfaction is in all ISPS interest today. - jared http://story.news.yahoo.com/news?tmpl=storyu=/ap/20020820/ap_wo_en_po/fea_us_spammed_war_of_attrition_1 On Wed, Aug 21, 2002 at 04:17:53PM -0400, [EMAIL PROTECTED] wrote: On Wed, 21 Aug 2002 15:51:36 EDT, Jared Mauch said: i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. The fact that you can call back in no way means that bounces won't double-bounce into the postmaster mailbox. I'm sure that yahoo.com would buy into a callback scheme, but it wouldn;t have done squat for this double-bounce: - Transcript of session follows - ... while talking to mx1.mail.yahoo.com.: DATA 554 delivery error: dd Sorry, your message to [EMAIL PROTECTED] cannot be delivered. This account is over quota. - mta461.mail.yahoo.com 554 5.0.0 Service unavailable (OK, so THIS double-bounce was a W32/Klez-H generated one, but I get enough of the same thing for spam with a Yahoo return adress). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: IETF SMTP Working Group Proposal at smtpng.org
Title: RE: IETF SMTP Working Group Proposal at smtpng.org -Original Message- From: Robert Blayzor [mailto:[EMAIL PROTECTED]] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org I'm not a company, I'm Joe Blow private citizen - do you expect me to pay $100 just to sign up with AOL? If you are Joe Blow private citizen, why would you need to run a mail server? Would you not use your ISP's, at least as a smart relay? Because he doesn't want to. He already provides POP3/SMTP services to me under his own domain name, and why should he change his servers to permit me to send mail as if from another domain where I do have a real mail account? I hate the free stuff (no POP3/SMTP unless you pay), I already have my own on another domain (for which I pay), and I don't want his (because I don't want to keep changing email addresses everytime they get bought out/sold). In short, because if I have to depend on my ISP for my convenience, it won't get done, unless it's done their way. I use it for outbound only, I pop my mail from my other provider... James H. Smith II Speaking for myself...
[Fwd: Re: IETF SMTP Working Group Proposal at smtpng.org]
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. On Wed, 21 Aug 2002, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! How about moving this discussion to a more appropriate list? Nanog is not the place to discuss spam and we are re-inventing the wheel, badly, on nanog. Half the spam I get is from throw away AOL, netzero, earthlink, etc. accounts. Spend $10 for a new ISP account, sent 10,000 emails with MY return address which is valid and on whitelists. Do it on a long weekend and get 30k out before you get stopped. If the spammers can not run their own name servers then they will just use someone elses. Last I checked there where over 6,000 ISPs in the country. Cancel them one place and they just go to another. 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 On Wed, 21 Aug 2002, Robert Blayzor wrote: Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times.
Re: IETF SMTP Working Group Proposal at smtpng.org
Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. Why don´t you just start using SSL certs with SMTP ? The protocol is there, ways to get certificates are there, no need to start smoothing a square piece to make a new wheel. Pete
RE: IETF SMTP Working Group Proposal at smtpng.org
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Well owners of the IP space that have accounts in the registrar pay the $100 per year, per account, not server. So if you have a personal mail server, but the space is not SWIP'd to you, you'd get your ISP to authorize it. Whether they charge you extra for it would be up to them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] I haven't lost my mind; it's backed up on tape somewhere.
RE: IETF SMTP Working Group Proposal at smtpng.org
but these days everyone that can negotiate a bulk-dial agreement with someone and run a radius server can sign up users and make the abuse a bit harder to track ... Well yes and no. Using a regisrar, people on dialups who want to run mail servers simply cannot do it. The IP space would be owned by the ISP, and the ISP would have to do the mail server registrations for the customer, or SWIP a block (on a dialup, oh boy) and let the customer do the registration themselves. (which would be a legal check as well as technical check). I guess it makes it a lot harder for those customers that setup not online all the time mail servers, and that rely on things like ETRN. But mail servers need static IP's, and network operators must know about those customers that need static addresses and if there is a mail server on the end of it. That's a major problem now, mail servers getting online are not tracked. i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. I'm not disputing this at all, but I believe it would take a lot more work to get something set, agreed upon, standardized / RFC'd, the mail server software, etc., than it would to make a registrar type system. Most mail servers pretty much support this already with RBL functions, which would probably be moderately changed. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Never trust a program unless you have the source.
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002, Gary E. Miller wrote: :Then how do you account for all the lawsuits? MAPS would love to hear :you say they have no legal problems. The CA and WA legislatures that :passed laws defineing and banning spam would love to hear you as well. The lawsuits were against the solution providers, not against the spammers. In the few cases where there were lawsuits against spammers, it was a civil suit, as there isn't an existing legislative solution that spans more than a few jurisdictions. California and Washington may seem like important jurisdictions, but not compared to .kr, .cn, .ru, .br, .mx, or even .ca. :I set up a lot of help desks, online shopping carts, etc. White lists :do not work in those roles. The mail is just too all over the place :and telling a boss that he is only losing a few orders or losing a :few customers due to a white list is not an option. I do IT secuirity incident response for about 60k people, 45k hosts, their AV gateways, IDS's and firewalls and I can assure you, spam is a security problem. Security as a discipline is uniquely positioned to articulate solutions to spam. Read the tmda.net site. Read the FAQ and the README files. Mail isn't lost, it is queued. See myprivacy.ca for an example of how it operates. The system works as follows: Sender sends message to recipient. Recipients MTA/MUA checks to see if they are a registered recipient. If yes, mail is delivered. If no, mail is queued, and a confirmation asking if they they are a legitimate corespondant is sent to the sender. The sender responds with the confirmation ticket, and is whitelisted. Queued mail is delivered. Now, the confirmation message will also include a policy stating that UCE, solicitations and all the other crap that people associate with spam are not to be sent to this address and by returning this message you accept this policy. It doesn't matter if even if someone comes up with a way to autorespond to this message, as if they violate the recipients policy, they are commiting unauthorized access, theft of services etc.. What TMDA-like systems do is escalate a problem that engineering and regular expressions do not have the adequate breadth to comprehensively express, and into a question of policy, where the conceptual and legal tools already exist. What this doesn't cover is everything that AV gateway filters do, but that's another story. :Policies do not define crimes, Common Law and Written Law do. There is a reason why there have to be notices that unauthorized access to systems is prohibited in /etc/motd in any government system you access. It is so that there is no legal ambiguity when someone gets caught hacking and the case shows up in court. Ask any CISA, CISSP, computer forensics specialist, or anyone else who deals professionaly in information security, and they will tell you, that if you don't have a policy, you will have trouble convincing anyone a crime has been committed. -- batz
RE: IETF SMTP Working Group Proposal at smtpng.org
If you are Joe Blow private citizen, why would you need to run a mail server? the internet is a peer network. this is not pay to be screwed. randy
RE: Eliminating physical colocation (was Re: Shared facilities)
These places do not have cameras and evidence that point to malicious intent to destroy your network? I'm sorry but that would make me just about irate, and definitely insist on moving the equipment ASAP. I don't plan on paying for colo facilities that I have any doubt in the integrity of the people with access to the facility. (Similar Disclaimer: I've never met a union worker that wanted to do more for the customer, than for themselves. Their blatant apathy can be a detriment to real work in times of emergencies.) G On Wed, 21 Aug 2002, Deepak Jain wrote: We have seen disgruntled Union members hit the EPO in data centers in Union-friendly cities. Not pretty outcome, no matter how much redundancy you have. Fire code is not compatible with Union rules. DJ (Disclaimer, I have a completely unbalanced view of Union workers, all bad. I know there are good Union workers, but I have never met any professionally -- I have met plenty AFTER retirement though). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent J. Bono Sent: Wednesday, August 21, 2002 2:50 PM To: N. Richard Solis; Sean Donelan; [EMAIL PROTECTED] Subject: Re: Eliminating physical colocation (was Re: Shared facilities) We have always had more of an issue with Union Members rather than Verizon Employees per se. If you don't use Union Labor to install in Boston or New York you had best have a secured cabinet or else 25 pair bundles seem to spontaneously develop slices.
RE: IETF SMTP Working Group Proposal at smtpng.org
Actually, it's swip'ed to me (I work for said ISP), but I also run a SMTP server on my laptop which bounces usually between two addresses (one at home, one at work), and I suppose that the work address (NOT swip'ed) would have a problem under this proposal. No, it's not a problem. Your ISP is registered with the registrar. They can simply list your IP you've been assigned as a valid mail server. They then accept responsibility for your mail server registration. I DO understand the reasoning, but it is a **BIG** culture change, and would take a year or two or more to implement network wide. That I would agree. No disputing that. But at the same time, everyone agrees that SOMETHING needs to be done. Regardless of what is done, it will be a big change. I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. No, per company. Not per server. Per server would be a bit extreme. Especially for those that have dozens of legit mail servers. As a service provider you pay $100 a year for your account, in which you can manage adding and removing mail server IP addresses from the list. But only IP's that are in your SWIP'd space. Ideas given this? Above. Thanks for your input. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ]
RE: IETF SMTP Working Group Proposal at smtpng.org
I know the DSL provider doesn't for the /29 serving my mail server. It's under the general announcement for the ISP. I can't even get them to personalize reverse DNS without knowing someone that runs the DNS servers. On 21 Aug 2002, Larry Rosenman wrote: On Wed, 2002-08-21 at 15:25, Robert A. Hayden wrote: Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. If you have a /29 or shorter they **HAVE** to swip it. Else they can't get numbers from ARIN. So, that point is moot.
Draft of a new NANOG FAQ
Thanks to the help of many wonderful contributors we have a draft of an FAQ for the NANOG list: http://www.nanog.org/listfaq.html I hope that many of you will want to contribute. This is truly a draft and we welcome your comments, additions, subtractions, etc. Please send mail to me privately and I'll forward it to the ever-growing group of editors.
Re: IETF SMTP Working Group Proposal at smtpng.org
Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. And as pointed an NANOG and other places other ways to verify that server is ok can also be used such as having whitelist for mailservers, using AUTH, etc. What is missing is glue in the protocol to allow servers to decide on level of trust as well as actual definitions for all these verification mechanisms. On Wed, 21 Aug 2002 15:55:41 EDT, Jared Mauch said: There is an important need to perform callback but allow for the ability to protect information from possible spammers for harvesting/verificiation. eg: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 451 try again, pending callback OK.. So now *you* have to callback and pick up the spammer's mail. What did that gain you? there's also the need to do some sort of pki to allow callback to be secure. eg: the dns record for nether.net should have some public-key in it and then some other stuff like possibly Much easier would be to use the existing STARTLS stuff and use the cert presented to decide if you want to accept the mail. mail from:[EMAIL PROTECTED] callback=validate.hotmail.com;key=alkjsdfj then pass the 'key' through the public-key availble via dns to provide back an authentication system to allow for more secure callback. Note that the concept of a callback doesn't mean the same things on an IP network as it did on a POTS network. Not that callback on the POTS network was ever as secure as people thought, anyhow... but this can still be abused depending... The only callback systems that ever came anywhere near working on the POTS network were ones that you told the callback this is Fred. Call me back at the home number you've been configured with, and it called you at Fred's previously-configured phone number. Having it say 'This is Fred, call me back at 127.0.4.5' doesnt do anything for security if you're just going to call 127.0.4.5.
EPOs in critical facilities
On Wed, 21 Aug 2002, Deepak Jain wrote: We have seen disgruntled Union members hit the EPO in data centers in Union-friendly cities. Not pretty outcome, no matter how much redundancy you have. I believe the Uptime Institute has some statistics showing EPO problems are one of the top five reasons for critical facility outages. Almost no telco CO's have facility-wide EPOs. Equinix facilities do not have facility-wide EPOs. Fire code is not compatible with Union rules. The fire code is your friend. Learn it, use it, follow it. It doesn't always say what everything thinks it says. Following the code, you can build a telecommunications facility without an EPO next to every door.
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! On Wed, 21 Aug 2002, Robert Blayzor wrote: But mail servers need static IP's, and network operators must know about those customers that need static addresses and if there is a mail server on the end of it. Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. How about moving this to an approriate forum where people really know spam and mail? Nanog is for moving packets. Nanog does not usually care what is in the packet unless it is a routing protocol. 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
mail delivery time on nanog-l (was Re: Die thread, DIE!)
On Wed, 21 Aug 2002, Vinny Abello wrote: OK. People can stop correcting me now. :) I did catch the mistake immediately after I sent the email. Now something REALLY useful in an email client would be an unsend feature... I'm joking of course. I have to say that before I get slammed with the technical reasons why that wouldn't work for mail on the Internet which I'm already well aware. ;) I guess that if mail sent to the nanog list wouldnt take 5-60 minutes to get delivered to all people on the list, people would sooner see that someone else has actually answered the email in question, and wont answer themselves. I remember this being discussed earlier, is there any perticular reason why this hasnt been fixed? If nanog-l is supposed to be a list for operational purposes, doesnt that require speedy delivery in a lot of cases? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: EPOs in critical facilities
On Wed, 21 Aug 2002 17:28:48 -0400 (EDT) Sean Donelan [EMAIL PROTECTED] wrote: On Wed, 21 Aug 2002, Deepak Jain wrote: We have seen disgruntled Union members hit the EPO in data centers in Union-friendly cities. Not pretty outcome, no matter how much redundancy you have. I believe the Uptime Institute has some statistics showing EPO problems are one of the top five reasons for critical facility outages. i've seen poorly trained, inexperienced electricians hit EPOs for totally bogus reasons. putting a big red EPO button in front of them is like dangling a shiney object in front of some people i know. once at GE RD, we had an electrician announce that the room was running on emergency power, so he had to turn the emergency power off. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security
Re: IETF SMTP Working Group Proposal at smtpng.org
Larry Rosenman wrote: [...] I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. (I have 3 boxes + the laptop that do SMTP regularly). Ideas given this? Relay through your upstream (hierarchical approach)? i.e. Register your server(s) with your provider, who is presumably trusted (registered with the global system). A bit of an aside: I recall ATT Canada blocked all SMTP from exiting their network (excepting their own servers, of course) a few years back in response to a large spam. I don't know the details -- this is from a response to a complaint I filed. Interesting idea, though -- you then catch 'em when they attempt to relay through your server. And as far as that goes, I've seen a system that worked quite well... Larry might be familiar with it, as it was his. Peter E. Fry
Re: DNS entries for infrastructure equipment
another way is to use subdomains to separate device, geographic area, and primary function so that a core router in Washington DC might look like this: core-1.wdc.infrastructure.net this would be a subdomain as well as it would interfaces under it as well and possibly sub-interfaces. if you're thinking that this could make the FQDM be quite long...you're right...but one advantage is to be able to do a "dig axfr" on the sub to see all of the devices in a specific location such as "dig wdc.infrastructure.net axfr" would return all of the devices in that geographic location. Then you could dig on a specific device (as a subdomain) to see all of the interfaces configured on that device. This can lead to lots of admin overhead but some good scripts to automate it...it works. of course this is just my opinion. steve jnull wrote: [EMAIL PROTECTED]"> Dan Lockwood(dloc[EMAIL PROTECTED])@2002.08.21 12:16:20 +: Does anyone have a resource that has recommendations about how to nameinterfaces in a DNS name space? Is there a standard that is used? TIA Dan Lockwood I'm certain there are some good resources available, but fm my experience, the most important thing is to work your convention to integrate with you exising or proposed management systems. If your managment system only works from a set domain (i.e. xyz.abc.net--abc being your company and xyz being a subsection) then that label xyz should only have dashes and not periods, otherwise they become a domain themselves.So, it may depend on the size of your network:primary device: r1.company.netinterface name: pos1-2-r1.company.netor pos1-2.r1.company.net or if you're there is needprimary device: r1.area-or-function.company.net...ect...There may be some customization involved with using domain subsets, but using insert lang scripts you can parse at either "-" or "." do retrieve information. So, unless size demains creating subsections I would keep the whole name in the top label by using dashes.< br>sig=$header
RE: IETF SMTP Working Group Proposal at smtpng.org
At 11:50 AM -0400 2002/08/21, Robert Blayzor wrote: Well yes, it could be done with certificates, but it can also be done via some type of root server system like DNS uses. A database distributed among many root servers from the registrars is proven. Look. The DNS is seriously screwed-up enough as it is. Let's not take a bad model and replicate it elsewhere. Tracking valid servers seems much easier to track rather than blacklisting IP's that are not mail servers at all or are abusive servers. Sure. Only accept e-mail from white-listed servers. You don't need a complex system to manage that. IMHO I don't think it would be that horrible of an idea with the right amount of notification and education to state something such as register your mail servers by this date or risk service interruption. Sure. Are you willing to be the first? -- 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:50 PM -0400 2002/08/21, Robert Blayzor wrote: Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. When you're willing to do this for your own personal private mail server, and you're willing to lose e-mail until you get your mail server on all known whitelists in existence, I might reconsider. -- 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 4:25 PM -0400 2002/08/21, Jared Mauch wrote: Lets say AOL, hotmail, yahoo all today had a way they could say we would like to cooperate in validating source addresses as at least somewhat more valid than today and had a mechanisim to do this with a patch to sendmail/qmail/postfix/zmailer. Doesn't help. AOL uses a proprietary MTA that they have developed in-house, which would need to be modified. Of course, you'd also need to modify all the other standard MTAs, too. And don't forget about all those Microsoft and Lotus Notes gateways out there. You could also then start keeping statistics and rate-limit the callback mechanisim. AOL (and i'm sure others) have done so, you want to bulk-mail aol users, sign here. Including this ability to increase customer satisfaction is in all ISPS interest today. AOL uses all sorts of mechanisms to try to detect and eliminate spam, but I wouldn't want to go into too much detail here. -- 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
Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. How about moving this to an approriate forum where people really know spam and mail? Nanog is for moving packets. Nanog does not usually care what is in the packet unless it is a routing protocol. The NANOG mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, the list is governed by the following guidelines: ... Doesn't mention anything about Nanog is for moving packets. An anti-spam/security discussion seems perfectly acceptable to me. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gary E. Miller Sent: August 21, 2002 5:57 PM To: Robert Blayzor Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Well, that's nice... until their dynamic DNS gets promptly killed (if they got it from us or someone responsible - I can't speak for everyone in this industry), at which point they're back at square one with all their email gone. A lot of people seem to think that dynamic DNS services are a way to cover up abuse (eg: spam, warez, etc); they're not, as a decent amount of spammers have found out the hard way. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: IETF SMTP Working Group Proposal at smtpng.org
Half the spam I get is from throw away AOL, netzero, earthlink, etc. accounts. Spend $10 for a new ISP account, sent 10,000 emails with MY return address which is valid and on whitelists. Do it on a long weekend and get 30k out before you get stopped. Of course my typical answer here is those ISP's need to be responsible. Quite honestly the simple fix is to firewall all outbound port 25 connections from non-static IP assignments, and force them to use specific SMTP servers. It's possible then to have mail servers detect incoming spam from customers through their mail server farms by counting a number of messages in a given period of time, then take action. These throw away accounts you claim are usually simple residential products in which 99% of all customers don't send over 1000 messages within ten minutes. (example) I'm just throwing out ideas on trying to deal with the problem. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! On Wed, 21 Aug 2002, Robert Blayzor wrote: Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Read what I wrote again. Do not say it is not possible, I see it every day. These people, and others will be happy to help you set it up: http://www.no-ip.com Do you own a domain name? Run your own web, mail, ftp, or any server connected your cable, dsl, or dialup connection using your personal domain name. Do some googling before posting nonsense... Doesn't mention anything about Nanog is for moving packets. An anti-spam/security discussion seems perfectly acceptable to me. From the proposed nanog FAQ: Off-Topic Questions 1. Spam 2. Local DNS [...] So take this topic to somewhere it belongs. 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
RE: IETF SMTP Working Group Proposal at smtpng.org
Look. The DNS is seriously screwed-up enough as it is. Let's not take a bad model and replicate it elsewhere. I'm not saying use DNS specifically, but using something DNS like. Whether it be a database of public keys or certs really doesn't make a difference at this level. Sure. Are you willing to be the first? If it came down to the wire and something like this were implemented, and enforced, then yes, I'd be the first in line. If the software, the system and the means are available, I'd make sure we were registered before the system went live. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: IETF SMTP Working Group Proposal at smtpng.org
At 5:42 PM -0500 2002/08/21, Peter E. Fry wrote: (Checking... OK, whew -- it doesn't appear to be me...) Get a real provider. That's easier said than done, especially for DSL and cablemodem customers, who most likely have no other choice. -- 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: EPOs in critical facilities
On Wed, 21 Aug 2002, Deepak Jain wrote: We have seen disgruntled Union members hit the EPO in data centers in Union-friendly cities. Not pretty outcome, no matter how much redundancy you have. I believe the Uptime Institute has some statistics showing EPO problems are one of the top five reasons for critical facility outages. Almost no telco CO's have facility-wide EPOs. Equinix facilities do not have facility-wide EPOs. Fire code is not compatible with Union rules. The fire code is your friend. Learn it, use it, follow it. It doesn't always say what everything thinks it says. Following the code, you can build a telecommunications facility without an EPO next to every door. Like anything, clue is hard to come by in consistent quantities. Yes, you can do a lot of things once you understand the code, but even a small (areawise) EPO causes lots of problems for whoever's equipment was hit. If the reason was a disgruntled Union worker, so much's the pity. DJ
Re: IETF SMTP Working Group Proposal at smtpng.org
At 5:35 PM -0500 2002/08/21, Peter E. Fry wrote: Relay through your upstream (hierarchical approach)? i.e. Register your server(s) with your provider, who is presumably trusted (registered with the global system). This is the approach I recommend, and have recommended for years. A bit of an aside: I recall ATT Canada blocked all SMTP from exiting their network (excepting their own servers, of course) a few years back in response to a large spam. AOL does the same. They have a transparent SMTP proxy for all outgoing connections. They've also explicitly asked to have this machine added to certain blacklists, so that people who don't want to receive what is almost certainly going to be spam can choose to do so. If you want to send real e-mail using AOL, then use the mail client provided by AOL. It's that simple. -- 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 2:15 PM -0700 2002/08/21, [EMAIL PROTECTED] wrote: Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Man, wanna talk about ideas that would bring all e-mail to a complete stop across the entire Internet? Imagine what it would be like if AOL did this, so that it could take five, ten, or even fifteen minutes just to get one callback on one message, if the remote server was slow enough. Now, if you start up a sendmail queue runner every sixty minutes, you only need a very small number of messages in your queue before you start stacking up more and more and more sendmail processes, until such time as you run out of memory, your mail server crashes, and you might potentially lose all your queued e-mail. Jeezus. Do you have to be the one guy who got blamed for shutting down all e-mail across the entire Internet on Black Tuesday, just to see the flaws in this plan?!? -- 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: mail delivery time on nanog-l (was Re: Die thread,DIE!)
At 12:09 AM +0200 2002/08/22, Mikael Abrahamsson wrote: I guess that if mail sent to the nanog list wouldnt take 5-60 minutes to get delivered to all people on the list, people would sooner see that someone else has actually answered the email in question, and wont answer themselves. Show me the headers that demonstrate these delays. On the message I am responding to, I see an end-to-end delay of just a few minutes, and that amount of time could easily be accounted for by your clock being slightly off from mine. I remember this being discussed earlier, is there any perticular reason why this hasnt been fixed? If nanog-l is supposed to be a list for operational purposes, doesnt that require speedy delivery in a lot of cases? For more details on the issues involved, read the following: Author: Rob Kolstad Title: Tuning Sendmail for Large Mailing Lists Pages: 195 Publisher: USENIX Proceedings: Eleventh Systems Administration Conference (LISA '97) Date: October 26-31, 1997 Location: San Diego, California Institution: Berkeley Software Design, Inc. Author: Strata Rose Chalup Author: Christine Hogan Author: Greg Kulosa Author: Bryan McDonald Author: Bryan Stansell Title: Drinking from the Fire(walls) Hose: Another Approach to Very Large Mailing Lists Pages: 317 Publisher: USENIX Proceedings: Twelfth Systems Administration Conference (LISA '98) Date: December 6-11, 1998 Location: Boston, Massachusetts Institution: Global Networking and Computing, Inc. -- 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: Eliminating physical colocation (was Re: Shared facilities)
Bell COs do not have Cameras, at least not those in Verizon, Bell South, or SBC land that we have seen. - Original Message - From: Gerald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 21, 2002 5:30 PM Subject: RE: Eliminating physical colocation (was Re: Shared facilities) These places do not have cameras and evidence that point to malicious intent to destroy your network? I'm sorry but that would make me just about irate, and definitely insist on moving the equipment ASAP. I don't plan on paying for colo facilities that I have any doubt in the integrity of the people with access to the facility. (Similar Disclaimer: I've never met a union worker that wanted to do more for the customer, than for themselves. Their blatant apathy can be a detriment to real work in times of emergencies.) G On Wed, 21 Aug 2002, Deepak Jain wrote: We have seen disgruntled Union members hit the EPO in data centers in Union-friendly cities. Not pretty outcome, no matter how much redundancy you have. Fire code is not compatible with Union rules. DJ (Disclaimer, I have a completely unbalanced view of Union workers, all bad. I know there are good Union workers, but I have never met any professionally -- I have met plenty AFTER retirement though). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent J. Bono Sent: Wednesday, August 21, 2002 2:50 PM To: N. Richard Solis; Sean Donelan; [EMAIL PROTECTED] Subject: Re: Eliminating physical colocation (was Re: Shared facilities) We have always had more of an issue with Union Members rather than Verizon Employees per se. If you don't use Union Labor to install in Boston or New York you had best have a secured cabinet or else 25 pair bundles seem to spontaneously develop slices.
RE: IETF SMTP Working Group Proposal at smtpng.org
At 7:23 PM -0400 2002/08/21, Robert Blayzor wrote: Sure. Are you willing to be the first? If it came down to the wire and something like this were implemented, and enforced, then yes, I'd be the first in line. If the software, the system and the means are available, I'd make sure we were registered before the system went live. Right. How are you going to enforce *anything* on the Internet? Every single RFC in existence is optional, at best. Every single black list is certainly optional. And until you can control the entire Internet and operate the mail servers for everyone in the world, there's no way in hell that you're going to get everyone to subscribe to the same white list. Sorry, guy. Ain't gonna happen. -- 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
Read what I wrote again. Do not say it is not possible, I see it every day. These people, and others will be happy to help you set it up: http://www.no-ip.com Do you own a domain name? Run your own web, mail, ftp, or any server connected your cable, dsl, or dialup connection using your personal domain name. Do some googling before posting nonsense... I read what you wrote, but I'm trying to understand how dynamic DNS has anything to do with sending spam. Dynamic DNS only does forward DNS for a host IP assignment. If AOL issues an IP to a dialup customer, it's still an AOL address with AOL access restrictions, AOL reverse DNS, etc. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
Sure they can. For sending e-mail, all you need is an IP address. It would help if the reverse DNS is set up correctly, and that you claim this same name in the SMTP dialog, but this isn't required. Yes, I know they can today. My point is that with a registrar based system, they cannot, because they cannot be registered as valid mail servers. For receiving mail, all you need is a domain name, which has a set of advertised MXes. Those MXes could point to mail servers operated by friends of yours who might use UUCP, or some private routing method to send your mail to whatever your current IP address is. Those MXes could even point to your own host/domain names, and the mail would be deferred until such time as you re-connect with your dynamic DNS provider and update the IP addresses for these names. Correct, but MX's (mail servers) have static assignments, unless you change DNS every time. Running MX's on dynamic IP's to receive mail would be quite silly. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
At 7:13 PM -0400 2002/08/21, Robert Blayzor wrote: Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Sure they can. For sending e-mail, all you need is an IP address. It would help if the reverse DNS is set up correctly, and that you claim this same name in the SMTP dialog, but this isn't required. For receiving mail, all you need is a domain name, which has a set of advertised MXes. Those MXes could point to mail servers operated by friends of yours who might use UUCP, or some private routing method to send your mail to whatever your current IP address is. Those MXes could even point to your own host/domain names, and the mail would be deferred until such time as you re-connect with your dynamic DNS provider and update the IP addresses for these names. Works just fine. -- 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
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:14 PM To: 'Gary E. Miller' Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Dynamic/static IPs, though, is a distinction that's much harder to make these days (ahhh, how I miss the days of dialup... NOT). There are plenty of people (myself included) who have cable/DSL connections at home with IPs that change every 6 months or a year. Similarly, people whose organizations can't justify the /20 from ARIN will have to renumber their servers every time they change ISPs (how many WorldCom/KPN Qwest/etc single-homed customers have switched or will switch?) or outgrow the ridiculously puny allocation they were able to justify from their upstream will have to change their static IPs. Oh, and what about a DHCP setup that's set to allocate the same IP to a certain MAC address? Is that static or dynamic? As for registration, well, let's try to avoid a mess like that created by the mandatory glue record creation process involved in name server registration, shall we? With the name server registration, you end up having all kinds of unnecessary glue records floating around which either a) drive someone crazy when they move their domain around, or b) cause random people out there to end up having DNS queries showing up at machines that aren't DNS servers (anyone care to guess how someone with a personal firewall would react when they see the queies on port 53/udp?). Same thing with SWIP delegations and the like; sadly, there are still all kinds of incorrect old information floating around in these databases, and I'd rather not rely on some three year old registration in deciding whether to trust some machine. I admit that something non-IP-specific, like SSL certificates, to me seem like a much more flexible long-term solution. Plus that way when you renumber your mail server, you wouldn't need to reregister the new IP, etc. That said, I (and our several tens of thousands of users running their own mail servers) would like to know how you define a real mail server. Is a real mail server a server that you've arbitrarily decided needs a static IP? Is a real mail server a closed relay (if so, someone on this list may feel insulted that his deliberately open relay isn't real by your standards)? Is your real mail server something operated by an organization with more than 200 accounts (in which case, you're telling me that my mail server with 25 or so accounts sitting in an Exodus colo with a perfectly static IP is not real?)? Etc. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: IETF SMTP Working Group Proposal at smtpng.org
1. I want to create specification that would allow server operators themselve to decide what kind of verification they want, if you do not like callback, do not implement it. 2. Most estimate that up to 50% of mail system resources are used for processing unwanted email, viruses, etc. The amount of processing time due to new specification will be smaller then what has been gained from not having to deal with unwanted emails as much. 3. The processing is server cpu resource, while sending email is bandwidth used. I'll give up some more cpu resources to decrease used bandwidth. 4. For last years cpu speed hardware have been increasing at 2x per 2 years and are more and more powerfull. Even if the initiative goes through fairly fast (I projected2 years, that is already too optimistic), it'll be another 4 years at least before its used, by that time servers would be 8 times faster! At 2:15 PM -0700 2002/08/21, [EMAIL PROTECTED] wrote: Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Man, wanna talk about ideas that would bring all e-mail to a complete stop across the entire Internet? Imagine what it would be like if AOL did this, so that it could take five, ten, or even fifteen minutes just to get one callback on one message, if the remote server was slow enough. Now, if you start up a sendmail queue runner every sixty minutes, you only need a very small number of messages in your queue before you start stacking up more and more and more sendmail processes, until such time as you run out of memory, your mail server crashes, and you might potentially lose all your queued e-mail. Jeezus. Do you have to be the one guy who got blamed for shutting down all e-mail across the entire Internet on Black Tuesday, just to see the flaws in this plan?!?
RE: IETF SMTP Working Group Proposal at smtpng.org
Wow. I turned my back on this thread to move to my new office, and it got interesting. The answer to your quesiton is, the cert itself can do this, if it includes a unique/semi-unique identifier, such as an SSN, a name and address, etc. Many governments give their people some unique identifier. You sign up for my service and say you wanna send mail, I say, Sure! Lemmie just check your ID against the revocation list... -Dave On 8/21/2002 at 15:11:59 -0400, Mark Segal said: It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. If the IP space is NOT SWIP, it would need to be registered by the customer ISP or via owners rwhois server. Just my $.02; for what it's worth Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Dave Israel Senior Manager, DNE SE
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002 [EMAIL PROTECTED] wrote: 1. I want to create specification that would allow server operators themselve to decide what kind of verification they want, if you do not like callback, do not implement it. Ultimately, only the system that is flexible in this regards will succeed as a viable solution. 3. The processing is server cpu resource, while sending email is bandwidth used. I'll give up some more cpu resources to decrease used bandwidth. The trick (and I steal this openly and completely from a recent thread on Cypherpunks) is make mail delivery computationally difficult - for the sender. This of course assumes that we are throwing out the fools gold of Hashcash itself. Presenting a computationally difficult problem to a connecting MTA moves the requirement for the CPU power to the sender while keeping the recipient site unfettered. Let's face it, the spam problem is merely one of cost shifting from sender to reciever, and this proposal shifts the load back. Any site that wishes to maintain the current system of email subsidies to the sender domain need only provide a computationally simple token. 4. For last years cpu speed hardware have been increasing at 2x per 2 years and are more and more powerfull. Even if the initiative goes through fairly fast (I projected2 years, that is already too optimistic), it'll be another 4 years at least before its used, by that time servers would be 8 times faster! Yet, all of this would not help the spam originating sites at all because of the sheer volume of mail they must send in order to turn a profit. Yours, J.A. Terranson
Re: IETF SMTP Working Group Proposal at smtpng.org
The problem with SSL is it doesn't include certificate chain to arbitrary authorities. However, there's a space for web of trust in SSL, I believe, so yeah, a new verison of SSL might be just the ticket. On 8/22/2002 at 00:02:24 +0300, Petri Helenius said: Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. Why don´t you just start using SSL certs with SMTP ? The protocol is there, ways to get certificates are there, no need to start smoothing a square piece to make a new wheel. Pete
RE: IETF SMTP Working Group Proposal at smtpng.org
On 8/21/2002 at 15:11:59 -0400, Mark Segal said: It's almost to the point to where mail servers need their own registrar, sort of the way domains are tracked now, track mail servers. Give mail server admins the option to accept mail from registered mail servers only or from any mail server. Of course there would need to be a ramp up period, like six months to a year, to make sure all of your mail servers are registered. And of course one should only be able to register mail servers if the IP space is actually SWIP to them. And of course, Netsol should be the only registrar for the first 75 years, not counting their first extension...
Re: DNS entries for infrastructure equipment
On Wed, Aug 21, 2002 at 12:16:20PM -0700, Dan Lockwood wrote: Does anyone have a resource that has recommendations about how to name interfaces in a DNS name space? Is there a standard that is used? TIA Hrm, a useful nanog discussion, will wonders never cease... Lets start by examining some examples from exiting important networks: 0.so-5-1-0.TL2.DCA6.ALTER.NET pos1-0-622M.cr1.SFO1.gblx.net p16-7-0-0.r02.stngva01.us.bb.verio.net sl-bb22-rly-3-0.sprintlink.net ge5-1.mpr1.iad5.us.mfnx.net bbr01-p4-0.nycm01.exodus.net ges1-ge-1-1.Restonrst.cw.net so-2-0-0.mp2.Denver1.Level3.net gbr3-p40.sl9mo.ip.att.net Obviously you don't NEED to state much at all, but you probably want to come up with a naming scheme which is logical and understandable to both your engineers and the rest of the internet. The general components of a naming scheme are the geographic location, the facility information, the device information, the port information, any subint info, and optionally a speed (if you like to brag). Let's look at each one individually. Location -- Most networks use either airport codes, clli codes, or some nonstandard written-out description, each with their own advantages and disadvantages. If you are looking to describe metro areas moreso than specific cities, they may be for you. On the other hand, if you expect to have a wide variety of areas, clli code may be more appropriate. One of the problems with airport codes comes in defining exact boundries on overlap, for example IAD/DCA/BWI, SFO/PAO/SJC, LGA/JFK/EWR, etc. Another problem comes when the codes aren't obvious to the average person (for example, what the heck is IAD? ORD? LGA?). Clli codes are a little more difficult to search, but sometimes a little bit easier to figure out. Made up codes (for example CHI for Chicago, WDC for Washington DC) or written out names tend to be the most confusing. Facility information -- Most people tend to stick a number on their location code and use it to name a facility, for example IAD1, stngva01, etc. Device information -- Here is where things get a little trickier. The general idea is to come up with a descriptor for the role of the device, and attach a number. The fun part comes when you start trying to think up role names which are short and simple, but which people can get without needing some inside info or a cheat sheet. There are a number of ways you can go here, personally I'm kindof partial to GX's CR (core routers) BR (border) HR (hosting) AR (access, for cust circuits), etc. Some of the more complex ones are impossible to guess unless you know the meaning behind them. Port information -- There are a couple ways you can go here too, depending on the devices you're using. Juniper's naming scheme for interfaces solves the problem for you, with Cisco you have to get a little more creative (p or pos? gi or ge? fa or fe?), and Foundry is even worse (everything is called Ethernet). Usually you want to just replace /'s with -'s. And if you have any sub-ints, you should throw them in too. Speed -- This can sometimes be useful, sometimes bragging, or sometimes just funny when someone gets the math wrong. If you want to tack on a -oc48 or -2488M it won't hurt anything, but please don't do something stupid like sprint's 405xT1 to mean OC12. Put it all together in a way that suits you and your specific needs, and you've got a naming scheme. Personally I prefer using the hierarchy inherient in DNS to come up with something simple like: 0.ge-0-1-0.core1.iad1.yourcompany.net or pos4-0.cr1.asbnva01.us.yourcompany.net But if you're going to be one of the one big word or lots of dashes people, I (unfortunately) can't stop you. Some very good examples of a logical layout you could model from are UU/GX, and Verio. My award for most annoying layout goes to CW. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: IETF SMTP Working Group Proposal at smtpng.org
All very interesting discussion, but discussing it here on NANOG is probably about the worst idea ever -- No offense intended, I'm sure you had only good intentions. I will now go on to continue the discussion. grin As a sysadmin at a large ISP which provides DSL and dial (and hosting, colo, bla bla bla) I have to admit that I am very interested in seeing something like this happen (registration of mail servers, trustdb, anything...) as I've had a few similar thoughts in the past, but figured that something with such a global impact would be utterly unfeaseable (and likely is, but still it is fun to dream.) Spam definitely impacts services from time to time, even on the most robust servers I have. I catch customers spamming frequently (and of course follow through with my abuse team and suspend their account and kick them offline and clean their crap out of my queues, etc etc..) but the absolute worst is all the open proxies being used (not 3rd party mail relays, but hosts which are in fact not even mail servers at all, merely running an insecure proxy (socks, squid, analogx, etc..)) Anyhow, I don't want to go too far off topic, or rant about spam, or any of the other impolitic things folks do on this list, but I figured I'd let you all know that there's a sysadmin at a DSL provider who cares enough to show interest in this concept. :-) I'd have no issue with working on a system to allow customers to run their own mail servers. Then again, I'm not an engineer, or in marketing, or any of the other decision-making groups, so that'd be my opinion only I'm talking about there. (note: I rarely have time to read this list, it was pure accident that I switched to this mailbox and saw this thread, so if you wish to reply to me, please include me in the cc:--Thanks:) /wjr On Wed, Aug 21, 2002 at 03:25:50PM -0500, Robert A. Hayden wrote: Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. On Wed, 21 Aug 2002, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan -- +--+ | William Rockwood | Sr. System Administrator | [EMAIL PROTECTED]| XO Communications, Chicago DCO +--+
RE: IETF SMTP Working Group Proposal at smtpng.org
The problem with SSL is it doesn't include certificate chain to arbitrary authorities. However, there's a space for web of trust in SSL, I believe, so yeah, a new verison of SSL might be just the ticket. Lets not forget that you need an SSL cert for every server with a different host name, and you need to go through companies like Verisign to get them. (yes, there are lesser evils I know). But using SSL certs could be more expensive then just registering your company, netblock or whatever with a management account. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: [Fwd: Re: IETF SMTP Working Group Proposal at smtpng.org]
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. e-mail isn't free. in my own experience, i can pay a high price by just hitting delete a couple hundred times a day, or a medium price by turning on all kinds of anti-spam features in my MTA and sending complaints out to network owners on whatever sneaks through the blockade, or a low price by only accepting e-mail from people who have paid to register their servers with some certifier whom i am willing to trust. we'll be seeing this kind of require signed-by-trusted certificates before permitting use logic in the personal certificate field soon. why not do it at the mail server level, where there are fewer certificates and more total lifetime value per signature? the secret is in correctly answering the question who gets the money. i would love to see a bona fide nonprofit use this as a fundraising method. (any organized religion's church comes to mind here as an ideal candidate.) server-level openpgp is also an option, and would more closely reflect the social realities: (1) introducers i'm willing to trust may not be at the top of any virtual certification hierarchy other than my own; and (2) there's no compelling technical reason to keep the number of ultimately trusted keys small. (verisign/thawte may feel that there are compelling business reasons, however.) -- Paul Vixie
Re: IETF SMTP Working Group Proposal at smtpng.org
Lets not forget that you need an SSL cert for every server with a different host name, and you need to go through companies like Verisign to get them. (yes, there are lesser evils I know). But using SSL certs could be more expensive then just registering your company, netblock or whatever with a management account. i won't glock up this already busy list with a full copy of the proposal, but before y'all go off and invent something, here's some prior art that's been resoundingly pooh-pooh'd by the smtp community. http://www.vix.com/~vixie/mailfrom.txt Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. -- Paul Vixie
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:39 PM To: 'Brad Knowles' Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Correct, but MX's (mail servers) have static assignments, unless you change DNS every time. Running MX's on dynamic IP's to receive mail would be quite silly. Then perhaps you'd like to tell me how we have tens of thousands of users quite happily doing it? True, I wouldn't run Hotmail/AOL/EarthLink/etc's MXes off dynamic IPs, but for a home/small biz mail server... Oh, and one last thing, when you specify an MX (statically, as you say), you don't put in the IP but rather a name created with A record, so what prevents that A record from being a low-TTL dynamic DNS A record? Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Why don't larger ISPs follow through on this? Simply deny RIAA any access... http://www.informationwave.net/news/20020819riaa.php Too bad it's just a small ISP. - Joost ___ music-bar mailing list [EMAIL PROTECTED] http://www.ampfea.org/mailman/listinfo/music-bar
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Is someone mainitaining a server I can get an eBGP feed from that will blackhole all RIAA IPs? If not, how do you propose to block the RIAA? Ralph Doncaster principal, IStop.com On Wed, 21 Aug 2002, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... http://www.informationwave.net/news/20020819riaa.php Too bad it's just a small ISP. - Joost ___ music-bar mailing list [EMAIL PROTECTED] http://www.ampfea.org/mailman/listinfo/music-bar
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. I suppose if you want symbolism, you can host -l riaa.com and wack their wcom webserver and other stuff at att, but I'd harly call that productive. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Controlling RIAA's hired guns
I know that this has somewhat thoroughly discussed here as of late, but when has it ever been acceptable to allow hackers to break into a customer's computer? I thought that abuse and security teams were designed to stop this type of thing. -- Nigel Clarke Network Security Engineer Forever Networks
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Start now, do whatever it takes. Amongst the paperwork passed to congress, RIAA must have indicated where it's hackers would work from. Why not start there? NANOG should not sit on this. Trust me, if RIAA tried to function without email and internet access for a day or two I think they would get the message. Nigel -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 6:30 PM To: Nigel Clarke Cc: Jerry Eyers; [EMAIL PROTECTED] Subject: Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs? On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. I suppose if you want symbolism, you can host -l riaa.com and wack their wcom webserver and other stuff at att, but I'd harly call that productive. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, Aug 21, 2002 at 09:36:29PM -0700, Nigel Clarke wrote: Start now, do whatever it takes. Amongst the paperwork passed to congress, RIAA must have indicated where it's hackers would work from. Why not start there? NANOG should not sit on this. Trust me, if RIAA tried to function without email and internet access for a day or two I think they would get the message. Ok, start listing IPs... If you have them (and can confirm them of course :P), I'm certain a dozen people on this list would put up a bgp feed before you can say blackhole. Heck I'm certain people would have something to do if you even knew the provider that was planning on giving them service for such activities. Until then, it's all a bunch of speculation, and my money is still on idle threats and hype. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. The blocking of any an all directly RIAA sites, feeds, etc, would produce an economic reaction. Cut off their sales websites, their basic connectivity (how much money do you think it would cost them to go back to snail mail today?), their [few] subscription sites. Let the money do the work. Yours, J.A. Terranson [EMAIL PROTECTED] * SPEAKING STRICTLY IN A PERSONAL CAPACITY * at this time anyway. We'll see if we can't change that. Tomorrow. Goddamn right!
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, 21 Aug 2002, Miles Fidelman wrote: On Wed, 21 Aug 2002, Nigel Clarke wrote: Start now, do whatever it takes. Amongst the paperwork passed to congress, RIAA must have indicated where it's hackers would work from. Why not start there? What they plan to do sounds incredibly illegal. Now if we could arrange for their top management to spend the next few years fighting criminal charges, that might keep them out of everybody's hair :-) Theres always the possible angle of a few hundred pissed off consumers all filing individual lawsuits against the top RIAA management as individuals, going after each one of them as a person and not as a corporate entity. Then there is also the angle of blacklisting providers who provide RIAA access to the net, blacklist them like spammers or any other net abusers. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
However, this type of action might not be necessary at all. Some of the users on this list think RIAA's recent actions are nothing more than empty threats. Why doesn't NANOG make a few of its own? A polite letter from a NANOG representative should do the trick. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J.A. Terranson Sent: Wednesday, August 21, 2002 7:01 PM To: Nigel Clarke Cc: Richard A Steenbergen; Jerry Eyers; [EMAIL PROTECTED] Subject: RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs? On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. The blocking of any an all directly RIAA sites, feeds, etc, would produce an economic reaction. Cut off their sales websites, their basic connectivity (how much money do you think it would cost them to go back to snail mail today?), their [few] subscription sites. Let the money do the work. Yours, J.A. Terranson [EMAIL PROTECTED] * SPEAKING STRICTLY IN A PERSONAL CAPACITY * at this time anyway. We'll see if we can't change that. Tomorrow. Goddamn right!
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, 21 Aug 2002 22:32:22 -0700 Nigel Clarke [EMAIL PROTECTED] wrote: However, this type of action might not be necessary at all. Some of the users on this list think RIAA's recent actions are nothing more than empty threats. Why doesn't NANOG make a few of its own? Well, it seems pretty certain that RIAA is doing DOS attacks on the file sharing systems (by trying to flood them with fake files masquerading as real MP3's). I would assume that these are not idle threats. Regards Marshall Eubanks A polite letter from a NANOG representative should do the trick. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J.A. Terranson Sent: Wednesday, August 21, 2002 7:01 PM To: Nigel Clarke Cc: Richard A Steenbergen; Jerry Eyers; [EMAIL PROTECTED] Subject: RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs? On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. The blocking of any an all directly RIAA sites, feeds, etc, would produce an economic reaction. Cut off their sales websites, their basic connectivity (how much money do you think it would cost them to go back to snail mail today?), their [few] subscription sites. Let the money do the work. Yours, J.A. Terranson [EMAIL PROTECTED] * SPEAKING STRICTLY IN A PERSONAL CAPACITY * at this time anyway. We'll see if we can't change that. Tomorrow. Goddamn right!
RE: IETF SMTP Working Group Proposal at smtpng.org
Then perhaps you'd like to tell me how we have tens of thousands of users quite happily doing it? True, I wouldn't run Hotmail/AOL/EarthLink/etc's MXes off dynamic IPs, but for a home/small biz mail server... Oh, and one last thing, when you specify an MX (statically, as you say), you don't put in the IP but rather a name created with A record, so what prevents that A record from being a low-TTL dynamic DNS A record? Running a mail server off a dynamically assigned dialup *CAN* work, but it really isn't the thing to do even if you put in a low TTL on the A record. Sure it works. But what about all the messages that will requeue on remote mail servers and depending on the remote queueing strategy of the remote mail server, it can take hours before mail could be re-attempted for delivery. A dynamically assigned MX box isn't really the best thing to do. If you want to do that then you should at least have a lower preference backup MX that is on 24/7 that will accept mail on your behalf, and when your server dynamic SMTP server comes online it can simply do an ETRN to requeue the mail on the backup MX. Having one MX on a dynamic DNS mail server is just rude to remote mail servers that try to deliver mail. Why should my servers consume more resources to benefit your customers? -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 10:53 PM To: 'Vivien M.'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Running a mail server off a dynamically assigned dialup *CAN* work, but it really isn't the thing to do even if you put in a low TTL on the A record. Sure it works. But what about all the messages that will requeue on remote mail servers and depending on the remote queueing strategy of the remote mail server, it can take hours before mail could be re-attempted for delivery. A dynamically assigned MX box isn't really the best thing to do. If you want to do that then you should at least have a lower preference backup MX that is on 24/7 that will accept mail on your behalf, and when your server dynamic SMTP server comes online it can simply do an ETRN to requeue the mail on the backup MX. Having one MX on a dynamic DNS mail server is just rude to remote mail servers that try to deliver mail. Why should my servers consume more resources to benefit your customers? You're assuming that these people aren't permanently online. I expect most of our users (I hesitate to call them customers, simply because a lot of them haven't paid anything) are using 24/7 type connections. Certainly, running your own mail server and being online two hours a day is foolish. However, this has NOTHING to do with IP allocation. A friend, years ago, had a static IP dialup with an ISP that billed him for an X hour/month package, where I think X was 120 or so. He could have run a mail server that met your static IP standard of approval, and yet was (unless he wanted to pay extra) only online 1/6th of the time. Now, most of our users may not have static IPs, but they're most likely online 24/7 or close enough. Which of the two uses more resources on your servers? I'm willing to bet the static IP dialup person will, so there goes your argument. Running mail servers on non-permanent dialup connections is foolish, I'll grant you that any day, but that wasn't the point you were making. Your point was that mail servers on dynamic IPs (and you never answered my question on how you define dynamic) are bad, no matter the circumstances surrounding them, and that's just plain not true. Oh, and BTW, you're not benefiting our users by having your servers queue mail for our users. You're benefitting YOUR customers who presumably want to be able to send mail to our users, and who expect your servers to queue mail. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, 21 Aug 2002, Nigel Clarke wrote: Start now, do whatever it takes. Amongst the paperwork passed to congress, RIAA must have indicated where it's hackers would work from. Why not start there? NANOG should not sit on this. Trust me, if RIAA tried to function without email and internet access for a day or two I think they would get the message. Surprisingly enough, they didn't seem to care too much that their website was offline fora few days. You never can tell though. Nigel -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 6:30 PM To: Nigel Clarke Cc: Jerry Eyers; [EMAIL PROTECTED] Subject: Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs? On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. I suppose if you want symbolism, you can host -l riaa.com and wack their wcom webserver and other stuff at att, but I'd harly call that productive. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
On Wed, 21 Aug 2002 21:30:27 EDT, Richard A Steenbergen said: And what IPs precisely are you planning to deny? So far its all idle threats, we have no idea where they plan to launch their scans or hacking attempts from, or even if they have any clue how to hack anything. I highly doubt they'll be attaching riaa.com to it either. If you read the URL originally referenced, they intend to blackhole riaa.com itself, and then run a honeynet gnutella network. Anything that pokes their Gnutella and then does anything else on their net that looks suspicious will get blackholed. Just imagine it - lots and lots of ISPs running honeynet Gnutellas, and if you poke around in it you get blackholed. That would make the RIAA's day. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04707/pgp0.pgp Description: PGP signature
Re: IETF SMTP Working Group Proposal at smtpng.org
On Thu, 22 Aug 2002 01:08:52 +0200, Brad Knowles [EMAIL PROTECTED] said: It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Worse yet, under his proposal, you're calling back to a callback address provided by the spammer on the MAIL FROM, to verify a spammer-provided token. What's wrong with this picture? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04708/pgp0.pgp Description: PGP signature
