Now you need to be aware that sending mail in your snippet involves purely invoking an external sendmail executable to send the mail for you. So the only direct way you can check the status is by its return value.
I'm not sure about what sendmail return values will provide (let alone availability of other sendmail clones such as qmail or postfix which may vary in behaviour WRT this). But I think sendmail's return value is not any much useful. Don't forget sendmail does not send the mail immediately but queued it for delivery so the sendmail process will immediately return without waiting for delivery. That is, mail sending with sendmail is an asynchronous operation so there is not much status indication you can get, beyond obvious misconfigurations such as the sendmail executable is not found which may get trapped! So probably, the sendmail return value is always 0 (successful) so you don't have much to tell from it (and so it will nearly always be successful so eval() won't work).
With a programming mind, I generally recommend this method:
(1) Generate mail with an additional header with an ID that your program can use to identify the message. e.g.
X-MsgID: 20050820000001
Note that custom headers should start with 'X-'. We need a custom message ID because we cannot get the actual message ID as we send it, so we need to embed our own.
Save information about this mail with this message ID in some persistent storage (such as database or files) that allows you to, say, associate this message with a particular application activity that triggers this message.
(2a) At sendmail, capture the return mail by redirecting incoming mail to a program (setting /etc/mail/aliases or similar) instead of to mailbox. The program will be invoked with the return mail content. In the program, you can extract the message ID from the custom ID we inserted. Then we know the mail cannot be sent (or deferred for later retry).
(2b) Some others who have no say over mail server configuration may read the destination mailbox (through POP3 for instance) instead.
(3) Some people may even want to extract the actual message ID for extracting the relevant record from /var/log/maillog. But I usually tend to think this is too much of a trouble.
This is a lot of programming. So are there existing modules you can use to help out a little bit? Probably yes. You may want to think about this:
http://search.cpan.org/~freeside/Mai...ounceParser.pm
I haven't used it before so I'm not sure if it's good. From the POD it seems to do the most important part of the trick though.