My first package. A small, but powerful Emacs-relative, with all those uneeded things stripped which makes emacs fat. Maybe these days especially useful for small memory devices, as it gives you emacs-likeness for the price of nvi or ae. I have no idea how well it works in a real utf-8-environment.

A greylist-milter which makes running a mailserver somehow possible for me. it keeps away about 2/3 of spam, which leaves me with only 400spams/day. I already have two contacts who want to help with that.

No news is good news, but nn is better. This is a USENET reader, for those people who grow up with Webforums and Blogs: This could be still the most effective way to celebrate flamefests, gather information or communicate with people sharing same interests. And nn has in my opinion the best UI for it, and makes it easy and fast to find interesting articles and skip others. Well, Upstream Development has ceased to exist around 1994. I think if no one takes over, this package will become finally useless when IPv6 gets widely used (right
after the release of 'Duke Nukem Forever') and it also doesn't deal well with non iso-8859-1-charsets. So best for this package would be to rewrite it from scratch (my dream: message/mime-handling/threading from mutt, scoring from slrn, and UI from nn) because the User Interface is much better than those of all still alive Newsreaders i tried.

This is my most popular package, which makes it possible to share one mouse and keyboard over many computers and displays. (It is available for UNIX/Linux, Windows and MacOS) This is a very very useful software, and i use it permanently. Sadly the Upstream Development mostly ceased to exist, and so i put this to ITA (instead of ITH) because many Debian-Users use it according to popcon. This software should be taken over by someone who is able to help Upstream. There is a RC-Bug, which caused the package be pulled from testing.

Interesting is that while filing those ITH/ITA all the same day, i only got responses for the packages which scores lowest in popcon, (24 for milter-greylist, 1196 for synergy).

In my ongoing attempt to investigate and fix problems of our mailinglist-server, i found that we only had a working bounce-detection for lists starting debian-* minus debian-private and the three digest-lists.

So i rewrote some parts of the bounce detection:

We now have four categories of lists:

high (30 or more mails a day)

medium (20 or more mails a week)

low (10 or more mails a month)

very-low (the rest)

for these four categories we calculate a spam-rate depending on the number of distributed messages and the number of bounces in the timerange of 24 hours for 'high' lists, 7 days for 'medium' lists, 30 days for 'low' lists and 90 days for 'very-low' lists.

If the Spamrate exceeds 80% for unmoderated, and 60% for moderated lists, and bounces have been seen for more than 24 hours we kick. (these rates are subject to change, when we have implemented the warning mechanism)

So these changes implemented a bounce-detection for debian-changes-digest and today we reached the level of 60% bounces for more than 500 subscribers.

So what next?

To finish the bounce-detection, i want to implement something which tries to notify subscribers about bouncing mails. This is useless for 'hard'-bouncers, but people with some smaller problems like mail2news-gatewayers this could be helpful. I also want to implement something which sends out unsubscription notices for three weeks after the kick, so kicked out people can resubscribe after they have sorted out the problems.

so people: fix your systems. if you do more with listmail than dropping it somewhere make sure that the bounces your system produces go to someone who can fix it. We (as in listmasters) normally simply unsubscribe those.

I'm just wadeing through Debian-Mailinglists on the search for enhancements and false-positives.

and i just came over debian-security-announce, a lists that sends a helpful message back to submitters that aren't allowed to send out advisories.

That message didn't contain a Precedence-Header so i added one, and wondered which value would be appropriate... I remember to have seen three values: 'junk', 'bulk' and 'list' (the latter should be set for all our Mailinglists).

So i tried the usual ways to find out about some more possible values, but i couldn't find a RfC or another Document that describes correct usage of the Precedence-Header.

So, i set the Header to 'junk' now, but if someone could point me to some documentation i would be thankful.

Explaination for non German Readers: Today the german parliament passed an act, which orders all communication-connection data (caller-ids, times, email-communication, other internet-transactions) have to be stored for 6 months.