|
||
|
||
Back in the days of dial-up modems and transfer speeds measured in hundreds of bits per second, unwanted email messages were actually felt as a significant dent in our personal pocketbooks. As increases in transfer speeds outpaced increases in spam traffic, the hundreds of unwanted emails we received per week became more of a nuisance than a serious financial threat. Today sophisticated spam filters offered by all major email providers keep us from seeing hundreds of unwanted emails on a daily basis, and relatively infrequently allow unwanted messages to reach our coveted Inboxes.
So, to some degree, the spam problem has been mitigated. But this “mitigation” requires multiple layers of protection and enormous amounts of continually-applied effort. First, there’s blacklisting—the “Internet Jail”—which forces spammers to constantly change and taint IP addresses. Then there’s whitelisting, for those who don’t mind never hearing from long-lost pre-Internet friends again. Next, there’s SPF, which helps us be certain that we don’t bounce error messages to the wrong people (though there are loopholes). And finally, as a last resort, we have content filtering, which weeds out all the viruses and other material that the cyber-filter finds objectionable to its artificial conscience. The result—for me, at least—is that I have to manually delete about 30 unwanted emails a day, and Yahoo takes care of the other 300. But I have little idea how well it’s working—I simply don’t have time to wade through 300 emails a day to make sure Yahoo hasn’t censored anything important. Who knows how many people out there are holding little grudges against me for never responding to their messages? Who knows how much pent-up tension false positives are causing in our modern email-centric society?
Since the advent of email decades ago, the paradigm has never changed: A sender composes a message, kisses it goodbye, and hands it off to a delivery service. The delivery service finds the exact addressee, and delivers the message. Back when email users were few and one person’s personal address book may have listed half of all email users in the world, this was fine, because not only could you trust the delivery service, you could trust all of the senders—why would Professor Smith ever want to send Professor Jones an advertisement for magic pills, when they both knew perfectly well that nobody could beat Professor Johnson’s price? The problem is that the system was—and is—tilted in favor of the sender: the sender can be sure that only the specified recipient will receive the message, but there is no guarantee to the recipient that the sender is who the sender says she is. It’s perfectly understandable that the original creators of email saw no problem with this, because this is how regular mail works—we still don’t know who sent the anthrax.
But, whereas regular mail has survived for hundreds—maybe thousands—of years with rare troublemakers, in just several short decades electronic mail has gone from birth to 24-hour life-support, thanks to its most prolific users: Spammers, Scammers, and Phishers. They take advantage of the naivete and good-heartedness of our trusting ancestors to flood our Inboxes with junk, scams, and viruses. They operate in an Inbox-centric universe that was created in an era when only Good existed, when putting something into a person’s Inbox was a matter of sacred trust that everyone respected. But now the innocence is gone, evil runs rampant, and every Inbox has become an open dumping ground for whomever cares to dump.
But the technology already exists to solve this problem, and it’s high time we start using it. We already have a technology that lets the recipient be sure that the sender is who the sender says she is, and it’s almost as popular as email. It’s called “The World Wide Web”, and it’s about time we started using it to solve our email problems. The WWW has been “Outbox”-centric all along: a sender (publisher) sticks a message (file) into her Outbox (web server) and the intended recipients (surfers who know the URL) read it (request it with their browsers). Why not apply this paradigm to email also? And to make things easier on everyone, why not just go ahead and apply the protocol too?
Thus, Hypertext Mail Protocol (HTMP) is born, or Stub Email for short (read “stubby mail”). The implementation path is easy, seamless, and will only take a few years to complete—maybe less; here it is:
Step 1: The early adopting end-user installs an HTMP plugin for her email client. The plugin has only three settings to configure: HTMP Outbox URL, HTTP BASIC AUTH username, HTTP BASIC AUTH password; and performs only one simple two-step operation: whenever the “send” button is pressed, the plugin first takes whatever email message would have been sent—headers and all—and HTTP PUTs it to the HTMP Outbox URL with an un-guessable UUID appended to the end of it, using the HTTP BASIC AUTH username and password to authenticate if challenged by the web server (it is assumed that the PUT operation is performed over a secure channel, such as SSL); second, the plugin replaces the original message with a well-formed email message that has many of the same headers as the original message (To, From, Cc, Subject, etc.), one additional header to specify HTMP compliance (HTMP-Version), and a message body that contains only one thing: the plain-text, fully-qualified URL of the original message that has now been PUT to the WWW. So the message that is actually sent via SMTP to the would-be recipients of the original email message is most likely much shorter than the original message, and contains only a (WWW-accessible) link to the original message; we’ll call this message the “Stub Email” and the link it contains the “Stub” (or “Stub URL”). Recipients of a Stub Email—whether or not they or their email clients have any idea what a Stub Email is—receive a perfectly readable and actionable message, one that contains a URL that they are obviously expected to retrieve. Thus, transition to widespread Stub Email use is seamless.
It is assumed that the Stub’s domain name, perhaps combined with something in its path—when viewed by the recipient—will convey enough information to sufficiently satisfy the recipient that the message is worth retrieving, i.e. we’ll finally have a use for all those .name domain names we bought. During this initial early-adopter phase of HTMP implementation, whether or not a message is worth retrieving is a judgment that each human recipient makes on her own. In later phases, this decision can be made automatically based off of a personal Stub Whitelist (SWL) stored in each person’s email client and maintained individually. A person’s SWL can be shared with friends and/or sync’d with trusted SWL servers, as well as contain listings based off of domain only, partial path, or other matching scheme. The SWL mechanism need not be part of the HTMP specification, but can be left open for networked individuals and email client providers to define independently or in specifications separate from the HTMP specification.
One thing that the HTMP specification should contain—for the purpose of limiting abuse—are certain restrictions on the length of the Subject and syntax and semantics of the Stub URL, such as maximum length, presence of a domain name and not just an ip address (for human accessibility), an encoded-but-human-decipherable sender email address in the Stub URL path, etc. Violators of these rules can be automatically bounced by ISPs using Stub Blacklists (SBL), or automatically deleted or demoted by individual email users using their personal SBL (analogously to SWL).
Step 2: The HTMP plugin is improved to modify the retrieval mechanism of the email client to implement various schemes of SWL and SBL. For whitelisted Stubs, the plugin can automatically retrieve the original message and replace the Stub Email with it, as if there were no such thing as HTMP. For non-whitelisted Stubs, upon viewing—or, depending on user settings, retrieval—of the Stub Email, the plugin can cause the client to display the Stub URL and allow the user to choose to either ignore the email, blacklist the Stub, or retrieve the original message. During this second phase of early adoption, non-Stub Emails are left untouched by the plugin and thus treated normally by HTMP-ified email clients.
Step 3: Popular email servers begin to support server-side SBL.
Step 4: Popular email service providers begin to support HTMP in their web-based email clients, providing PUT-able web directories to their subscribers.
Step 5: Adoption among end-users becomes widespread, and more and more people begin to configure their email clients to automatically filter out and delete email messages that do not contain the HTMP-Version header.
Step 6: The latest versions of all popular email clients natively support HTMP.
Step 7: Popular email service providers begin to reject non-HTMP-conforming email messages.
Step 8: The days of disconnected, free-floating, kiss-and-wave email messages is over. If you want to say something substantial to somebody, you have to tell her exactly where to find you. Non-HTMP-conforming emails fizzle out because nobody’s reading them. All Spammers, Scammers, and Phishers seek shelter in countries you’ve never heard of and continue to find ways to send out trillions of junk emails. But all the unsolicited messages are super-short Stub Emails that link to domain names you’ve never heard of—or never cared to hear of—and you can complain to ICANN if they bother or scam you, and ICANN can cause their domain name to be redirected to a wholesome website displaying helpful Internet safety tips—like not to talk to strangers or click on strange links.
And thus the Spam Problem is solved, spammers can go back to being run-of-the-mill street thugs, and we can hire more cops to protect the streets rather than having to put up with cluttered Inboxes.
Not only does HTMP force bad people to find other things to do, it also allows good people to do things they couldn’t do before. For example, with HTMP, when you want to email your friends and family five photos of your newborn baby, you don’t have to worry about them muttering under their breath as they wait unusually long for their email to download—not knowing whether or not their waiting will be worthwhile. Instead, they’ll get a short Stub Email (read “short stubby mail”) that downloads instantaneously, has a Subject of something like “Hot out of the oven: 7 pounds 3 ounces!!!”, and a Stub perhaps like this:
http://nathancheng.com/[email protected]/lskjdfLJFLdoifjjpoiuc.eml
Your friends and family can immediately be sure that it is a message from you, and can retrieve it should they choose. Using a HTTP HEAD request, their email client could also tell them how large is the original email that is waiting for them, and based on that they can decide to retrieve it now, later, or not at all.
I can go on and on with many other interesting new possibilities that HTMP brings to email. For example, the HTTP DELETE command can finally be put to good use: how many times have you hit the “send” button only to have a sinking feeling in your stomach that you just did something horribly wrong? Well, now you can correct your mistake by quickly issuing a HTTP DELETE command to delete the message from your HTMP Outbox (hopefully you didn’t say anything stupid in your Subject line, because even HTMP can’t help you with that); or, if you’ve got time to redact, you could simply PUT a new message in its place. Another example of a new possibility is the ability see who retrieved your email and when (ever heard of log files)? But the log file only lists the ip address of the request, you say, there’s no way to tell who actually retrieved the email, you say. Well, it’s already a given that you’ll have BASIC AUTH protecting PUTs and DELETEs, who says you can’t also have recipient-specific BASIC AUTH for your GETs? Then you’ll know. Another new possibility: every HTMP Outbox, by convention, could also function as a blog: when a smart-aleck script kiddy tries to retrieve a directory listing of your HTMP Outbox, he can instead be treated to an index.html file that lists HTMP Outbox entries that you consider to be public; or it could simply be convention that the “/public” subdirectory of every HTMP Outbox is open for all to view, and you can put your blog entries there. So send someone an email, and they automatically know where to find your blog. The possibilities are endless, but I will stop here, for now.
Thanks to Robert Taylor for reviewing my idea, calling it “Hypertext Mail Protocol” instead of the ridiculous name that I had proposed, helping me think through it, encouraging me to publish it, and editing the final draft.
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
This is store and retrieve. I proposed that scheme under the name of “weemail” two years ago. You do not need the web. You can also use SMTP/FTP. It was the system I first used in 1977 on Xerox machines. I think (and I am not alone) this is the only solution to control spam because it is architectural.
However, we spent time on considering its implementation (I had a site in French for reporting that). Your proposition works, but it can be implemented better in using “weemail servers” and weemail more sophisticated format (I consider your stub mail as a subset of our weemail: same approach but free additions in the mail sent, and more complete architecture). Also considered the OPES additional possibilities (Open Pluggable Edge Services).
An open format permits to give a better subject, multilingual description, dynamic mailing lists, autofilters, etc. etc.
Incidently it may help increasing the spam noise. But it permits to decrease its interest for the spammer.
The problem is to find someone to technically document and develop it.
BTW the traffic reduction is substantial. But one BIG objection consistently received from internuts: sender knows if destinee read the mail and when. This is considered as a chocking idea. It can be is a major privacy violation.
NB. You can propose a very simple other solution to another problem, along the same lines. HTWHOIS.
I am interested if you carry some work on this.
Do you mean a “BBS” or Bulletin Board Service, where you login to read the bulletins and mail, and also create more bulletins and mail?
Hmmmm, what a novel idea!!!
How are you going to deal with the Yahoos, AOLs, Microsofts, Googles, etc, who are beginning to extract value from their accumulated user databases by offering them up (for a cost) to direct marketers? There billions to be made there.
Remember SPAM exist because there is a market for it. Just like cocaine, heroine, beer, Jack Daniels, sex and Petroleum!
Do you realize one of the largest markets of the telecomputing society is the porn market? What are you going to do to satisfy the “Daddy” market who still wants to be anonymous in reading and creating mail?
What most vendors and people want is to simply control the abuse.
Anyway, you can control your spam. Just don’t be promuscious and use a online hosting service that caters to controlling abuse and is not simply open-ended to collect names.
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
I haven’t had enough time to complete some catch-up studying before answering JFC Morfin’s very helpful comment, but I will answer Hector’s right away:
I was a very heavy BBS user back in the 80’s and early 90’s, and I do not see many similarities between that and HTMP. If you’re in to drawing similarities, I would say that the similarity between HTMP and blogs is much stronger than the one you are suggesting.
As for “the Yahoos, AOLs, Microsofts, Googles”, I fail to see how HTMP will adversely affect any of their current revenue streams.
HTMP will not end spam in the sense that you will never receive an unsolicited email again. But HTMP will empower you to know for certain who the solicitor is, and it will make client-side blacklists much more practical (because you don’t have to retrieve the entire contents of the email message before rejecting it). That shouldn’t stop the “legitimate” spam that makes our economy tick, but it should help in reducing the more illicit types of unsolicited emails.
As a newbie to this list, at first glance this idea sounds pretty good, and I think I’d like to be one of the early adopters.
But first I’d want to try to understand it a little better. I wrote something in a sort of “thinking on paper” exercise, but it exceeded the 6000 character limit on comments—even if it hadn’t I think a wiki or similar would be a better place for such discussion.
Is there a place (a wiki, blog, mail list, or forum) where the idea can be discussed in more detail? If not, I can start a page on WikiLearn and point to it from here.
Randy Kramer
PS: My original reason for joining circleid was to make a meta-comment after reading a different article—I wish the comments to all articles were in the same font size as the article!
First of all, I wouldn’t have to “re-zoom” the page to read the comments. Second, there’s something vaguely disturbing / annoying / disrepectful (?) / dismissive (ahh, maybe that’s the word I’m looking for) about displaying the comments in a smaller font size.
Randy,
Thanks for the inputs here:
With regards to a wiki, CircleID has the Backgrounders section which could potentially work well here. Feel free to give it a try.
The font size for comments is set here to be same size as main articles—please send a feedback if you’re having problems.
Nathan,
I don’t know what your direction is with this proposal: whether you intend to make a scholarly study of it, an implementation of it, or whether you were just running it up the flagpole to see if anyone would salute. Given the nature of your blog, I’ll take a wild guess at the latter.
The basic idea of making email a “pull” rather than “push” exercise (storing it at the sender’s facility until explicitly requested) has merit, architecturally speaking. The earliest citation I know of which advocates a switch to a pull-based architecture is IM2000. IM2000 is not a complete idea, but if you’re going to advocate a pull-based system, you should at least be familiar with it and the questions it raises. Some further interpretations of IM2000 can be found at im2000.org. In my July 2001 BSc Honours thesis I described a minimalist means for incorporating “pull” into the existing SMTP architecture. HTTP was one of the protocols I considered, but eventually settled on POP3 for various reasons. There was something similar presented at SRUTI 2005, for which see DiffMail.
Having said that, your idea is in severe need of a costs/benefits analysis. For starters, it’s not going to be any more effective than SPF in stopping spam, so it’s a bad idea to sell it as a spam cure. Spam can’t be differentiated from normal mail architecturally, since spam is about violation of social contract—sending mail against the wishes of the recipient. It pays to give a very sober and precise evaluation of the benefits offered by any architectural improvement, since there are going to be no magic bullets here, just a series of beneficial refinements. Spammers are tenacious, and won’t give up at the first hurdle you place in front of them. I once suspected that solving the open mail relay problem would effectively end spam.
In short, I can see many costs associated with your plan, some new pitfalls you haven’t considered at all, and not as many benefits as you’d think. Some of the basic concepts are sound, but there’s a long and arduous road between sound basic concepts and a sound complete design. I say this as someone who is in my third year of a PhD candidacy, attempting to design such a system.
Brett, this is a very interesting input. Nathan, why not to start a mailing list on the matter. May be this would help us all. This could start a open use effort?
I would be quite interested in the problems raised by Brett.
I fully agree that it is not a way to fight spam, but I think it is the only way to make spam lose interest in the way it works today. But as I noted it may increase other pains unless it is well addressed.
I am also interested in understanding why POP3. Seems quite reducing?
I have taken a look at the previous works to which JFC Morfin and The Famous Brett Watson referred me: weemail (in French), IM2000, and DiffMail. Before I say anything, let me just say that the discovery of these three previous similar works is to me an encouragement and confirmation that I am thinking in the right direction. I am sorry if I am encroaching on “PhD territory”—I’m not trying to steal your fame, just trying to express what I think are good ideas and effect change.
So, yes, these three works are very similar to—if not entirely the same as or more comprehensive than—mine. The most developed of these—and the only one under active development—is DiffMail, or “Differentiated Mail Transfer Protocol” (DMTP); it is formally presented in an Internet Draft, which was published January 1, 2006. DMTP is more sophisticated than HMTP in that it uses—to use my terms—the “Stub Email” concept only in certain cases (unknown senders), and in other cases uses regular email messages.
The primary weakness of DMTP is that implementing it will require modification of all participating MUAs and MTAs, so using it is not the individual choice of an end-user, but the result of a contract between all participants. Also, with DMTP, it is the email server that must create transparency for the email client by storing original messages while stubs are delivered to recipients using a new SMTP command; but the transparency is not complete, because it is the email client that must request the original message from the email server using a second new SMTP command. So all the millions (billions?) of email users and providers have to agree to switch over to DMTP; if they don’t, email users of the world will be split into two distinct groups, it being possible to experience the benefits of DMTP only when communicating with people in the DMTP group.
Perhaps the authors of DMTP have come up with a solution for this somewhat crippling implementation defect, but I have not been able to find it on the WWW.
So I believe HTMP—though perhaps slightly less functional that DMTP—is more likely to succeed because it is something that can grow and spread the way all successful movements grow and spread on the Internet: virally. As soon as an email client plugin is available, individual early-adopters can begin using HTMP immediately, and still communicate via email (even HTMP-ified emails) with all the non-adopters. And HTMP doesn’t change SMTP at all, so existing email servers won’t even know that they’re being used by HTMP-ified clients.
JFC Morfin is right: my proposition could be considered a functional subset of weemail—a simplified weemail, if you will, and as far as I can tell, he proposed it in 2003. So he gets the academic credit. But I think “HTMP” and “Stub Email” is a better name to call it.
In the end, HTMP and DMTP accomplish pretty much the same thing, but I think HTMP takes a more realistic approach.
There is definitely much more to be said on this topic, by me and others. For example, I have discovered a truly remarkable solution, that it is possible to solve the privacy issue with HTMP/DMTP/weemail/IM2000, but this comment box is too small to contain it. I will share it with you all another day.
I missed a “not” in the last sentence of paragraph 3 of comment 8.
Here I will address and outline solutions to the primary objection to HTMP I have seen so far in comments here and elsewhere.
Objection: The fact that a sender will know that a receiver has read an email message is a major privacy violation, will inform spammers that an email address is active, and is reason to consider HTMP dead on arrival.
Solution:
Keep reading, because I think I have a solution to this problem that you will like.
The vast majority of email users, though perhaps concerned about “privacy” in a general sense, do absolutely nothing to protect themselves even with the current Inbox-centric email paradigm. As proof of this, please consider the answers to the following three rhetorical questions:
How many users of POP3 and SMTP use unsecured channels to transmit over the Internet their login information in clear text, thereby making themselves vulnerable to anyone caring to sniff the channel?
How many readers of email allow their email clients to retrieve externally referenced resources (like images)by default, without any kind of prompt before doing so, thereby informing spammers that their email addresses are not only valid, but that the recipient has actually seen the email message?
How many readers of email have their email clients configured to automatically send out receipt notifications?
The answers to all of these questions are obviously “the overwhelming majority of the total”. So for the overwhelming majority of all email users, on the issue of privacy, HTMP is all upside straight out of the box.
Now let’s address the privacy concerns of the complementary minority who currently use only secure channels to send and receive email, never retrieve external resources referenced in an email message, never send receipt notifications to senders, have fingerprint-protected screen savers triggered by pressure sensors on the palm rests of their keyboards, and take all necessary precautions to prevent people from looking over their shoulders or bugging their cubicles.
The primary way to solve this problem is to require all mail transfer agents verify the validity of all Stub Emails they handle by actually GET’ing the Stubs. Generally speaking, sender log files would then become less valuable because the logs would always show that messages were retrieved, and most likely multiple times. Mail clients wishing to obfuscate the sender’s web server log file even further could use the HTTP User-Agent header to identify themselves as a transfer agent rather than a client. In order to aid the quick adoption of HTMP (this would be the only part of the HTMP specification that would require a change to existing mail server technology), perhaps a transitional HTMP specification could make this a “SHOULD” or “MAY” requirement, and once adoption has reached a significant milestone, the specification could solidify this as a “MUST” requirement.
Immediately we see that this requirement on transfer agents to GET the Stub will reduce the positive impact that HTMP could have otherwise had on the volume of Internet traffic. However, this could also be seen as a good thing because it will actually drastically increase the bandwith requirements of the sender, while still reducing others’ bandwith requirements from current levels. To see this, consider the following:
If you send an email message of size S from your email client A and it passes through mail transfer agents B1…Bn before reaching its final destination email client C, the total bandwith requirements T(P) on each of the participants is as follows:
Currently: T_c(A) = S, T_c(Bi) = 2 * S, T_c(C) = S;
HTMP without obfuscation: T_wo(A) = s + S, T_wo(Bi) = 2 * s, T_wo(C) = s + S;
HTMP with obfuscation: T_w(A) = ( ( n + 1 ) * S ) + s, T_w(Bi) = ( 2 * s ) + S, T_w(C) = s + S;
where s is the (very small) size of the Stub Email.
From this it is evident that with the log file obfuscation requirement, the increase in bandwith for transfer agents and the receiving user agents is extremely minimal, whereas the increase in bandwith for sending user agents is massive. This is a good thing. In fact, this is a wonderful thing, because it will increase spammers’ bandwith costs enourmously while keeping everyone else’s just about the same. So instead of crippling the HTMP idea, I submit that the solution to the privacy issue is actually an even better reason to hope for the quick implementation and worldwide adoption of HTMP.
A second, less realistic method that the minority mail recipients could use to protect their privacy is to set up “mail reading proxies” (MRP) or “distributed mail reading networks” (DMRN): everytime you want to retrieve the original message from a Stub URL, you simply paste it into an MRP/DMRN website, and it goes and gets the message for you. Of course, this will still alert the sender that someone retrieved the message (but with HTMP web log obfuscation in place that won’t be useful information), but it won’t reveal to them your real ip address. Look no further, such a network already exists here and there are probably many others like it.
The third part of my solution to the privacy issue is unsavory in comparison with the first two, and is not something that I would necessarily advocate, though I think it is a point that needs to be made: HTMP makes spammers susceptible to DoS and DDoS attacks by people who are upset that their privacy has been disturbed. In order to defend this weakness, spammers will have to invest in expensive network equipment and bandwith, which will even further reduce their population and profitability.
If there are other objections to HTMP, I will address them as time allows.
Hi Nathan,
While you are a user, we were writing the software since the 80s to make it happen. Offline Mail systems such as QWK, OPX (Silver Xpress), Blue Wave, RIME, UTI, etc, were all par the course. Fidonet systems were similar in concept as well. Another term for this by Fidonet Systems were “Point systems” is what we called them in the automated Frontend market.
The major difference today is that in the past, you had to join the “social network,” and further more, you had to be a compliant system. In other words, to join, you had to show that your client software was a) compliant and compatible with the standard, and b) that you were available for contact at a mininum hour we called ZMH or Zone Mail Hour.
Imagine if every SMTP system had to be “certified” to be compliant SMTP system. That you has to “register” with some entity before you were allowed to submit mail into the internet backbone? Imagine if before you were allowed to have a MX record, you had to be sanction first by some 3rd party governing affiliation before you can enter your records into DNS?
So it was practically impossible to bombard these early frameworks with anonymous spam or the like because it was membership only.
The problems of today can be charted in the evolution of the software:
version 1: Strict User authentication
version 2: Allow for Alias Names for the “daddy/porn” market
version 3: Allow for anonymous names
version 4: the internet and news
The irony?
version 5: More version 1 features!
So the more things change, the more it remains the same.
A good example for most people to see this is that early on, the biggest BBS systems, like the AOL, PRODIGY and CIS, did not have SPAM problems. That changed once they open the access to the users providing internet addressing, and with a relaxed SMTP protocol in the area of validation, the problem grew to levels we have today.
It probably won’t. But the new business model is to give marketers access to their growing user base for a fee, It doesn’t matter how you can get the matter to them. The question is it will strict mail access. If it is restrictive, you won’t find a high adoption rate.
Empower who? The user? Or the system? We are talking about implementing a new level of authentication and verification. HTMP or SMTP or any other authentication idea will have to deal with the system that has to do this work for you.
If you are requiring a “login” to submit, that should be good enough for SMTP software. If you requiring a client to be 100% compliant, that would be good enough for 80% of the abuse on the network.
As the old saying goes, “All good ideas will work, if everyone used it.”
The question is to prove to the software writers why it will work over applying the same level of software compliance and authentication within the current framework?
Other than that, don’t let me discourage you.
Hector Santos, CTO
http://www.santronics.com