Re: Complaint of the week: Ebay abuse mail (slightly OT)
we all knew that profitable large network owners would change the landscape compared to merely ebitda-positive large network owners, and here's an example of how "big company" cost management practices can go up against "reasonable and customary internet behaviour" and pretty much ignore it.
Having an abuse@ email address may be customary Internet behavior but it is no longer reasonable. The fact is that SMTP email has outlived its usefulness and needs to be replaced with something that provides a chain of authentication that certifies the sender's identity. Once email senders are no longer able to falsify their identity, then it will again be economically feasible for companies to accept abuse@ email from anyone. Instead of working to prevent email relaying, we should be working to encourage it along with certification of the sender's identity. If we had a web of ISP mail servers that trust each other to certify the sender's identity, then people would be happy to accept any and all email relayed through that web. The web of trusted email servers would use a new and improved mail transfer protocol (NIMTP) that would only be used to exchange email between trusted servers. Users could continue to use authenticated SMTP to initiate the sending of email, but nobody would accept any unauthenticated SMTP servers any more. --Michael Dillon
Speaking on Deep Background, the Press Secretary whispered:
Having an abuse@ email address may be customary Internet behavior but it is no longer reasonable. The fact is that SMTP email has outlived its usefulness and needs to be replaced with something that provides a chain of authentication that certifies the sender's identity.
Will eBay do business with me if THEY have to type in a 1" square on MY webform? -- A host is a host from coast to coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
On Mon, 04 Aug 2003 13:38:37 BST, Michael.Dillon@radianz.com said:
The web of trusted email servers would use a new and improved mail transfer protocol (NIMTP) that would only be used to exchange email between trusted servers. Users could continue to use authenticated SMTP to initiate the sending of email, but nobody would accept any unauthenticated SMTP servers any more.
And this would deploy how? In particular, consider the following questions: 1) What *immediate* benefits do you get if you are among the first to deploy? (For instance, note that you can't stop accepting "plain old SMTP" till everybody else deploys). 2) Who bears the implementation cost when a site deploys, and who gets the benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want to do this?) 3) What percentage of sites have to deploy before it makes a real difference, and what incremental benefit is there to deploying before that? (For any given scheme that doesn't fly unless 90% or more of sites do it, explain how you bootstrap it). 4) Does the protocol still keep providing benefit if everybody deploys it? (This is a common problem with SpamAssassin-like content filters - if most sites filter phrase "xyz", spammers will learn to not use that phrase). If you have a *serious* proposal that actually passes all 4 questions (in other words, it provides immediate benefit to early adopters, and still works when everybody does it), bring it on over to 'asrg@ietf.org'.
Also the fact that the transition time would require many companies to run 2 or more protocols. And simply put the majority of SMTP isn't bad, if fully implemented as a single standard and implemented by vendors and developers. But the idea isn't bad, but may have massive cost additions, if you are going to authenticate servers, we would basically be better off to run a FIDONET netmail configuration, where you must register to a controlling party, but then that may mean a monthly charge. Though I do have my own proposal sitting ontop of SMTP, and used initially as something to determine the level of filtering to do, it would reduce requirements on dns queries to various rbl's. It will also validate headers and each host along the way. Another thing that I am putting in the ID.. is standard error message formats, it would make life easier for maillist owners, there is one mail server that sends back only the account name of an invalid mailbox, without a domain or email address to help even figure which message failed. Jason On 4 Aug 2003 at 12:16, Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Aug 2003 13:38:37 BST, Michael.Dillon@radianz.com said:
The web of trusted email servers would use a new and improved mail transfer protocol (NIMTP) that would only be used to exchange email between trusted servers. Users could continue to use authenticated SMTP to initiate the sending of email, but nobody would accept any unauthenticated SMTP servers any more.
And this would deploy how? In particular, consider the following questions:
1) What *immediate* benefits do you get if you are among the first to deploy? (For instance, note that you can't stop accepting "plain old SMTP" till everybody else deploys).
2) Who bears the implementation cost when a site deploys, and who gets the benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want to do this?)
3) What percentage of sites have to deploy before it makes a real difference, and what incremental benefit is there to deploying before that? (For any given scheme that doesn't fly unless 90% or more of sites do it, explain how you bootstrap it).
4) Does the protocol still keep providing benefit if everybody deploys it? (This is a common problem with SpamAssassin-like content filters - if most sites filter phrase "xyz", spammers will learn to not use that phrase).
If you have a *serious* proposal that actually passes all 4 questions (in other words, it provides immediate benefit to early adopters, and still works when everybody does it), bring it on over to 'asrg@ietf.org'.
On Mon, Aug 04, 2003 at 12:16:12PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Aug 2003 13:38:37 BST, Michael.Dillon@radianz.com said:
The web of trusted email servers would use a new and improved mail transfer protocol (NIMTP) that would only be used to exchange email between trusted servers. Users could continue to use authenticated SMTP to initiate the sending of email, but nobody would accept any unauthenticated SMTP servers any more.
Hmmm. I fail, personally, to see why ESMTP couldn't handle it. Sure, it would require a new extension, but what's what the E is for, isn't it? Specifically, view it as a form of public-key certificate exchange, whether you trust a central authority or a web of trust to establish that identity (and, really, nothing says you couldn't do both). A signature from each hop along the way (though normally this wouldn't be more than 2-3, since most mailservers these days directly connect).
And this would deploy how? In particular, consider the following questions:
1) What *immediate* benefits do you get if you are among the first to deploy? (For instance, note that you can't stop accepting "plain old SMTP" till everybody else deploys).
The very, very first to deploy? Very little, but also very little, if any, cost - since nobody will invoke that extension, there's no crypto verification overhead inbound or outbound. It costs a few bytes in your EHLO block, I guess, and some code that will stay paged out once the process has run for any length of time. Almost the first to deploy, before wide adoption? Tie it into your other spam filtering systems. Stuff from trusted sources (however that is defined) can get tailored rules for each verified site (for most, that probably means higher trust; for a few, lower).
2) Who bears the implementation cost when a site deploys, and who gets the benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want to do this?)
Like many game situations, all deployers benefit, in a curve related to the number of deployers, and the cost hits each deployer. Making the overhead cost very low (an extra config line the next time you upgrade sendmail, to turn it on, and adding certificates for sites you actually care about, if and when you care about them) would remove most of the pain. A marginal cost to deploy, weighed against a benefit based on the risk of others deploying, can still be an acceptable business risk.
3) What percentage of sites have to deploy before it makes a real difference, and what incremental benefit is there to deploying before that? (For any given scheme that doesn't fly unless 90% or more of sites do it, explain how you bootstrap it).
Two sites that speak to each other will potentially make a difference to those two sites. Value as deployment increases is probably better than linear, for most calculations of value return (I'm sure there are some where it might not be; they don't have to deploy, if the cost is higher than the value return, but that seems likely to be rare *if* it's done properly).
4) Does the protocol still keep providing benefit if everybody deploys it? (This is a common problem with SpamAssassin-like content filters - if most sites filter phrase "xyz", spammers will learn to not use that phrase).
Yes. It provides more benefit the more sites deploy it, by building a cohesive web of trusted servers within which one can believe, with some reasonable expectation of being correct, that you know who is actually talking to you - and make secondary decisions based on that, much as many folks now do with RBLs.
If you have a *serious* proposal that actually passes all 4 questions (in other words, it provides immediate benefit to early adopters, and still works when everybody does it), bring it on over to 'asrg@ietf.org'.
The devil is, of course, in the details. The most crucial of them being that it *must* be extremely easy to implement, likely to be implementable in widespread software releases, and that the incremental overhead of use must be small enough that the value provided is greater, in most cases. In my opinion, at least, the value derived isn't from stopping spam; spammers will still use throwaway accounts, folks will still try to scam others, none of this will magically stop existing. The value is in establishing a single, verifiable, consistant identity for any system with which you might wish to talk, so that you can make decisions based on that identity (or the lack thereof). Much of this is based on my observations of the use and adopting of PGP and SSL certificates. I don't sign all of my messages - most of them, yes, but I occasionally don't do so if I expect the recipient might have problems reading it, and if the recipient is valuble enough to make that choice. Even though 90% of the mail coming to my inbox isn't PGP signed, it also doesn't incur any extra cost; my client supports it automagically, and only invokes it when I *do* get signed mail. I can then look at that signature, and any other data I have either in the trust database or my own head, and make decisions based on that data (Verified signature, a person I find usually has reasonable ideas, probably worth reading; bad signature, read with skeptecism; no signature, default handling). It shouldn't be too difficult to imagine a set of rules for SpamAssassin or similar setups that looks like: MATCH (mailserver I trust to never relay spam) -1000 MATCH (mailserver which sends me lots of useful mail and rare throwaway spam accounts that their abuse team will nail) -10 MATCH (signed mailserver, unknown certificate) -1 MATCH (unsigned mailserver) +0.5 MATCH (known spamhause mailserver) +10 Okay, sure, most spammers won't be nice enough to use well-identified servers, and will fall into the unknown category; the value for this is probably initially very low (since most mail would be there), and if adoption increases, it can rise accordingly (look at how many folks are willing to flat-out refuse connections from various RBLed servers, or from all of APNIC space, or other broad, sweeping cutoffs). Value also scales much faster if it's large ISP mailservers implementing it, rather than Joe Blow's home server - and these mailservers are the ones that are most likely to be able to generate a certificate and enable a known feature line with very marginal overhead cost. As a comparison: how many sites, today, don't support the 8BITMIME extension? How much value do they lose from not supporting it? How many sites have SpamAssassin rules (or the equivalent) that assign a trust value to emails that have 8-bit headers? How much benefit did early adopters of 8BITMIME get, how much did it cost them, and how long did it take for value to rise above cost for a significant percentage of sites? I'm not going to assert that the answers are identical, but I do suspect (based solely on personal observation) that they might not be all that different, either. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
participants (5)
-
David Lesher -
Jason Robertson -
Joel Baker -
Michael.Dillon＠radianz.com -
Valdis.Kletnieks＠vt.edu