Prior to V8.7, sendmail recognized the Return-Receipt-To: as valid, and would return notification of delivery success to the address indicated in that header. This proved a bad idea (see Return-Receipt-To:) for a variety of reasons. Beginning with V8.7 sendmail, the Return-Receipt-To: header was no longer recognized and, instead, the DSN command of NOTIFY=SUCCESS replaced it.

Demand, however, has caused the Return-Receipt-To: header to return to limited use. Beginning with V8.10, if the RrtImpliesDsn option is true, if a Return-Receipt-To: header is found, and if this is the final delivery, sendmail will act as if a NOTIFY=SUCCESS was requested, and will strip the Return-Receipt-To: header and return a DSN success notification to the envelope sender address (unless noreceipts (See this section) is declared for the PrivacyOptions option). If this is not the final delivery, sendmail will relay the message onward to the next MTA with the Return-Receipt-To: header deleted, and with the request for success notification carried in the envelope's NOTIFY=SUCCESS.

The Return-Receipt-To: option is declared like this:

O RrtImpliesDsn=bool                 configuration file (V8.10 and later) 
-ORrtImpliesDsn=bool                 command line (V8.10 and later) 
define(`confRRT_IMPLIES_DSN',bool)   mc configuration (V8.10 and later) 

The optional argument bool is of type Boolean. If bool is missing, this option becomes true (Return-Receipt-To: headers are returned as DSN). If the entire option is missing (the default), it becomes false (Return-Receipt-To: headers are ignored). The default for the mc configuration technique is to omit this option.

The RrtImpliesDsn option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.