I suppose the only way to avoid this would be to take advantage of the possibilty in SMTP to set no return address, ie to persuade the library to start with
MAIL FROM: <>
But can you initialize it with an empty user id that will generate that?
If so, that sets a null return path, which is what MTAs do to avoid cascades of bounce messages. If you do want to provide some valid error reporting to the users of your apps, you can then add an Errors-To: header, which will in some circumstances do the trick, though there are lots of decidedly wonky email systems out there that do insane things like always reply to the Envelope From (SMTP) address, rather than anything in the headers, and other such lunacies.
If you can't persuade the SMTP object to behave as you wish, provided you trap the most common response codes and you're not doing anything really complicated, you could probably write a fairly simple SMTP submission tool using a socket and AsyncStreamsText - it's not the most complex of protocols, after all.