That would be against how Delivery Notifications (DSN) are defined in RFC 3464. DSN on success is only sent if a client specifically requests for it.
Because DSN needs modification on the protocol level MAIL FROM or RCPT TO command, the server must report supporting DSN. That happens by first announcing that the server supports Extended SMTP, and then, as a reply to EHLO command, list of supported features include 250 DSN, e.g. here on the last line:
<-- 220 mail.example.com ESMTP Postfix (Debian/GNU)
--> EHLO client-198.51.100.123.example.com
<-- 250-mail.example.com
<-- 250-PIPELINING
<-- 250-SIZE 10240000
<-- 250-VRFY
<-- 250-ETRN
<-- 250-STARTTLS
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250-DSN
Postfix has support for DSN and options for restricting who can request it. From Introduction:
Specifically, DSN support gives an email sender the ability to
specify:
What notifications are sent: success, failure, delay, or none. Normally, Postfix informs the sender only when mail delivery is
delayed or when delivery fails.
What content is returned in case of failure: only the message headers, or the full message.
An envelope ID that is returned as part of delivery status notifications. This identifies the message submission transaction, and
must not be confused with the message ID, which identifies the message
content.
The implementation of DSN support involves extra parameters to the
SMTP MAIL FROM and RCPT TO commands, as well as two Postfix sendmail
command line options that provide a sub-set of the functions of the
extra SMTP command parameters.
Let's explain this a little. The normal simple SMTP connection would continue with:
--> MAIL FROM: sender@example.com
<-- 250 2.1.0 Ok
--> RCPT TO: recipient@example.net
<-- 250 2.1.5 Ok
But with DSN supported and requested, it could be (depending on what's requested) e.g.
--> MAIL FROM: sender@example.com RET=HDRS
<-- 250 2.1.0 Ok
--> RCPT TO: recipient@example.net NOTIFY=FAILURE,DELAY ORCPT=rfc822;recipient@example.net
<-- 250 2.1.5 Ok
Here, RET=HDRS means that only the headers should be added to the automatic reply, and NOTIFY= specifies that only failures and delays should be reported. If there was also NOTIFY=SUCCESS, the report would have been sent on any result, i.e. that would alter the normal behaviour of Postfix. (ORCPT is just to add the original recipient.)
Therefore, the server simply shouldn't take liberties to send delivery notifications on success if they are not expressly requested.
It's too bad Mac OS X Mail doesn't support this feature. It's not surprising as this client doesn't even have GUI support for read receipts. Fortunately, a read receipt is a different standard that doesn't involve modifications to the SMTP commands: it works by adding Disposition-Notification-To header to the email contents. That's possible from Mac OS X Terminal (add, remove and check):
defaults write com.apple.mail UserHeaders '{"Disposition-Notification-To" = "u@example"; }'
defaults delete com.apple.mail UserHeaders
defaults read com.apple.mail UserHeaders
