David von Oheimb

關於我

開發者資訊
名稱 David von Oheimb
首頁 http://David.von-Oheimb.de/
加入日期 Dec. 31, 2008
參與開發的附加元件數量 1 個附加元件
此開發者的附加元件平均分數 評分: 4 / 5 顆星

由我建立的附加元件

Duplicate Contacts Manager 需要重新啟動

This Thunderbird add-on searches address book(s) for pairs of matching contact entries.
It can automatically delete entries that have equivalent or less information than the other one.
Any remaining matches are presented for manual treatment.

評分: 5 / 5 顆星 (17)
1,256 位使用者

我所發表的評論

Duplicate Contact Manager

評分: 3 / 5 顆星

In response to recent requests/reviews:

The original developer has abandoned this add-on and has been unreachable for years. Since I needed some improvements I ended up doing them myself and providing a strongly improved add-on here: https://addons.thunderbird.net/en-US/thunderbird/addon/duplicate-contacts-manager/

此使用者對此附加元件 曾發表過 1 筆評論

YouTube Unblocker

評分: 5 / 5 顆星

Works just fine (on Firefox 21.0 under MacOS).

此意見為舊版本 (0.4.1.1-signed) 的附加元件。 

Duplicate Contact Manager

評分: 5 / 5 顆星

Im Gegensatz dazu, was welba67 am 29. Oktober 2012 und yaq12wsx am 11. April 2012 schrieben, findet dieses Add-On bei mir sehr wohl Einträge mit gleichen E-Mail-Adressen und unterschiedlichen Namen. Auch beim Zusammenführen von zwei sehr großen Adressbüchern (mit jeweils vielen hundert Einträgen) habe ich keinen Fehler festgestellt.

Ich finde dieses Add-On seit den Updates auf Version 0.9, die viele Verbesserungen beinhaltet, sehr nützlich.

TB Header Tools Extension

評分: 5 / 5 顆星

I tried the latest unofficial fix (version 0.7.1 by Ray Stevens) from http://forum.addonsmirror.net/index.php?showtopic=1906
It works great on my TB 3.04 (both 32-bit and amd64) and does not break Junk Mail filtering/moving. Thanks a lot to all who contributed to it!

BTW, http://forum.addonsmirror.net/index.php?showtopic=1906&#entry24444 is a good intro how to use this extension, while http://forums.mozillazine.org/viewtopic.php?t=279907 is very outdated.

SyncKolab

評分: 3 / 5 顆星

Works nicely with small address books, and really does synchronize them (as opposed to Addressbooks Synchronizer). Yet it ignores address lists and it does not progress on my real address book with 700+ entries and some 20 lists. So I'm back with exporting to LDIF files, syncing them with unison and kdiff3 more or less manually, and then re-importing them :-(

此意見為舊版本 (1.0.3) 的附加元件。 

Mail Redirect

評分: 4 / 5 顆星

I find the add-on very handy in particular when I send emails to a large number of friends (usually using BCC). When I later notice that some of them was missing on the list, I can simply re-send the original email (including any attachments) to the new recipient(s).

Yet this scenario brought up a privacy issue (at least for version 0.7.4):
For each *multi-line* email header, all its lines but the first one are simply copied from the original email. This is a severe
privacy problem for multi-line sensitive headers like BCC, where all the following lines of this header are still visible in the bounced email!
I've corrected this with the code patch given below. You can download the patched version from http://home.arcor.de/j-i-t/mail_redirect-075-DvO-tb20x.xpi

Two further observations.
* Would be nice if the title of the window in which the bounced email is
"composed" does not just just say "Mail Redirect" but also gives the
email subject, as done by the usual "compose" window. This is helpful
e.g. when there are multiple compose windows open.
* To me, the choice between "Resent-To", "Resent-Cc", and "Recent-Bcc"
is superfluous and confusing - is there any difference concerning the
visibility of the new recipents' names? If not, just offer Resent-To.

--- chrome/content/mailredirect-compose.orig.js 2008-12-25 19:55:17.000000000 +0100
+++ chrome/content/mailredirect-compose.js 2008-12-25 19:55:17.000000000 +0100
@@ -1373,7 +1373,9 @@


if (inHeader) {

// dumper.dump("!! reading new buffer -- leftovers.length="+leftovers.length);

- buf = leftovers + aScriptableInputStream.read(1024);

+ buf = leftovers + aScriptableInputStream.read(50000); // hoping that

+ // 50000 characters are sufficient even for large multi-line headers

+

leftovers = "";



while (buf.length > 0) {

@@ -1418,6 +1420,22 @@
// terminate the line with CRLF sign, not native line-endings

line = buf.substr(0, eol+1-eol_length) + "\r\n";

buf = buf.substr(eol+1);

+ while(buf[0] == " ") // multi-line header, extends over several lines

+ {

+ eol_r = buf.indexOf("\r");

+ eol_n = buf.indexOf("\n");

+ if (eol_r != -1 && eol_n != -1) {

+ eol = eol_r>eol_n ? eol_r : eol_n;

+ } else if (eol_r != -1) {

+ eol = eol_r;

+ } else if (eol_n != -1) {

+ eol = eol_n;

+ } else {

+ eol = buf.length-1;

+ }

+ line += buf.substr(0, eol+1); // for simplicity, leave native line-endings

+ buf = buf.substr(eol+1);

+ }

// dumper.dump("line=>>"+line+"

此意見為舊版本 (0.7.5) 的附加元件。