Of course, in a BinkP session, both sides can become both sending and the receiving ends. This means that the mailer has to calculate the checksum before transmitting the file. The checksum is pre-conditioned and postconditioned. If the checksums disagree, the receiving end has two options. This will cause a non-destructive reject of the file, so that the session goes on, but the remote site will mark the file as not sent successfully and retransmit it in the next session.
Precompiled binaries are also available there.
The protocol will fail if errors don't occur spontaneous, but regularly with an error rate greater than 1 error per file. In this case, transmission will be impossible because all files will always be rejected. It is the easiest way to implement CRC fully backwards compatible, and it is the way that requries the least amount of changes in the code of existing binkp mailers. Even given the mentioned disadvantages, the extension is good enough for detecting spontaneous transmission errors, so that sysops will not loose valuable data, and so that they can see that there is a problem in the network infrastructure and fix it. That is, this extension is intended as a safeguard against rare error conditions on a transport layer that still, basically, is reliable.