Sending mail. It sounds so easy, you make a connection to port 25 and dump the mail on that server. That part is not so hard to do. Extending that to multiple smtp-servers is also doable.

But then it gets difficult rapidly. Users want authentication possibilities. LOGIN and PLAIN are not so difficult, but when it comes to CRAM-MD5, GSSAPI and friends, you don’t want to write it from scratch. And when there is authentication, you better do something with encryption as well. TLS and SSL have been made easy due to QSslSocket but you still have to incorporate it into the class.

So we (Mailody) decided that continuing this home-brew class was not the way to go and looked around and found MailTransport. Sometime ago Volker Krause extracted the mail sending part from KMail and put it in a separate library. After some quick and dirty tests we decided that was the way to go. The library was relicensed for the most part and moved to kdepimlibs. I added a new class which can test which authentication mechanisms are supported by the server and ported some bits.

Last night Volker changed KMail to also use MailTransport. So now KMail, Mailody and KNode are all using MailTransport. That means that when you add or change a smtp-server in Mailody, it is also available in KMail and KNode. I love this. It is a huge gain over configuring the smtp-servers in three different applications. And it is an easy to use library so any application can include these settings and support outgoing emails.

But it also brings in some things to consider. Usually when something does not work, you file a bug and work around the issue (humans are good in that) or you can not live with the bug and you search for another application. But as soon as you start using libraries for more applications it is also dangerous. Imagen there is a mailserver which does not work correctly with MailTransport, you can not change to another application as that application is also using MailTransport.

Another problem is the bugreports. Bugs for MailTransport will be filed against the host application. That means that duplicate reports are reported against different ‘products’ and that means they are hard to find and probably means I’ve to follow KMails bugreports to scan for bugs in MailTransport. On the other hand there are more interested parties in the bugs so there is a chance that they will be resolved faster.

But in the end the user wins. They have the same smtp-settings in different applications without entering the same settings over and over again.

We all know that all the infected Windows computers are forming a large network which is used for sending spam. What I did not know up to know how all those computes are managed.

That has changed. We can now have a look at the front-end of a botnet, look at this blog.

I must admit the interface looks very good. You can send spam emails from any random country on any random time even with counters for new bots, etc. It underlines the efford that has gone into it. That can only happen when sending Spam is delivering enough money.

It also underlines my statement that e-mail is rapidly loosing reliability and will probably become unusable somewhere in the future.