Re: Email peering
On Fri, Jun 17, 2005 at 11:48:58AM -0400, Ben Hubbard wrote: You seem to repeatedly describe a solution that becomes so big that it (at least substantially) replaces 25/SMTP. That's what I don't think will work, or is needed. Please let me borrow Ben's point and expand on it. Spam as it's usually discussed (spam propagated via SMTP) is only part of the spam problem. We've seen Usenet spam, chat room spam, http referrer log spam, blog spam, and so on. And all of those bundled together and labeled as spam are only part of the overall network abuse problem -- which also involves phishing, zombies, DoS attacks, spyware, etc. And these are all (increasingly) interelated problems, e.g. spam is used to phish people to sites which forcibly download spyware, and so on. We could (and some already have) spend an enormous amount of time devising very clever solutions to these and deploying them. But as we've seen, doing so usually results only in a shift in the nature of the abuse, not an overall reduction in it. So even if we had The Perfect Solution to SMTP spam and it was globally deployed tomorrow and had no adverse side-effects...we'd buy ourselves a brief respite, no better. I'm not saying some of the technical approaches aren't clever. They are. But none of them are going to solve the problem for any acceptable value of solve, not because there's anything wrong with them per se, but because they're technological attempts to solve the problem at its end points -- rather than its source points. The best place to stop abuse is as near its source as possible. Meaning: it's far easier for network X to stop abuse from leaving its network than it is for 100,000 other networks to defend themselves from it. Especially since techniques for doing so (for instance, controlling outbound SMTP spam) are well-known, heavily documented, and easily put into service. The problem is that network X, for many values of X (see the data compiled by Spamhaus or SPEWS or any number of others) hasn't done so. Whether that failure is due to incompetence, greed, laziness, negligence or anything else is an interesting question...but really doesn't matter, because regardless of the cause, the fastest way to get it fixed is to make it X's problem...*not everyone else's*. (It's often impressive how fast X can move--despite protestations otherwise--when this situation is created.) Those who have been around a long long time know that this is how it used to be. If your network started spewing crap, and didn't stop spewing crap in a fairly timely manner, you got a phone call or email explaining that someone had their hand on your plug and was going to pull it. The point? The point is that there is no need for any new technology to deal with the spam/abuse probem. What there is a desperate need for is the *will* to use the technology we already have -- to shift the burden of dealing with abuse onto those who are permitting it to originate from their network. This can be done in a number of ways: using DNSBLs, firewalls, routers, whatever. Because if it's not done, then Network X, for many values of X, will be perfectly happy to watch everyone else innovate and scramble and spend money to defend themselves *as long as X doesn't have to*. As we've seen. For many years. Over and over and over again. After all, why should they? There's nothing in it for them and no downside if they don't. [...] if you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is it isn't scaling well. --- Paul Vixie So either the collective we has the will to stop putting up with this nonsense -- or we don't. If it's the former, then we already have all the tools we need. If it's the latter, then nothing we come up with, no matter who clever it is, is going to make any real difference. ---Rsk
Re: Email peering
Rich Kulawiec wrote: The best place to stop abuse is as near its source as possible. Meaning: it's far easier for network X to stop abuse from leaving its network than it is for 100,000 other networks to defend themselves from it. Especially since techniques for doing so (for instance, controlling outbound SMTP spam) are well-known, heavily documented, and easily put into service. The problem with countermeasures that would actually hurt the source of junk heavily enough would also have to hurt legitimate traffic making you an immediate lawsuit magnet. If that would not be the case, or some larger parties feel they could stand despite this fact, the problem would be fairly straightforward to reduce to a fraction in a few months time. Pete
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
There's no reason why one couldn't build a comparable model for mail, with the SMTP speciality service provider offering SMTP transit to a base of trusted customers. This comparatively small number of SMTP speciality provider would then maintain good relations (peerings) with the comparatively small number of major ISPs. Oh wait -- there are a variety of folks who are already specializing in doing that sort of thing -- it's just that most folks don't need to buy that sort of service (yet). While this could work, we are mixing a format and content type that is not security sensitive and is used to carry point to multipoint messages (forums?) and media (NNTP), with a format and content type that is highly sensitive, and is generally used to carry point-to-point communications which may contain things like personal or financial information (SMTP). I am not sure any level of security would make me feel good about passing my emails through a 'peering .. core' of SMTP relays. However, if we do go in this direction, I plan on firing up my old copies of BinkleyTerm. FIDO and NetMail may be a good place to start :) (Did I just date myself?) -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: Email peering
I am not sure any level of security would make me feel good about passing my emails through a 'peering .. core' of SMTP relays. However, if we do go in this direction, I plan on firing up my old copies of BinkleyTerm. FIDO and NetMail may be a good place to start :) Back in the day, there were users of Fido technology networks who were concerned with email privacy. They applied a technology called PGP to secure the contents of their messages. Interestingly enough, even though the open Internet email system doesn't normally relay email through other people's servers, many people still use PGP and its descendants to secure their email content. Could it be that some people don't trust routers to deliver their port 25 packets to the destination without diverting a copy to prying eyes? Surely people would never configure route maps to do such a thing? And let's not even begin to discuss the ways in which widespread use of crypto technology in email systems could allow for things like non-repudiable signatures. And let's not even look at a widespread email alternative that is in use on the Internet today and which is slowly gathering features that make it look more and more like email version two. Imagine what will happen when IM networks take the same step that email networks took in the early 90's and allow for general interconnection. --Michael Dillon
Re: Email peering
On 19/06/05, Alexei Roudnev [EMAIL PROTECTED] wrote: My e-mail is [EMAIL PROTECTED], but I send it when I am on DSL with EthLink (and thru Earthlink SMTP). And it is 100% valid situation. Sure is - which is one reason why spf just is not going to work for you CSV on the other hand makes no claim about the sender - it looks at the sending host
Re: Email peering
Back in the day, there were users of Fido technology networks who were concerned with email privacy. They applied a technology called PGP to secure the contents of their messages. Folks, We are talking about changing an existing system -- one with an installed base of perhaps 1B users, but it's fine if we instead use the much lower number of some mere hundreds of thousands of servers. For such situations, it is considered essential to find a way to obtain incremental utility, for incremental adoption. It is also considered essential to minimize the critical dependencies for adoption. It is considered particularly risky to have one strategic adoption decision depend upon another, especially when the second has a history of more than 10 years of failing to gain major adoption (or rather, use.) We could go into a long and painful discussion about the reasons these lessons are valid, but the reality is that they are not all that difficult to appreciate, if one looks at the process of obtaining global adoption in a voluntary environment. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: Email peering
My e-mail is [EMAIL PROTECTED], but I send it when I am on DSL with EthLink (and thru Earthlink SMTP). And it is 100% valid situation. - Original Message - From: John Levine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 18, 2005 12:25 AM Subject: Re: Email peering In between the choice of accepting mail from *anybody* by default which we have now and the choice of accepting mail from *nobody* by default that explicit peering agreements represents there is another solution; which is to accept mail only from IPs that have *some relation* to the sender's From domain, for example by MX record or by reverse DNS (we implemented that test and call it MX+). This has the same problem as all of the other duct tape authorization schemes -- it breaks a lot of valid e-mail, so that you have to maintain a painfully large manual exception table, or write off a lot of mail that your users will not forgive you for losing, or more likely, both. In this particular case, the biggest issue is forwarders, commercial ones like pobox.com, associations like the ACM and IEEE (I get some odd mail being uucp at computer.org), and large numbers of colleges and universities which let graduates keep their email address. In all of those cases, the users send mail from their own ISPs, whatever they are, inbound mail is forwarded back to the ISP accounts, and there is no way to enumerate the valid sources of mail. There's also plenty of domains where the inbound and outbound mail servers are different, and neither one matches the domain name of the mail. For example, I host about 300 small mail domains on a pop toaster here. The MX is mail2.iecc.com, and the outbound host that many but not all of them use is xuxa.iecc.com. (Mail for iecc.com itself is on another host.) The IPs all happen to be in the same /24, but guessing whether two IPs are close enough is a poor way to authenticate or authorize anything. Before you point out that they could change the way those systems work to be compatible with your scheme, well, duh, sure. But if you're going to make people change their existing working mail setups, there's little point in going through the vast cost of a widespread change for such a marginal benefit. Read archives of SPF mailing lists for endless flamage on this topic, since SPF has the same problem. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Fri, 17 Jun 2005, [EMAIL PROTECTED] wrote: The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. Dude, it's 2005. You can put down the X.400 crack pipe now. Why does fixing the SMTP email architecture by applying some lessons learned from BGP peering lead people to talk about X.400, UUCP, Bitnet, Fidonet and other obsolete protocols? Because these protocols did EXACTLY the same thing you've been attempting to push: explicitly routed, trust-based-peering delivery. IT DOES NOT SCALE, and we know this because many of us have long since implemented it! Personally, I've directly used three of the above, and still do run one of them on my personal home server. There are far too many SMTP machines already deployed out there -- we're not talking thousands; here it's tens to hundreds of thousands worldwide -- to reel it back in and make widespread, mandatory mail peering anything but a bedroom fetish for high salaried security consultants. SMTP is not perfect; however, it is the de facto standard and is widely adopted BECAUSE it does not require any of this crap. In the ideal case, where remote networks do strive to keep themselves clean, it works well. Blacklisting a remote network for its failure to keep a clean house is also not perfect, nor are any of the other heuristic approaches being taken. In spite of their imperfections, these approaches are making an impact, and pointing the blame where it belongs: squarely at the misbehaving network. You may feel free to descend back into the world where control of e-mail is in the hands of a few, but the rest of us have given up the ghost on that approach. I do, however, know of a good clinic where they can help you fight your addiction, once you're ready to admit the problem -- that's the first step towards recovery. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Mon, 20 Jun 2005, Todd Vierling wrote: There are far too many SMTP machines already deployed out there -- we're not talking thousands; here it's tens to hundreds of thousands worldwide -- to It's actually millions. And I'm not just pulling that number out of someone's -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Email peering
In between the choice of accepting mail from *anybody* by default which we have now and the choice of accepting mail from *nobody* by default that explicit peering agreements represents there is another solution; which is to accept mail only from IPs that have *some relation* to the sender's From domain, for example by MX record or by reverse DNS (we implemented that test and call it MX+). This has the same problem as all of the other duct tape authorization schemes -- it breaks a lot of valid e-mail, so that you have to maintain a painfully large manual exception table, or write off a lot of mail that your users will not forgive you for losing, or more likely, both. In this particular case, the biggest issue is forwarders, commercial ones like pobox.com, associations like the ACM and IEEE (I get some odd mail being uucp at computer.org), and large numbers of colleges and universities which let graduates keep their email address. In all of those cases, the users send mail from their own ISPs, whatever they are, inbound mail is forwarded back to the ISP accounts, and there is no way to enumerate the valid sources of mail. There's also plenty of domains where the inbound and outbound mail servers are different, and neither one matches the domain name of the mail. For example, I host about 300 small mail domains on a pop toaster here. The MX is mail2.iecc.com, and the outbound host that many but not all of them use is xuxa.iecc.com. (Mail for iecc.com itself is on another host.) The IPs all happen to be in the same /24, but guessing whether two IPs are close enough is a poor way to authenticate or authorize anything. Before you point out that they could change the way those systems work to be compatible with your scheme, well, duh, sure. But if you're going to make people change their existing working mail setups, there's little point in going through the vast cost of a widespread change for such a marginal benefit. Read archives of SPF mailing lists for endless flamage on this topic, since SPF has the same problem. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web
Re: Email peering
On 18 Jun 2005, John Levine wrote: In between the choice of accepting mail from *anybody* by default which we have now and the choice of accepting mail from *nobody* by default that explicit peering agreements represents there is another solution; which is to accept mail only from IPs that have *some relation* to the sender's From domain, for example by MX record or by reverse DNS (we implemented that test and call it MX+). This has the same problem as all of the other duct tape authorization schemes -- it breaks a lot of valid e-mail, so that you have to maintain a painfully large manual exception table, or write off a lot of mail that your users will not forgive you for losing, or more likely, both. In this particular case, the biggest issue is forwarders, commercial ones like pobox.com, associations like the ACM and IEEE (I get some odd mail being uucp at computer.org), and large numbers of colleges and universities which let graduates keep their email address. In all of those cases, the users send mail from their own ISPs, whatever they are, inbound mail is forwarded back to the ISP accounts, and there is no way to enumerate the valid sources of mail. This gets into the discussion of what percentage of mail a user gets that is like this. It varies widely. From our measurements for most users this is less than 1 percent. For me or you its definitely much higher than 1 percent (I definitely agree with you). There's also plenty of domains where the inbound and outbound mail servers are different, and neither one matches the domain name of the mail. For example, I host about 300 small mail domains on a pop toaster here. The MX is mail2.iecc.com, and the outbound host that many but not all of them use is xuxa.iecc.com. (Mail for iecc.com itself is on another host.) The IPs all happen to be in the same /24, but guessing whether two IPs are close enough is a poor way to authenticate or authorize anything. In between the two extremes of spam growing at the rate of Moores law and not using email anymore there are all sorts of solutions. Pick a solution or solutions that you like, or not. Virtually all of them will result in some sort of reduction in the current ability of anybody being able to send mail as anyone from anywhere. Before you point out that they could change the way those systems work to be compatible with your scheme, well, duh, sure. Nope wasn't going to. They'll break when sending to people who filter or reject based on MX+. But if you're going to make people change their existing working mail setups, there's little point in going through the vast cost of a widespread change for such a marginal benefit. Read archives of SPF mailing lists for endless flamage on this topic, since SPF has the same problem. Oh yeah. The only different here is that this is simpler, doesn't require any interpretation of the SPF/Microsoft policy/patent wars, and doesn't involve a complex virtually turning complete macro language embeded in DNS. You don't have to understand any new DNS entries because there are no special DNS entries with MX+. With regards to the marginal benefit, this a measurement thing that only you can determine for your specific userbase. We can measure the results from MX+ and greylisting for our users. For the people that use it, they are really happy. Perhaps they correspond with more users of large ISPs and companies that satisfy the test criteria. If you assert that it won't work for your users, that's completely within the realm of normal decision making, who am I to tell you what is going to work for your users. You only have so much time in the day, you have to make your own judgement calls for whatever techniques to make available to your users. Mike. +- 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 | +---+
Re: Email peering
This has the same problem as all of the other duct tape authorization schemes -- it breaks a lot of valid e-mail, ... In this particular case, the biggest issue is forwarders, ... This gets into the discussion of what percentage of mail a user gets that is like this. It varies widely. Agreed. Around here (Ithaca NY) it's probably on the order of 20% due to all of the Cornell grads who still use their cornell.edu address. Pick a solution or solutions that you like, or not. Virtually all of them will result in some sort of reduction in the current ability of anybody being able to send mail as anyone from anywhere. Right. That's why for widespread deployment we have to look at the small minority of schemes that don't break legitimate mail. That's why I'm looking at CSV, which makes it easier to assign reputation to sending hosts, and domainkeys (or whatever it's called when they're done mixing in IIM) which if sensibly used makes it easier to whitelist mail from people you like. R's, John
Re: Email peering
Folks, DNSWL -- this is already being done. It is not widely viewed as being in any way similar to a peering concept. What would be more similar would be a consortium of large providers providing such a whitelist. That would be something I would welcome. To repeat what John Levine said, and that I suggested in my posting Informal email peering please take a look at CSV http://mipassoc.org/csv as a candidate mechanism for determining the operations-related identity to assess, and for a means of querying a third party to obtain an assessment. CSV is simple, uses efficient DNS records, and mostly importantly uses operations identities rather than content origination identities. Several schemes that have some popularity use a path registration approach (SPF, Sender-ID) which ties an origination identifier (rfc2822.From, rfc2822.Sender, or rfc2821.MailFrom) to the MTAs along the transmission path. For you ops folks, think of this as requiring pre-registration of all source routes to all recipients. For you architecture freaks, think of it as a really spiffy layer violation. By contrast, CSV uses identities that are directly tied to the MTA that is being assessed. Once you have a validated identity, you need a scalable means of assessing it. The combinatorial explosion with email makes pair-wise agreements unscalable. Hence, some form of third-party assessment schemes is needed. And that is what motivated the idea for http://mipassoc.org. Develop a common set of best practises, and have organization commit to supporting them. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
[EMAIL PROTECTED] wrote: Today, if Joe Business gets lots of spam, it is not his ISP's responsibility. He has no-one to take responsibility for this problem off his hands. But if he only accepts incoming email through an operator who is part of the email peering network, he knows that somewhere there is someone who will take responsibility for the problem. That is something that businesses will pay for. Just look at the Postini numbers... Pete But first, ISPs have to put their hands up and take collective responsibility for Internet email as a service that has value and not just as some kind of loss leader for Internet access services. --Michael Dillon
Re: Email peering
Similar concept, same scaling problems; it just hides the explicit routing from the user (as would any modern peering system, presumably). Then you are presuming wrongly. Nowhere in what I wrote have I suggested any changes in the existing email technology. I am not suggesting that we drop SMTP in favour of your favourite old dusty protocol. I am suggesting that we need a system of accountability for people who run Internet email servers based on contracts and SLAs, i.e. peering agreements. I haven't specified how it would be implemented because I expect that the companies negotiating such agreements would specify this in some kind of operational best-practices document. One way that it COULD be implemented is for people accepting incoming email on port 25 to check a whitelist before accepting email. Only operators who have signed a peering agreement would be on the whitelist. Presumably, the whitelist would be served up by your regional association and they would have some means of relaying queries (or synchronizing their database) with the other 4 regions. Let's face it, people have described a lot of best practices for running SMTP based email services but there has never been a concerted effort to implement these in some methodical way. It has always been a case of preaching to the converted at NANOG or on some lists. And it just does not scale! --Michael Dillon
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
There are, however, three very big problems. First, it forces people to pay for services that they don't pay for today. Businesses often pay, not for services, but for accountability. They want someone else to take responsibility for a problem even if it costs them more money than taking that responsibility on themselves. Insurance, maintenance contracts, etc. Today, if Joe Business gets lots of spam, it is not his ISP's responsibility. He has no-one to take responsibility for this problem off his hands. But if he only accepts incoming email through an operator who is part of the email peering network, he knows that somewhere there is someone who will take responsibility for the problem. That is something that businesses will pay for. But first, ISPs have to put their hands up and take collective responsibility for Internet email as a service that has value and not just as some kind of loss leader for Internet access services. --Michael Dillon
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. Dude, it's 2005. You can put down the X.400 crack pipe now. Why does fixing the SMTP email architecture by applying some lessons learned from BGP peering lead people to talk about X.400, UUCP, Bitnet, Fidonet and other obsolete protocols? You're right, it's 2005 and we have suffered from email SPAM for 10 years now, getting worse every year. So when are we going to admit that SMTP-based email is *NOT* the superior solution for email that we all thought it was in 1995? --Michael Dillon
Re: Email peering
[EMAIL PROTECTED] wrote:
Similar concept, same scaling problems; it just hides the explicit
routing
from the user (as would any modern peering system, presumably).
snip
One way that it COULD be implemented is for people accepting
incoming email on port 25 to check a whitelist before accepting
email. Only operators who have signed a peering agreement would
be on the whitelist. Presumably, the whitelist would be served
up by your regional association and they would have some means
of relaying queries (or synchronizing their database) with the
other 4 regions.
DNSWL -- this is already being done. It is not widely viewed as being in
any way similar to a peering concept. What would be more similar would
be a consortium of large providers providing such a whitelist. That
would be something I would welcome.
I would settle for having aol,msn,yahoo,earthlink,cablevision or any
half dozen providers making public THEIR whitelists.
The problem is that there does not appear to be any incentive for them
to do so -- fee or no fee.
In fact, I would encourage anyone planning on ragging on DNSBL's to put
up AND shut up, namely operate a DNSWL.
Existing public whitelists include:
exemption.ahbl.org
bondedsender.org
habeas.com
To use it with sendmail:
jlewis's http://njabl.org/dnswl.m4
http://groups-beta.google.com/group/comp.mail.sendmail/msg/a26d1cbd1c739626
To use it with spamassassin:
header XXX_DNSWL eval:check_rbl('xxx-firsttrusted', 'xxx.ttec.net')
score XXX_DNSWL -5
Anyone else with a public DNS whitelist?
snip
Re: Email peering
On 17/06/05, Joe Maimon [EMAIL PROTECTED] wrote: DNSWL -- this is already being done. It is not widely viewed as being in any way similar to a peering concept. What would be more similar would be a consortium of large providers providing such a whitelist. That would be something I would welcome. Something that is already being setup, and that tends to add a slight amount of reputation to any authentication schemes that might be used, is a feedback loop Kind of like what we do, or what AOL does (http://postmaster.info.aol.com/fbl/) Not public as such, but well it is as much like peering as anything in the smtp email world can be. [eoe gateways to uucp and x400] -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's SenderIDAuthentication......?]
[EMAIL PROTECTED] said: That is something that businesses will pay for. But first, ISPs have to put their hands up and take collective responsibility for Internet email as a service that has value and not just as some kind of loss leader for Internet access services. Many large organizations already have already, in a case by case way, set up private mail peering with others they exchange large volumes of mail with. This trusted traffic is often able to bypass the expense and delay of the spam-filter farm, making the cost and hassle of a parallel mail infrastructure worthwhile to them, and everyone is happy. There is no reason you can't pick another port, modify one of the many FOSS mail servers out there to do whatever it is you are proposing, and start providing this kind of thing on a more formal basis. Call it an email toll-road. (hm, would a toll-road be troll free? I might pay for that). If you are able to create a solution that works, and that people will pay for, then you'll be happy. Since it works in parallel, it won't disrupt anyone who doesn't want to play along, so they won't be anymore unhappy than they are now. I don't think what you have been talking about so far will work, and I don't think I'm alone in that. But hey, prove me wrong, and maybe someday I'll be writing a check to you to make sure I get email every day. Best, Ben
Re: Email peering
Many large organizations already have already, in a case by case way, set up private mail peering with others they exchange large volumes of mail with. This trusted traffic is often able to bypass the expense and delay of the spam-filter farm, making the cost and hassle of a parallel mail infrastructure worthwhile to them, and everyone is happy. Sounds good. I don't think what you have been talking about so far will work, and I don't think I'm alone in that. That's strange because you just finished describing how SOME companies are already engaging in email peering on a piecemeal basis. And how these companies ARE finding this to be beneficial in reducing costs. So please explain why my suggestion about widespread email peering agreements won't work? And please don't suggest that webs of trust are not scalable. Given the techniques of scaling that we have in the 21st century, I simply don't believe that. --Michael Dillon
Re: Email peering
In message [EMAIL PROTECTED] om, [EMAIL PROTECTED] writes: Similar concept, same scaling problems; it just hides the explicit routing from the user (as would any modern peering system, presumably). Then you are presuming wrongly. Nowhere in what I wrote have I suggested any changes in the existing email technology. Quite apart from anything else, this requires an email routing protocol. Getting the policy statements right in such a protocol is a non-trivial task; it will make BGP look simple, because of the implied liability a mail sender would incur under this scheme. Let me be very specific. I own a 1U server in a rack somewhere. (The concept has been discussed here many times, of course; thanks to some friends, I can actually do it.) How do I send email? Well, maybe the colo operator has a mail server. Maybe the rack operator has mail-forwarding contracts with his upstream IP (i.e., BGP) peering providers. To whom can they send mail? More precisely, with whom have they signed contracts that will let them deliver mail, and under what conditions? Maybe one of the upstreams has better contracts in some countries than the other does, or maybe the other will charge me less for delivering my email, but with a hefty chargeback to me if it's found to be spam. Or maybe one of them won't talk to (or listen to) mailers in certain parts of the world -- we've seen that alleged and/or bragged about on this list -- because of perceptions of where spam comes from. But the better mail server I'd prefer to use is down today, because of a fiber cut/DDoS attack/spam overload. How do I know, and how do I fall back to an alternate? We can all invent more scenarios. I think we can all see the analogies to BGP, too -- and we all know how hard it is to get that to do what we want. The scheme you're suggesting might work without new protocols in a purely hierarchical world. It might even work with a fully-connected cluster of Tier 1s, each of which is a tree root. But the Internet doesn't work that way, or we'd all be using EGP for routing. Besides, as I mentioned the other day, there are policy side-effects. See http://news.com.com/Your+ISP+as+Net+watchdog/2100-1028_3-5748649.html?tag=nefd.top for an example of the kind of thing I'm worried about. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Email peering
On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote: Similar concept, same scaling problems; it just hides the explicit routing from the user (as would any modern peering system, presumably). Then you are presuming wrongly. Nowhere in what I wrote have I suggested any changes in the existing email technology. I am not suggesting that we drop SMTP in favour of your favourite old dusty protocol. I am suggesting that we need a system of accountability for people who run Internet email servers based on contracts and SLAs, i.e. peering agreements. In between the choice of accepting mail from *anybody* by default which we have now and the choice of accepting mail from *nobody* by default that explicit peering agreements represents there is another solution; which is to accept mail only from IPs that have *some relation* to the sender's From domain, for example by MX record or by reverse DNS (we implemented that test and call it MX+). Here is a downloadable reference implementation for use with procmail: http://mxplus.org/ The example program mxplus is code that was carved out of the mail server software we use and made standalone. It's an antispam option that works well for many users. The example includes sender email address validation, which is another test like MX+ that works well for most users and breaks under usually acceptable circumstances when senders do bad things like send email with an invalid From address. YMMV. Mike. +- 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 | +---+
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
The number of agreements needed in the email world is significantly higher than what is needed for BGP. The proponents of email peering typically want to switch from the current model (millions of independant email servers) to a different model, with only a few big actors. * [EMAIL PROTECTED] [Thu 16 Jun 2005, 14:48 CEST]: I don't know who these proponents are, that you refer to. However, in my earlier message I quite clearly described a model that allows for millions of independent email servers organized in roughly 3 levels of hierarchy and I described how it could be done so that email peering IS NOT LIMITED to a few big actors. You pour some RIR sauce over your hierarchy of the top five players but that still makes it a model with only a few big actors. [..] This will not prevent spam, but it will provide operators with the power to shut it off, whenever it occurs. It would No. Infrastructure will provide operators with that power, legal agreements will not. [..] What is missing today? Paraphrased: Basically a lot of administrative overhead that will increase costs of everybody involved with no direct benefit except for the satellite players providing those new services and those looking for control over basic infrastructure for whatever reason. If the BGP peering side of the business can sort out all of this stuff, then why can't the email side of the business do the same, or perhaps, do even better? It's not comparable, as has been explained several times to you. -- Niels. -- The idle mind is the devil's playground
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
If the BGP peering side of the business can sort out all of this stuff, then why can't the email side of the business do the same, or perhaps, do even better? It's not comparable, as has been explained several times to you. Perhaps you have never been involved in BGP peering? Let me explain what the BGP peering side of the business does, in addition to operating BGP sessions with peers. To start with, most ISPs don't start peering until after they have negotiated and agreement. Those agreements are legal contracts with many pages specifying the responsibilities of the two parties, limits on how the technology is to be applied, SLAs, processes for interoperation and communication between NOCs, i.e. the people protocols. The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. I have seen many of these contracts in companies that I worked for in the past. They are rather similar to one another in many ways. Since the total number of BGP peers is rather small, it is quite workable to let these contracts evolve to some sort of rough standard and that is what has happened. In the email world, there are many, many more players, and some kind of secret sauce is essential to converge bilateral email peering agreements to some kind of community standard rather than letting evolution take its course and risking chaos as a result. The stuff that you call RIR sauce, is what I would call open and public negotiation in some kind of a forum which is not biased or dominated by parties who may have some market dominance. It is, in fact, the antithesis of a model with a few big actors. It is also a model that works, more or less, in other industries. The FCC is one example imposed by government. The RIRs is another example formed from the ground up. There is more than one way to do this. Which would you prefer as a role model, the FCC or ARIN? --Michael Dillon P.S. ARIN itself has absolutely nothing to do with email services and is unlikely to get involved in this in any way. I am using them mainly as a successful example of an open public organization that manages a common resource.
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote: If the BGP peering side of the business can sort out all of this stuff, then why can't the email side of the business do the same, or perhaps, do even better? It's not comparable, as has been explained several times to you. Perhaps you have never been involved in BGP peering? Let me explain what the BGP peering side of the business does, in addition to operating BGP sessions with peers. To start with, most ISPs don't start peering until after they have negotiated and agreement. Those agreements are legal contracts with many pages specifying the responsibilities of the two parties, limits on how the technology is to be applied, SLAs, processes for interoperation and communication between NOCs, i.e. the people protocols. This is a commonly made claim, but is rarely true in practice. A few of the largest networks, generally with small numbers of peers, require peering contracts. Most of the smaller networks with large numbers of peering sessions seem to have decided that the overhead of dealing with contracts isn't justified by the benefits. We've got several hundred peering sessions here, and maybe four or five signed contracts. The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. I have seen many of these contracts in companies that I worked for in the past. They are rather similar to one another in many ways. Since the total number of BGP peers is rather small, it is quite workable to let these contracts evolve to some sort of rough standard and that is what has happened. If we ignore the contract piece, this sounds a lot like UUCP. In the email world, there are many, many more players, and some kind of secret sauce is essential to converge bilateral email peering agreements to some kind of community standard rather than letting evolution take its course and risking chaos as a result. The stuff that you call RIR sauce, is what I would call open and public negotiation in some kind of a forum which is not biased or dominated by parties who may have some market dominance. It is, in fact, the antithesis of a model with a few big actors. It sounds like you envision five big actors, who would function as regulated long distance/international e-mail carriers, each of which would have a monopoly in their region. This is the phone network model in a lot of places, except that phone monopolies don't often cover more than a few countries while your five e-mail monopolies would have an average of 40 countries each. I'll withhold public judgment on whether this would be a good thing. -Steve
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
Far not, I have nothing to add on the e-mail peering hand-waving, but... On 2005-06-16, at 11:49, [EMAIL PROTECTED] wrote: If the BGP peering side of the business can sort out all of this stuff, then why can't the email side of the business do the same, or perhaps, do even better? It's not comparable, as has been explained several times to you. Perhaps you have never been involved in BGP peering? Let me explain what the BGP peering side of the business does, in addition to operating BGP sessions with peers. To start with, most ISPs don't start peering until after they have negotiated and agreement. Those agreements are legal contracts with many pages specifying the responsibilities of the two parties, limits on how the technology is to be applied, SLAs, processes for interoperation and communication between NOCs, i.e. the people protocols. ... this (above) is vastly different to my experience. At ISC we have between 1000 and 2000 BGP sessions active at exchanges around the world. I can count the number of those that required signed peering agreements on two hands. Of those that did require paperwork, most were very happy to set up BGP sessions straight away, without waiting for the contracts to be signed and mailed. (If there are any such people watching, to whom I never got around to sending you a signed contract back, please let me know, and sorry :-) Unless I am just very special, and some natural law protects me from mountains of legal paperwork which everybody else is obliged to climb, BGP peering is a lot more free and loose in real life than you suggest. Joe
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
I don't know who these proponents are, that you refer to. However,
in my earlier message I quite clearly described a model that allows
for millions of independent email servers organized in roughly
3 levels of hierarchy and I described how it could be done so
that email peering IS NOT LIMITED to a few big actors.
You mean like ucbvax? (If you don't know what that means, you have no
business talking about Internet e-mail.)
Seriously, the mess you're proposing was already done. It didn't scale.
Taken from http://en.wikipedia.org/wiki/UUCP :
=
People often published compound bang addresses using the { } convention
(see glob) to give paths from several big machines, in the hopes that
one's correspondent might be able to get mail to one of them reliably
(example: ...!{seismo, ut-sally, ihnp4}!rice!beta!gamma!me). Bang paths of
8 to 10 hops were not uncommon in 1981.
=
You're lost in the past. Study history and stop repeating it back to us.
--
-- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
Todd Vierling wrote: On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote: The proponents of email peering typically want to switch from the current model (millions of independant email servers) to a different model, with only a few big actors. I don't know who these proponents are, that you refer to. However, in my earlier message I quite clearly described a model that allows for millions of independent email servers organized in roughly 3 levels of hierarchy and I described how it could be done so that email peering IS NOT LIMITED to a few big actors. You mean like ucbvax? (If you don't know what that means, you have no business talking about Internet e-mail.) Seriously, the mess you're proposing was already done. It didn't scale. I think the salient point is that BGP itself does not and would not scale to the same level of demand SMTP peering agreements would need. Currently 160k prefixes and 16bit ASNs -- while in and of itself stretching many operators scaliability limits -- come nowhere close to millions of domain names, mailsystems, mail orgs, mail users and pieces of mail. Aggregation is currently failing for BGP, there is no rational basis to assume it could even begin to make traction for SMTP. Its a pipe dream.
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
I don't know who these proponents are, that you refer to. However,
in my earlier message I quite clearly described a model that allows
for millions of independent email servers organized in roughly
3 levels of hierarchy and I described how it could be done so
that email peering IS NOT LIMITED to a few big actors.
You mean like ucbvax? (If you don't know what that means, you have no
business talking about Internet e-mail.)
Seriously, the mess you're proposing was already done. It didn't scale.
Taken from http://en.wikipedia.org/wiki/UUCP :
=
People often published compound bang addresses using the { } convention
(see glob) to give paths from several big machines, in the hopes that
one's correspondent might be able to get mail to one of them reliably
(example: ...!{seismo, ut-sally, ihnp4}!rice!beta!gamma!me). Bang paths of
8 to 10 hops were not uncommon in 1981.
=
You're lost in the past. Study history and stop repeating it back to us.
Although I agree that email peering is a seriously bad idea, I don't
think that the analogy to uucp is correct. Uucp users had to know
explicit paths; today, we'd use routing protocols. (I tried the
equivalent for uucp back in 1982, but the map data -- think routing
registry -- was of too low quality. Hmm -- today's routing registry
isn't very complete, either. But we have BGP, which uucp didn't have.)
Uucp also relied on relative names, rather than absolute domain names.
This scheme would retain domain names.
The other big difference from early uucp is the presence of business
agreements. A lot of uucp email (and netnews) traffic was, shall we
say, not always carried in accord with corporate goals. People today
are accustomed to paying for basic Internet services such as access;
that was rarely possible in uucp days. (For more details, see
http://www.cs.columbia.edu/~smb/papers/pathalias.paper.pdf by myself
and Peter Honeyman, published in 1986.)
There are, however, three very big problems. First, it forces people to
pay for services that they don't pay for today. I'm not talking about
Jo[e] Consumer, I'm talking about a modest-sized business or ISP. They
have the ability to deliver email today and will resist being told to
pay. Nor will paying stop them from receiving spam -- at best, they
see less spam if *you* pay. In other words, the incentives are
backwards.
A second problem is that multi-hop email seriously reduces reliability.
That is indeed a lesson we learned in uucp days. It's mentioned in the
paper; it was present even more explicitly in the original pathalias
software package I released.
But the biggest issue is control: if you have to pass email through a
site, that site controls whether or not it can be delivered. Yes, that
might stop (some) spam. Might it also stop unpopular political ideas,
or provide a facility for government (or whomever) to profile you?
Maybe my upstream email provider, 3 hops away, is Google; does that
mean I've consented to let Google associate keywords in my email with
my email address? (I won't reprise the debate about gmail and privacy,
save to note that as of this morning, the Google web page on *sender*
privacy still doesn't address that point.)
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Thu, 16 Jun 2005, Steven M. Bellovin wrote: You're lost in the past. Study history and stop repeating it back to us. Although I agree that email peering is a seriously bad idea, I don't think that the analogy to uucp is correct. You're right -- I left out the routing table bit, which also existed some time ago. BITNET used the bitnet.links file; here's an old one still accessible for viewing: http://web.mit.edu/afs/athena/reference/net-directory/host-tables/bitnet.links Similar concept, same scaling problems; it just hides the explicit routing from the user (as would any modern peering system, presumably). -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
Of course, there's already one application-level messaging protocol that relies extensively on arranged peerings: Usenet. Usenet doesn't rely on a *full* N-way mesh of arranged peerings, it relies instead on a core of fairly well interconnected backbone or core news sites who've agreed to do feeds with each other, as well as to feed downstream leaf nodes (either on a for-fee commercial basis, or gratis as part of a regional consortia or whatever). To receive traffic or originate traffic, a leaf node doesn't need to peer with every other news server, it just needs to do feeds with a couple of upstream core sites to insure that it has reasonable coverage and redundancy. Spam isn't much of a problem on Usenet anymore because peers who tend to have spam issues tend to clean them up or get depeered or shunned... There's no reason why one couldn't build a comparable model for mail, with the SMTP speciality service provider offering SMTP transit to a base of trusted customers. This comparatively small number of SMTP speciality provider would then maintain good relations (peerings) with the comparatively small number of major ISPs. Oh wait -- there are a variety of folks who are already specializing in doing that sort of thing -- it's just that most folks don't need to buy that sort of service (yet). Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
[EMAIL PROTECTED] writes: The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. Dude, it's 2005. You can put down the X.400 crack pipe now. ---Rob
