Re: Selection of Appropriate Local SMTP Relay
On Mon, Jan 10, 2000 at 12:16:25PM -0500, Daniel Senie wrote:
Using DNS, as you propose, has some problems. In your example, you rely on the topology of the network, and make assumptions about classful structure. This isn't workable in the present network environment.
I'm not convinced that I do. It's quite possible to specify a different mail relay for every individual address in an ISP's network. I might be using octet boundaries so that I can follow the same well-known in-addr.arpa zone structure as is currently used, but that's all. It seems to me that handing out mail relays in IPCP and DHCP are also very valid approaches, although they arguably require more software changes to be useful (e.g. in access-server firmware). Here are a couple of points: 1. The use of MX records in the manner I suggested allows the SMTP relays to be used to be changed fairly dynamically -- using IPCP, for example, a caller would only get one set per call (and calls can be pretty long-held; I see calls lasting five days here). 2. The use of MX records also allows backup mail relays to be specified, with an associated priority, in a familiar way. 3. Using a network-layer protocol like PPP or DHCP to collect the data requires some consistent application-layer interface to retrieve the specified nameserver info by client software; this, ideally, would require standardisation across platforms, and practically does not sound trivial. However, there's already a well-defined mechanism in almost every platform for applications to perform DNS queries. Thanks for the feedback, Joe
Joe Abley wrote:
On Mon, Jan 10, 2000 at 12:16:25PM -0500, Daniel Senie wrote:
Using DNS, as you propose, has some problems. In your example, you rely on the topology of the network, and make assumptions about classful structure. This isn't workable in the present network environment.
I'm not convinced that I do.
It's quite possible to specify a different mail relay for every individual address in an ISP's network. I might be using octet boundaries so that I can follow the same well-known in-addr.arpa zone structure as is currently used, but that's all.
Ny using octet boundaries, you're making an inference that the IP addresses are being used in a classful fashion. It's doubtful this will be the case in today's network.
It seems to me that handing out mail relays in IPCP and DHCP are also very valid approaches, although they arguably require more software changes to be useful (e.g. in access-server firmware).
Agree, which is what I said as well.
Here are a couple of points:
1. The use of MX records in the manner I suggested allows the SMTP relays to be used to be changed fairly dynamically -- using IPCP, for example, a caller would only get one set per call (and calls can be pretty long-held; I see calls lasting five days here).
2. The use of MX records also allows backup mail relays to be specified, with an associated priority, in a familiar way.
As others point out, the IP address given out for a particular dialup will NOT be representative of the ISP. For example, I use a national dialup provider for access to the 'net when I'm travelling. This provider rents POPs from PSI.net, Level3.net, and probably plenty of others. The same dialup POPs are rented by a LOT of other ISPs. Having an MX lookup on the INADDR for the IP Address of the dialup port will be quite problematic, since the desired effect is to get the name of the SMTP server for the PROPER ISP, not for the POP vendor.
3. Using a network-layer protocol like PPP or DHCP to collect the data requires some consistent application-layer interface to retrieve the specified nameserver info by client software; this, ideally, would require standardisation across platforms, and practically does not sound trivial. However, there's already a well-defined mechanism in almost every platform for applications to perform DNS queries.
You didn't comment on my other suggestion, that of doing MX on the assigned name servers. This has all of the advantages you want, without the problems associated with trying to determine which ISP is in use based on IP address. Now I'm not convinced the MX on DNS server approach is a good solution, but it's probably better than doing MX on the IP address assigned. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Mon, Jan 10, 2000 at 07:36:15PM -0500, Daniel Senie wrote:
It's quite possible to specify a different mail relay for every individual address in an ISP's network. I might be using octet boundaries so that I can follow the same well-known in-addr.arpa zone structure as is currently used, but that's all.
Ny using octet boundaries, you're making an inference that the IP addresses are being used in a classful fashion. It's doubtful this will be the case in today's network.
I don't buy your logic. By that reasoning, PTR records are not supported on today's network either, since they also work on octet boundaries.
As others point out, the IP address given out for a particular dialup will NOT be representative of the ISP.
Without a way of authenticating a user SMTP session, client IP address is the _usual_ method of deciding how much relaying an SMTP server should do for a client. Your point about port wholesaleing is perfectly valid, at least in the circumstances when the port retailer is not able to hand out addresses from her own blocks (as is possible with many port wholesalers). It's unlikely that any single approach will win all the time. My proposal was mainly intended as a quick win -- very quick and easy to implement on the ISP side (for ISPs where it is applicable), and relatively straightforward on the mail client side. It's certainly not the be-all and end-all of relay authentication solutions.
You didn't comment on my other suggestion, that of doing MX on the assigned name servers. This has all of the advantages you want, without the problems associated with trying to determine which ISP is in use based on IP address.
Aah, sorry, I didn't spot that. It also has the disadvantage that many roamers seem to have hard-coded nameservers in their laptop stacks, which frequently continue to function (although a little bit more slowly!) while they're roaming round the world. As I think I mentioned, from my experience not many operators nail down recursive lookups through their nameservers, which means you don't need to be local to use them. I presume you were still talking about using MX records in the in-addr.arpa zones, since MX records in the forward zones have other (obvious) application?
Now I'm not convinced the MX on DNS server approach is a good solution, but it's probably better than doing MX on the IP address assigned.
Joe
On Tue, 11 Jan 2000, Joe Abley wrote: | > Ny using octet boundaries, you're making an inference that the IP | > addresses are being used in a classful fashion. It's doubtful this will | > be the case in today's network. | | I don't buy your logic. By that reasoning, PTR records are not supported | on today's network either, since they also work on octet boundaries. | Yes but the methods for delegating PTR records that are smaller then a /24 are ugly hacks. See RFC 2317 if you don't already know why. Sorry, off topic, just had to get my gripe in there. --- Gates' Law: Every 18 months, the speed of software halves.
| > Ny using octet boundaries, you're making an inference that the IP | > addresses are being used in a classful fashion. It's doubtful this will | > be the case in today's network. | | I don't buy your logic. By that reasoning, PTR records are not supported | on today's network either, since they also work on octet boundaries. |
Yes but the methods for delegating PTR records that are smaller then a /24 are ugly hacks. See RFC 2317 if you don't already know why.
actually...the real problem is that since ip addresses aren't necessarily allocated on octet boundaries, you'd need more than one set of mx records at the boundary point in the dns. just having 165.165.in-addr.arpa. MX 10 noc.tor.hookup.net. MX 20 vertex.tor.hookup.net. wouldn't work if 165.165.0.0/16 was divided up into a few /18 or /19 blocks and used by different providers.
Sorry, off topic, just had to get my gripe in there.
perhaps. :) -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
Hello All , I've just been doing a few tests on some 2514 routers I had laying around . I setup the two ether interfaces & on each like the diagram below +--------+ +--------+ | 2514 |+----------------------+| 2514 | +--------+ +--------+ + + [hub] [hub] + + +---------+[ ftp source ] +---------+[ ftp source ] I noticed a drastic lessening of expected bandwidth thru the routers . On the range of seeing only 24-25% of available ether bandwidth . But when I plug the two 'ftp source's into the same hub I am getting a more resonable 66-75% of the available ether bandwidth . Has anyone any info on what might be the cause of the lack of expected thru put . Tia , JimL +----------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | 25416 22nd So | Give me Linux | | babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP | +----------------------------------------------------------------+
You are using a router with a motorola 680x0 processor at a lower clock speed that has a hard time handling two loaded T1's!! So, it shouldn't seem that bad that it can't seem to pump more then 3Mbps... On Mon, 10 Jan 2000, Mr. James W. Laferriere wrote: | | | Hello All , I've just been doing a few tests on some 2514 routers | I had laying around . I setup the two ether interfaces & on each | like the diagram below | | +--------+ +--------+ | | 2514 |+----------------------+| 2514 | | +--------+ +--------+ | + + | [hub] [hub] | + + | +---------+[ ftp source ] +---------+[ ftp source ] | | I noticed a drastic lessening of expected bandwidth thru the | routers . On the range of seeing only 24-25% of available | ether bandwidth . | But when I plug the two 'ftp source's into the same hub I am | getting a more resonable 66-75% of the available ether bandwidth . | | Has anyone any info on what might be the cause of the lack of | expected thru put . Tia , JimL | | +----------------------------------------------------------------+ | | James W. Laferriere | System Techniques | Give me VMS | | | Network Engineer | 25416 22nd So | Give me Linux | | | babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP | | +----------------------------------------------------------------+ | | | --- Gates' Law: Every 18 months, the speed of software halves.
I'm going to make a pitch for the IP-address based method. Specifically, if you have a set of well known IP addresses for common services, thus something like: 223.255.255.1 - Primary DNS 223.255.255.2 - Secondary DNS 223.255.255.3 - SMTP Mail 223.255.255.4 - Time Server You could very easily support this in ANY network. No additional HW/software required. Specifically: config> ip route 223.255.255.1 255.255.255.255 dns.ser.ver.addr config> ip route 223.255.255.3 255.255.255.255 smtp.ser.ver.addr and so on. You then add an alias on the loopback interface for the "well known" address and make sure your dns/smtp daemon binds to it. Easy to implement, easy to explain, no additional coding changes required, although it would be nice to have stuff ship with these pre-configured. All that you need is a chunk of address space reserved for this and a list of services, each assigned to an address. I think that, barring the need to find/get the IP address block, it should take only a day or so to build an appropriate list of services. The main DNS detractor that I see is figuring out how to hand out DNS server numbers in a CONSISTENT, RELIABLE fashion for roaming users. Remember, that the purpose of this is for someone to be able to find the "correct" server to provide the services which a roaming user will find at different locations depending on where they are dialing in, thus, a config for a user would be: DNS Servers - varies by location SMTP server - varies by location pop3/imap server - always home isp time server - varies by location etc.... Thus the table would only list those services which should vary based on where the user is dialing in/connecting. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On Mon, 10 Jan 2000, Forrest W. Christian wrote:
I'm going to make a pitch for the IP-address based method.
Specifically, if you have a set of well known IP addresses for common services, thus something like:
223.255.255.1 - Primary DNS 223.255.255.2 - Secondary DNS 223.255.255.3 - SMTP Mail 223.255.255.4 - Time Server
You could very easily support this in ANY network. No additional HW/software required.
Just IP addresses, which are completely free and as easily available as tap water, right? I run 3 of the aforementioned services on a box at home using a single IP. Are you suggesting that I should need 3 IP addresses within a specific range in a netblock to do so? Somehow I fail to see how this is a particularly stellar idea. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Earth is a single point of failure. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Mon, 10 Jan 2000, Patrick Greenwell wrote:
IP. Are you suggesting that I should need 3 IP addresses within a specific range in a netblock to do so?
Somehow I fail to see how this is a particularly stellar idea.
No. I'm saying everyone on the planet will use the same 3 addresses for the same 3 services. My customers will use the same IP address as your customers. If you dial into any isp configured for this and send packets destined for 223.255.255.1 you will get the "closest, best" DNS server for dialup customers. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
why not use the 127.0.0.0/8 space ... :)
223.255.255.2 - Secondary DNS 223.255.255.3 - SMTP Mail 223.255.255.4 - Time Server
You could very easily support this in ANY network. No additional HW/software required.
Specifically:
config> ip route 223.255.255.1 255.255.255.255 dns.ser.ver.addr config> ip route 223.255.255.3 255.255.255.255 smtp.ser.ver.addr
and so on.
You then add an alias on the loopback interface for the "well known" address and make sure your dns/smtp daemon binds to it.
Easy to implement, easy to explain, no additional coding changes required, although it would be nice to have stuff ship with these pre-configured.
All that you need is a chunk of address space reserved for this and a list of services, each assigned to an address.
I think that, barring the need to find/get the IP address block, it should take only a day or so to build an appropriate list of services.
The main DNS detractor that I see is figuring out how to hand out DNS server numbers in a CONSISTENT, RELIABLE fashion for roaming users.
Remember, that the purpose of this is for someone to be able to find the "correct" server to provide the services which a roaming user will find at different locations depending on where they are dialing in, thus, a config for a user would be:
DNS Servers - varies by location SMTP server - varies by location pop3/imap server - always home isp time server - varies by location
etc....
Thus the table would only list those services which should vary based on where the user is dialing in/connecting.
- Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On Mon, 10 Jan 2000 bmanning@vacation.karoshi.com wrote:
why not use the 127.0.0.0/8 space ... :)
I've heard that suggestion several times. The underlying problem is that you have routes in most peoples routing tables which look like: Network Address Netmask Gateway Address Interface 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 And as such, anything bound for 127.x.x.x won't exit most boxes. Instead you want something which looks like a "normal" IP address and will get routed towards the ISP. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On Mon, Jan 10, 2000 at 11:47:38PM -0700, Forrest W. Christian wrote:
On Mon, 10 Jan 2000 bmanning@vacation.karoshi.com wrote:
why not use the 127.0.0.0/8 space ... :)
I've heard that suggestion several times.
[teaching bill to suck eggs]
If anybody is still interested, I have written my original rambling discourse up as an internet draft, which can be found here: http://www.patho.gen.nz/~jabley/draft-jabley-relays-dns-00.txt Can I suggest we retire to the roamops list for any further discussion? Presuming I'm still welcome there, of course, after sending my initial "subscribe" message for that list directly to the list address. doh.
On Mon, 10 Jan 2000, Forrest W. Christian wrote:
I'm going to make a pitch for the IP-address based method.
Specifically, if you have a set of well known IP addresses for common services, thus something like:
223.255.255.1 - Primary DNS 223.255.255.2 - Secondary DNS 223.255.255.3 - SMTP Mail 223.255.255.4 - Time Server
You could very easily support this in ANY network. No additional HW/software required.
Not quite, this would actually cause more problems for those of us who use wholesalers for our dialup services than it would solve. It's quite important to us for many reasons for our customers to use our SMTP servers, not our wholesaler's. If each AS directed all the traffic from these well known addresses to their 'best' SMTP server, we wouldn't be able to stop our customers from sending spam or control the quality of our SMTP services. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
On Tue, 11 Jan 2000, Brandon Ross wrote:
Not quite, this would actually cause more problems for those of us who use wholesalers for our dialup services than it would solve. It's quite important to us for many reasons for our customers to use our SMTP servers, not our wholesaler's. If each AS directed all the traffic from these well known addresses to their 'best' SMTP server, we wouldn't be able to stop our customers from sending spam or control the quality of our SMTP services.
Sorry for the ignorance here... When you buy wholesale dialup how does the internet-destined traffic get routed from your customer to the internet. If it goes from the dialup through the wholesaler's network to yours and to the internet, this will not cause breakage (I doubt this is the case). If it goes from the dialup through the wholesaler's network and directly to the internet, this WILL cause breakage. (I can think of some uses for policy routing here, but I doubt that in most cases they would be useful) The point of the well-known addresses is to provide a best-guess default for those services which most likely need to be utilized from the dialup provider. For example, a lot of ISP's will not provide POP before SMTP authorization for relay, instead they rely on whichever ISP is actually hosting their "roaming" customer for relay. If ISP's could configure their customer's computer so that as long as they dial into a RFCXXXX compliant ISP they will be able to send mail, it would be great. I do understand that there is going to be some breakage. Especially when your customers don't dial into you. That's when having them hard-configure their software for your servers and having them use POP before SMTP auth makes since. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On Tue, 11 Jan 2000, Forrest W. Christian wrote:
When you buy wholesale dialup how does the internet-destined traffic get routed from your customer to the internet.
If it goes from the dialup through the wholesaler's network to yours and to the internet, this will not cause breakage (I doubt this is the case).
Nope, but even if it did and the wholesaler was routing those well known addresses to their own servers, that traffic wouldn't end up on my network or my SMTP servers unless there was some ugly VPN stuff going on.
If it goes from the dialup through the wholesaler's network and directly to the internet, this WILL cause breakage.
Yup.
I do understand that there is going to be some breakage. Especially when your customers don't dial into you. That's when having them hard-configure their software for your servers and having them use POP before SMTP auth makes since.
I think my point here is that most dialup users today are in this situation. Most of largest dialup providers out there use wholesalers for dialup. If I had to guess, I'd say that users in this situation probably amount to over half of the population in the US. I'm not saying I have the right answer, just that whatever the answer is should support at least a majority of the current base. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
On Tue, 11 Jan 2000, Brandon Ross wrote:
I'm not saying I have the right answer, just that whatever the answer is should support at least a majority of the current base.
I think must of us agree that the the truly right answer (at least for SMTP Relay) is to implement SMTP auth on a global scale. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
Sendmail 8.10 does SMTP auth well and it is supported by newer versions of most of the e-mail clients out there... "Forrest W. Christian" wrote:
On Tue, 11 Jan 2000, Brandon Ross wrote:
I'm not saying I have the right answer, just that whatever the answer is should support at least a majority of the current base.
I think must of us agree that the the truly right answer (at least for SMTP Relay) is to implement SMTP auth on a global scale.
- Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
-- North Shore Technologies Corporation - Steven J. Sobol, President & Head Geek 815 Superior Avenue #610, Cleveland, Ohio 44114, USA Phone +1 888.480.4NET sjsobol@NorthShoreTechnologies.net http://NorthShoreTechnologies.net Owned and loved by the dogs of Jaymist Chinese Shar-Pei, Montville, Ohio :) Alcohol and calculus don't mix.. Never drink and derive.
On Tue, 11 Jan 2000, Forrest W. Christian wrote:
I'm not saying I have the right answer, just that whatever the answer is should support at least a majority of the current base.
I think must of us agree that the the truly right answer (at least for SMTP Relay) is to implement SMTP auth on a global scale.
That's a nice idea...but we can't even get all the open relay's closed. How many years do you think it'll take to fundamentally change how the SMTP protocol works across the entire internet? I'm more in favor of the idea of using an SMTP server local to the network you're dialing into and blocking or transparently redirecting SMTP traffic to remote networks. I realize this makes it difficult or impossible to impose your restrictions on what your customers can do with SMTP if they dial into outsourced ports, but IMO this would stop the abuse of open relays much sooner than SMTP auth can. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| Spammers will be winnuked or System Administrator | nestea'd...whatever it takes Atlantic Net | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________
btw, you could notinstallk 223.255.255.* network on the some routers (cisco for example), 223.255.254.* only. On Tue, 11 Jan 2000, Brandon Ross wrote:
Date: Tue, 11 Jan 2000 02:05:50 -0500 (EST) From: Brandon Ross <bross@mindspring.net> To: nanog@merit.edu Subject: Re: Selection of Appropriate Local SMTP Relay
On Mon, 10 Jan 2000, Forrest W. Christian wrote:
I'm going to make a pitch for the IP-address based method.
Specifically, if you have a set of well known IP addresses for common services, thus something like:
223.255.255.1 - Primary DNS 223.255.255.2 - Secondary DNS 223.255.255.3 - SMTP Mail 223.255.255.4 - Time Server
You could very easily support this in ANY network. No additional HW/software required.
Not quite, this would actually cause more problems for those of us who use wholesalers for our dialup services than it would solve. It's quite important to us for many reasons for our customers to use our SMTP servers, not our wholesaler's. If each AS directed all the traffic from these well known addresses to their 'best' SMTP server, we wouldn't be able to stop our customers from sending spam or control the quality of our SMTP services.
Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
participants (12)
-
Alex P. Rudnev -
Andrew Brown -
bmanning＠vacation.karoshi.com -
Brandon Ross -
Chris Cappuccio -
Daniel Senie -
Forrest W. Christian -
jlewis＠lewis.org -
Joe Abley -
Mr. James W. Laferriere -
Patrick Greenwell -
Steve Sobol