Slashdot Mirror
Replacing SMTP?
dousette asks: "In reading over one of the RFC's governing the SMTP protocol, and other RFC's as well, it's interesting to note that you see some big names and big companies from time to time. With all the loopholes in the current SMTP specification, is it possible for the Slashdot collective to come up with another one? Would it stand a chance in making it into a standard, or do they just listen to Cisco, AT&T, etc? I realize that a lot of people have a lot of ideas how things should be done (and they haven't been shy about posting them to Slashdot), but has anyone tried to write the RFC for a replacement protocol? As a side note (where I won't be shy about posting how things should be done), if there were a replacement trusted protocol, one could have mail received via that protocol bypass spam filtering, id checking, or whatever checks might be in place (saving processor cycles, etc). The regular checks could still be done on other mail received via the 'older' SMTP protocol. If more and more ISP's make use of this, SMTP could be gradually phased out... or if you are one for a sudden cut-over, just cut to the new one at the same time as the IPv6 upgrade!"
Why doesnt the new implementation use the evil bit. It the server is written by m$, or running on an m$ platform it sets the evil bit. If its running under linux it doesnt set it and ignores all mail comming in using evil bit! :P
Simple really :P
"is it possible for the Slashdot collective to come up with another one?"
SlashDot Transfer Protocol - Essentially, the way it works, is the information is posted on one single, easily crashed server. Then, this information is linked to by Slashdot. Then, said server is taken down. However, 1,000 other posters will have mirrored it by then, therby helping in the "transfer" of the information.
Jason Lotito
I don't think the name needs more work. We can just call the new one SMTP Hi-Speed and the old one SMTP Full-Speed. If the USB people can do it, so can we.
With all the loopholes in the current SMTP specification,is it possible for the Slashdot collective to come up with another one?
To start with, I would suggest a detailed look at RFC 2549.
The Standard for the Transmission of IP Datagrams on Avian Carriers described therein is fairly broad and could prove a feasible alternative to current email delivery mechanisms, specifically SMTP.
The reason I think it hasn't taken off since 1999 is that it proposes to completely replace IPv4 (like IPv6). Maybe it would be easier to first phaseout SMTP over IPv4 for now, rather than the whole IP layer.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Like IPv6? You mean most things will already be there but no one will support it, no one will care apart from a few and no one will implement regardless of how hopeless and disastrous the current implementation is?
Ah yes, like IPv6 indeed. You know, I'll send a shiny mail delivered by SMTP2* over an IPv6* internet about the release of Duke Nukem Forever* to my gaming-addicted girlfriend* on the day SCO coughs up some evidence*
Note:
* = May or may not require divine intervention.
Hate me!
So... instead of a friendly hello, the mailserver should instead answer for an incoming connection request with a gruff "nuqneH!" (Klingon for "What do you want?")
or SMTP Mail Transport Protocol in the GNU tradition..
Can't we use Karma?
Simple premise - everyone in the world signs onto the 'KarmaMail' service, and get to send mail at "1". Once enough KarmaMail users validate the user's email as being legitimate, their Karma goes up. Registered users can also complain about a spammer, thus making their Karma go down. Marking email messages as 'urgent' requires a higher Karma. Users with a negative Karma (>= -5?) can only send at '0'. Users with a very negative Karma get booted off the system.
Then individual users can use Karma plus Whitelists to decide who to read mail from. Whenever a server receives mail, it checks with the central KarmaMail repository and inserts the user's Karma into the mail headers (optionally, Karma can be assigned to the *server* as well, eliminating the open relay problem). The header can then be processed by the mail reader.
Maybe someone would care to expand this idea further to clear up the many loopholes I've left?
You can accomplish anything you set your mind to. The impossible just takes a little longer.
> I come to this discussion as an expert
/. that's posted by people who forget to point out to us how knowledgeable they are.
Gee whiz! Better mod this one "+10: Self-Proclaimed Expert" to distinguish it from all the other stuff on