The email includes references to an externally-hosted images, like
http://example.com/[tracking_id].png, where the tracking company controls the server hosting the image. The company records how and when each unique image URL is loaded by a mail client.
As you've noted, print operations can be logged by a tracking image in the
@media print CSS directive. This assumes that the tracking image will not be loaded until the user actually prints the email.
Length of viewing time could theoretically be tracked by a slowly-loading image. The server would keep the HTTP response permanently unfinished, and it is only terminated when the user navigates away from the email. The server can log how long it took for the client to terminate the connection. However, I haven't observed this slow-load behavior in HTTP. It might be possible to do something similar with TCP sockets, which might be kept open even after the HTTP request completes (since the image is served with
Connection: keep-alive), but my initial research suggests that the TCP connections may be kept alive after navigating away from a page that requested that keep-alive resource.
Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. Possibly time-tracking is a premium feature not enabled for this tracker.
The only other (mildly ridiculous) possibility I could consider is that the
/F resource is somehow loaded when a navigation action is performed (i.e., the navigation action causes a manipulation to the document structure that causes the CSS rule to apply). If this (quite out-there) theory is the case, time-tracking will only work on Web-based mail, though.
Finally, they don't have ability to detect deletions. That article simply assumes that a user who has spent less that 2 seconds looking at an email has deleted it.