--- a/ch03.roff	Sun Apr 22 12:34:14 2012 +0200
+++ b/ch03.roff	Sun Apr 22 13:50:35 2012 +0200
@@ -118,7 +118,7 @@
 
 
 .H1 "Draft and Trash Folders
-.U2 "The Draft Folder
+.U2 "Draft Folder
 .P
 Historically, MH provided exactly one draft message, named `\fLdraft\fP' and
 being located in the MH directory. When starting to compose another message
@@ -175,6 +175,63 @@
 All theses changes converted special cases to regular cases, thus
 simplifying the tools and increasing the flexibility.
 
+.U2 "Trash Folder
+.P
+Similar to the situation for drafts is the situation for removed messages.
+Historically, a message was deleted by renaming. A specific
+\fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP),
+being prepended to the file name. Thus, MH wouldn't recognize the file
+as a message anymore, as only files whose name consists of digits only
+are treated as messages. The removed messages remained as files in the
+same directory and needed some maintenance job to truly delete them after
+some grace time. Usually, by running a command similar to
+.DS
+find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
+.DE
+in a cron job. Within the grace time interval
+the original message could be restored by stripping the
+the backup prefix from the file name. If however, the last message of
+a folder is been removed \(en say message `\fL6\fP' becomes file
+`\fL,6\fP' \(en and a new message enters the same folder, thus the same
+numbered being given again \(en in out case `\fL6\fP' \(en, if that one
+is removed too, then the backup of the former message gets over written.
+Thus, the ability to restore removed messages does not only depend on
+the ``sweeping cron job'' but also on the removing of further messages.
+This is undesireable, because the real mechanism is hidden from the user
+and the concequences of further removals are not always obvious.
+Further more, the backup files are scattered within the whole mail
+storage, instead of being collected at one place.
+.P
+To improve the situation, the profile entry \fIrmmproc\fP
+(previously named \fIDelete-Prog\fP) was introduced, very early.
+It could be set to any command, which would care for the mail removal
+instead of taking the default action, described above.
+Refiling the to-be-removed files to some wastebin folder was a common
+example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP'
+(implemented through a shell alias) and `\fLrm `mhpath +d all`\fP'
+the empty the wastebin.
+Managing the message removal this way is a sane approach. It keeps
+the removed messages in one place, makes it easy to remove the backup
+files, and, most important, enables the user to use the tools of MH
+itself to operate on the removed messages. One can \fLscan\fP them,
+\fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more
+need to use \fLmhpath\fP to switch over from MH tools to Unix tools
+\(en MH can do it all itself.
+.P
+This apporach is matches perfect with the concepts of MH, thus making
+it powerful. Hence, I made it the default. And even more, I also
+removed the old backup prefix approach, as it is clearly less powerful.
+Keeping unused alternative in the code is a bad choice as they likely
+gather bugs, by not being constantly tested. Also, the increased code
+size and more conditions crease the maintenance costs. By strictly
+converting to the trash folder approach, I simplified the code base.
+\fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed
+message to the trash folder (`\fL+trash\fP' by default). Messages
+there can be operated on like on any other message in the storage.
+The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where
+the `\fL\-unlink\fP' switch causes the files to be truly unliked instead
+of moved to the trash folder.
+
 
 .H1 "Paths to ...
 .P