(Rudimentary technical documentation)
Remarks: ReSecCo is the international version of WiSiKo firstly published in November 2016. To preserve compatibility between these versions some items like certificates point to WiSiKo pendants. If you read ReSecCo think of WiSiKo, too.
ReSecCo/ WiSiKo uses GnuPG (Gnu Privacy Guard), an open source implementation of Phil Zimmermanns PGP (Pretty Good Privacy) with additional features concerning handling of PKCS #7 (s/Mime) cryptology. GnuPG is a command-line-tool. The ReSecCo/ WiSiKo implementation is fully compatible with GnuPG (because it adds nothing to GnuPG) and you may use GnuPG documentation and GnuPG command line for better understanding or to suit needs that may appear and are not featured by WiSiKo/ ReSecCo. GnuPG was not altered by us. You may recognize this fact as you are prompted to download GnuPG from its original place on the internet while ReSecCo configures. You should take a look onto the GnuPG site occasionally to keep it up to date. ReSecCo/ WiSiKo wraps the DLLs delivered by the GnuPG project.
There are other open source tools we have used to build ReSecCo (mentioned on the info page within the program). But unfortunately we also have used commercial tools under license so we cannot publish ReSecCo/ WiSiKo as open source.
Where will ReSecCo store (hold) your data?
ReSecCo administers two relational databases. One of them holds the mails and related data, and the second holds address data. You may opt to encrypt the databases when the program terminates. The key that will be used to encrypt in this case is the ReSecCo/ WiSiKo key (see below). The database system that we use is "Absolute Database" created by "Component Ace". Besides storing the fetched emails in a database they will be stored in single files that will be encrypted.
Cryptological functions are proceeded by GnuPG. More information how GnuPG manages its data can be found within the GnuPG documentation downloadable from the GnuPG web site.
If you have not altered the defaults the databases and the archives are stored in "%Users%\[your username]\%Appdata%\Roaming\ReSecCo". The GnuPG key rings are stored in "%Users%\[your username]\%Appdata%\Roaming\GnuPG" by default.
A full-text search on emails is not reasonable if the emails are encrypted. You may tag your mails to find them again.
ReSecCo stores emails (fetched or imported) in a database as they come in. Any structure you will find exists in flags (digital markers) which were set by analysis. These flags enable different views on the data pool as virtual folders or a structure orientated on email addresses. The "folders" shown are fixed. Only the "archive" folder is extensible by subfolders.
Fetched emails will be placed within the folder "Recent" were they will remain for 24 hours after they have been collected. Elder mails will be moved into "Archive". To keep emails in "Recent" you can mark them "Remain in Recent".
If you import mails (*.eml files) they will be placed within the folder you have currently selected.
You will find an alternative view within the section "Addresses - Correspondence". Therein you will find only mails which belong to a specified address.
You may mark emails as read/unread, in/out, indelible etc.
Additional and as a specialty ReSecCo offers the possibility to set dates of re-presentment or automatical deletion. Represented mails will appear in "Recent" on the date you named and will be treated as new mails.
You can delete subfolders created in "Archive" or dissolve them. This means that the emails organized in the dissolved folder will be moved into the next upper folder that was not dissolved.
Every email you have fetched or imported will be assigned to an address item within the ReSecCo address book. If there is no suitable address ReSecCo will create a new one. In these cases "Name" and "Email address" will be filled in with the mail address stated within the email header.
If ReSecCo recognizes an email as spam mail it will not create an address entry. If you move a mail from "Suspected to be spam" to "Recent" or "Archive" ReSecCo will make up a new address entry.
If you move a mail into "Suspected to be spam" the entry within the address book will be deleted if the moved email was the only one assigned to this address.
Addresses recognized as spam will be added automatically to a black list. If you move an email from "Suspected to be spam" to another folder the address within the black list will be deleted.
You can edit the "black list". You may delete entries and you may declare whole domains as spam senders. Be aware: Never block provider domains.
Within the section "Addresses - Correspondence" all emails concerning a selected address are viewable.
Addresses can be merged. If a sender uses a new address ReSecCo will create a new address entry. To merge this new entry with another one that points to the same person use "Assign data of this address to another address" to merge addresses. After proceeding there is is only one item left with two email addresses. But pay attention: Different addresses of the same institution may fulfill different functions. One might be a newsletter address, the other one an address to get support. In such cases you should preserve both entries.
You can assign more than one postal address, email address or phone number to an address entry.
Assigning a "Group" to an address entry makes it easier to find addresses and enables you to set periods of life time to emails automatically. You can define groups like "Friends", "Family" etc. but also "Newsletter that will be deleted after one week". If you fetch a mail whose sender's address belongs to this group ReSecCo sets the date of automatical deletion seven days after receipt.
All incoming mails (if they were fetched or imported) will be analyzed by ReSecCo. As the one and only reference ReSecCo analyzes the header of the mail. This header might be faked (what shall we do...)
- ReSecCo does not differ between incoming or outgoing mails but it tries to mark the direction correctly. If the header entry "From:" covers an own mail address the mail will be interpreted as outgoing mail. To interpret older mails correctly, you should fill in the old and no more used mail addresses into the virtual account "historical". ReSecCo will interpret any mail without a "From:" address of your own as incoming, others will be recognized as outgoing. If ReSecCo's interpretation fails you can alter the in/out state manually. If your communication partner uses ReSecCo/ WiSiKo the kind of the mail is described within the extraordinary header entry "X-WiSiKo-Kind" that will always be interpreted correctly within ReSecCo.
- If an email is encrypted, ReSecCo will set a marker "encrypted", that's all. An automatical decryption is not designed for security reasons. The decisions described below will be proceeded when you initiate decryption of the mail.
- If the sender of an email requests a confirmation ReSecCo will show a button to enable you to react. If you click it you can confirm the request or ignore it. I have learned that some email programs automatically confirm "deleted without reading" if the sender has requested a confirmation and the recipient didn't have read it but deleted it. ReSecCo sends confirmations about receipt signed and, if possible, encrypted. The button will become hidden once you have sent the confirmation or you have ignored it explicitly. The technical process is realized by sending a status message (confirmation or ignoring) to your email address. If you use more than one computer the computers you have not worked with will recognize your action. The status messages will not be displayed.
- If the incoming mail has been digitally signed ReSecCo will check the signature and the result of checking will be stored. This way functions as long as no encryption appears. X.509 certificates will be imported into the gnuPG key management automatically. If an openPGP key is attached to the email it will be imported automatically, too.
- If there is a vCard file attached ReSecCo will import it into the address book.
Remark: ReSecCo attaches your vCard (see Settings - Identity) to every email you send.
- Setting of a deletion date. If the sender of an email is assigned to a group it may be indicated to set a date when this mail should be deleted.
If you create mails with ReSecCo a header entry "X-WiSiKo-Kind" will be set to post if e.g. the message is an original message, a forwarded message or an internal copy of a message you have sent.
ReSecCo marks fetched or imported emails with a unique ID to avoid multiple fetching or importing mails. This ID will be stored within a table "already receipt".
ReSecCo does not store sent mails but it sends a copy to the sender's address. Within such mails ReSecCo sets a header entry ("X-WiSiKo-Kind: Internal copy of original"). The mail will be sent encrypted to your address. The idea behind this proceeding is to enable yourself to get sent mails on more than one computer.
ReSecCo encrypts messages with only one key in principle. GnuPG permits encryption with one or more keys. Any owner of a key engaged may decrypt the message. In my view there are risks that I do not want to support. If ReSecCo sends a message it is always encrypted with the key that belongs to the recipient, copies sent are encrypted with the recipient of the copy's key and your copy is encrypted with your
ReSecCo/ WiSiKo key. I mention this because most other email clients handle it different. Enigmail (the Thunderbird PGP extension) encrypts outgoing mail using the keys of the recipient and the sender.
In a "Reply to ..." ReSecCo cites just the subject not the email body. I thought about this item and ... let me tell: I'm a software developer and I have to hold my software state of the art. So I constantly send commented updates to my customers. If a customer has a problem that is big enough to contact me he regularly replies my update email. That results in one sentence from him and four pages of mine. I do not like this. If you think that citing is important you must copy and paste. ReSecCo is organized customer orientated. If you want to resume a communication you can choose the address view. Citing is needless.
"Reply to all" is not implemented in ReSecCo.
As there is no "Reply to all" there is no "Draft" folder. If you want to hold an idea you can store it within the editor.
ReSecCo forwards emails "unchanged". The "X-WiSiKo-Kind" entry will be set to "Forwarded". If the mail was encrypted it will be decrypted and, if possibly, newly encrypted with the new recipient's key. Signatures will survive if they are below the encrypted parts of the mail. Additional signing by you is possible. Do not underestimate signing. It's the source of trustworthiness. "Unchanged message" means that additions of comments or of a vCard are prohibited. If you would attach anything to the mail the signature would be broken. And in the future we only want signed emails.
Half of ReSecCo's default folders are folders to gather trash. There are "Suspected to be spam" and "Trash A" or "Trash B" The messages within trash folders are marked to be trash. This means that they already exist within the system. To purge them you must empty a trash folder. Explanation of A and B: The A trash folder holds messages that you want to delete from ReSecCo but to keep on the server, these messages might be fetched by another instance of ReSecCo or an alternative email client. The B trash folder holds messages that you want to delete from ReSecCo and from the server. Messages in "Suspected to be spam" and in "Trash(B)" will be deleted from the server if you click on "Empty trash". Before you have done this the messages can be moved into non trash folders like "Recent" or "Archive" to ensure their remaining within the system. ReSecCo has another useful function. If you want to resume the workflow (see above) of an email you may delete it from the "already received list". It is a keyboard function. Mark the email and enter "Ctrl+Del". Afterwards the mail will be fetched anew if fetching has been initialized.