When the system has to do a retry on a partially sent fax it should commence the retires from the last successfully send page. Now, this is not an exact science because of buffering however it should not resend the entire fax again.
If you know the errant fax numbers you are able to set the retries for just those numbers to 1 or 2 in the current API, however it is an interesting idea to have your suggestion added to the API. I will have it submitted.
There is a longstanding difficulty with some consumer fax machines not acknowledging the last page of a multi-page fax properly, which causes SRFax to resend even though the recipient may have in fact received all pages. This occasionally earns us an angry phone call from a client who believes we are purposely or incompetently sending them same documents over and over and wasting their paper. They don't want to hear about it being their fault. We're in a poor position to help them troubleshoot.
It would help us greatly if an API variable could be added that applied to fax protocol errors but not to busy/no-answer errors. So if we specified,
sRetries = 2
... we would get up to 2 retries regardless of the type of error, but if we specified,
sRetries = 2
sProtocolRetries = 0
... we would get retries if there was an initial connection error (e.g. busy signal) -- but once a connection to a fax receiver was established, there would be no retries regardless of whether the send appeared to complete. On our end, we would probably keep a list of "trouble clients" and make our system specify sProtocolRetries just when sending to those particular numbers.