The Simple Mail Transfer Protocol is the fundament of electronic mail on the Internet.
It was created in better times when hosts were trustworthy and the Internet was kind.
Unfortunately this has not remained this way, leading to so many problems that
people are even turning to closed proprietary alternatives to have SPAM- and disturbance-free messaging.
E-Mail is a hopeless case, and the process of its demise is already in action - Young people are flocking away to commercial social networks, because they find sending messages on those "less formal" and ironically more reliable. Even in serious business, messaging in Xing or similar has found its place.
Here's a disclaimer that comes with some mails.. see how low the expectancy has gone of what the e-mail service is supposed to provide:
- Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission.
This just as an introductory note. See also psycmail for e-mail notification into PSYC. Read also about SPAM in PSYC. Now let's get to the techie stuff.
Contents |
net/smtp/server in psyced
psyced comes with a little SMTP server implementation which has the purpose of accepting short real-time like e-mail messages and delivering them to the intended recipient via PSYC. It rejects anything that comes with attachments, isn't plain text, large message sizes or even too many lines of text, as those messages cannot be intended for a chat-type recipient.
Addressing people happens via a tilde prefix in the mailto:~nick@serverhost syntax as in mailto:~person@example.net. The _flag_disable_prefix_person_SMTP tuning lets you disable this prefix character, making regular user@host accept e-mail.
For places you're expected to use mailto:*place@serverhost as in mailto:*gnu-announce@example.org. In combination with mailcast places you can create newsfeeds which are fed by real-time e-mail alerts instead of asynchronous RSS. See Create Places for details. In fact any chatroom can receive e-mail if you let it (they just won't store it like mailcast does), so this elementary e-mail to multicast gateway has all kinds of potential. Try it out!
Additionally you can use SMTP_ALIASES to define recipient names without prefix character. See below.
For an alternative designed to implemented behind an existing SMTP server like Postfix, see also LMTP.
Spam Filter for Hopeless Addresses
This radical approach makes up for a very simple but effective spam filter which rejects most unwanted information. Of course it also rejects regular e-mails, so you will not want to send your regular communications to it, but it works just fine for those e-mail addresses you essentially gave up using a couple of years ago. If an old friend sends you a "hello, does this still work" on one of those, you will receive it. If she sends you a couple of lines more, she will receive a mailer-daemon reply containing a warning, that the message was too long. Fair chance of her trying again, whereas spam creators absolutely ignore this for now. Of course should this technology get more popular, we will have to refine it some more.. ;)
My real life experience with this set-up is as such: I still get spam on my chat screen once or twice a day, which disturbs a lot less than in my real mailbox. In exchange I caught one old friend trying to contact me, which otherwise I would have lost in spam folders. Other spam killer solutions may be more effective, but in this case I absolutely wanted to lay hands on the SMTP reception bit myself. The source code for net/smtp/server is simple and straightforward, so if you want to try your own strategies, it's great.
And here's a case of a friend trying to contact me using a wrong address. He got curious by the funny error messages and ended up sending it manually. ;D
(mailto:c...@.....com) (MAIL from mail... to ...) SMTP per Hand Hallo Carlo, Wie geht's? Lange nichts mehr gehört! Bin gerade frisch aus Paris eingetroffen und habe wieder Stellung in Berlin bezogen. Was macht die Kunst? Melde Dich mal! Mehr geht nicht wegen Multi-Line 220 und 254 Insufficient storage for long messages. C...
Installation
To be able to use this gateway you need to have an IP address with unallocated port 25, so you can let psyced listen to it. See the installation procedures on how to set this up.
By using #define in your local.h you can tune the behaviour of the SMTP server:
- #define MAX_EMAIL_LINES <number> lets you specify how many lines an e-mail is permitted to have to be forwarded to the recipient. The default is 9.
- #define MAX_EMAIL_SIZE <number> is the limit on amount of bytes permitted. The default is 360.
The server keeps a log of rejected e-mails in log/SMTP_SPAM and a log of accepted ones in log/SMTP_OK.
Currently the SMTP server only accepts messages for local users or places. No relaying to remote entities. You may however define aliases that forward recipient names to a different user name, like this:
#define SMTP_ALIASES "hostmaster" : "~BuGless", \
"mailer-daemon": "*admin"
SMTP Instant Messaging
It not only accepts MAIL, but also the lesser known SEND, SOML and SAML commands of SMTP which were originally conceived to implement instant messaging in SMTP. So if you really want to chat using SMTP, go ahead!
Futures
These are possible ways to improve what psyced is doing for SMTP now:
Real SPAM Filtering
With the fine process forking facilities of ldmud it is possible to extend the filtering process by also piping messages through a spam filter daemon running alongside psyced.
Relaying to Remote Entities
You could implement a parsing syntax which permits to receive e-mail to be forwarded to remote PSYC instances. This could introduce security aspects, so for now we are limiting reception to local entities only. Those local entities can still forward using /set id <uniform>
Parsing Special Formats
We could implement the analysis of messages coming from popular alert services like Google or Myspace, extract the interesting bit of information (quite often just one line, as these alert services only exist BECAUSE there is no messaging standard.. good old BITNET had one, so it never had to pollute e-mail for this) and forward it to the recipient(s) in a most palpable way.
Using the mailcast feature described above you can forward those mails to a programmable place, then do all the dissection and parsing you need before multicasting the meat to your audience.
E-Mail Delivery via PSYC
The way SMTP is losing popularity to closed circuit web-based message systems (several mentioned in Centralistic) is yet another scary development against open standards. We should probably extend psyced to be able to handle e-mail-like multiple line messages better, and improve its File Transfer abilities so that at least alternatives are available. This however creates a whole new lot of issues for client programmers. The psyced server is ready to handle larger messages, but which clients are? Some Jabber ones? Do they thread? Do they keep folders? Etc etc etc. Anyway, for a lot of applications, especially one-to-many delivery, e-mail delivery via PSYC may be quite a plus. One next step to actually implement this would be to define a protocol switch extension much like we have done for XMPP.
Integrating Future Mail Technologies
And then, yes, we should start seeing both the web interface as the classic mail application as client interfaces to psyced. We already have a simple Post Office Protocol implementation in net/pop (we even have NNTP). We can learn to accept mail for delivery via any of PSYC, XMPP or SMTP - the latter two being a bit harder to safeguard from SPIM/SPAM - but this approach could slowly open up a way out of the technological mess that e-mail is today, without completely turning to proprietary messaging, which is the way the net is evolving right now, and you don't want your kids to ask, where were you when they took away open protocols from the Internet? ;)
Related Work in Replacing SMTP
As discussed above, PSYC could become a technology to step in the shoes of SMTP, even if only for a subset of humanity. Other projects have similar interests, but differing attitudes at solving the problems. The main disadvantage of the PSYC approach to these is, that there is still so much to be done to get anywhere. The typical advantages are multicast routing and the fact that so many other applications like primarily IM and chat are already available. Also it is about time to reduce the number of addressing schemes and social modeling for people rather than have one each for every application, and in that field PSYC with its programmable UNIs has some clear strengths.
Petmail
Uses public key hashes as addressing mechanism, but since that isn't pragmatic it allows using "phrases" as human identifiers stored in central address servers. The bad news, you essentially need to keep all address servers in sync, or somebody may steal your identity "phrase" which is bound to become an oligarchic structure like IRC networks. Also Petmail has no clue about multicasting.
Internet Mail 2000
Just a theoretical construct by the illustrious Mr. Bernstein, which suggests to leave actual content on the sender side for receivers to retrieve it only when they really want it. Defeats smarter distribution schemes like multicast and isn't all too pragmatic when your time on the internet isn't endless or paid flat - Instead of having a document at hand you first have to download it. Essentially it's more like exchanging files in an IM/IRC application. But it has its strong sides, too.
CAKE (Key Addressed Crypto Encapsulation)
At first I thought it would provide a replacement to the job of DNS, but if it uses centralized servers, that's not a solution. In fact I can't find any technical details that tell me exactly how a user's pk hash is supposed to lead you to his current address. Anyway, the intended primary application of CAKE is a mail replacement, too. CAKE is particularely serious about using the user's hash as an addressing medium rather than only using it for authentication, but I rather see the disadvantage of accountability with that: If it is completely ensured that you were the author of a message, it can be used against you in court. Would the hash in addressing make it easier to prove, that you are indeed the person addressed by it? Not sure.
Opinions
From The White House email controversy:
- Most email systems are poorly factored information because they duplicate a message for every last reader of a given message. It would save a lot of space and traffic if a given attachment or message was stored in one and only one place rather than replicated en-mass.
- Of course, the security for centralizing items properly without being read by non-recipients complicates things, but shouldn't be a show-stopper. Also, the retainment date cutoff of the central server and individuals may be different, which makes some people want to be pack-rats if they can't trust the central system to keep stuff long enough.
- A related problem is that people often CC copy everybody and their dog to cover their butts. Thus, we get bajillion messages that don't relate to us.
- The whole idea of email needs a big rethink. It's become a jungle monster.