All this system does is provide some reasonable protection for users against mail forgery originating from their own machine. My experiments with port 25 show that a telnet connection from a remote machine to port 25 causes the remote machine's address to appear in the ESMTP headers. However, mail sent from a local connection to port 25 can't be readily distinguished from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the systems I've examined, I can enter a user's login through port 25 and sendmail will affix his real identity from /etc/passwd just as though that user had sent the mail. For instance, a user can forge mail from root on their own machine. I don't know about you, but that's something that concerns me. It's entirely possible that someone impersonating root could send email to a user to change his password as a "system test", giving the bad guy access to someone else's account. Admittedly, this is a pretty benign example, but the potential for real damage is there.
The last time I hacked a mailer (elm 2.4 to be specific) I seem to remember that it invoced sendmail as a process rather than connecting to it via port 25 to send mail. It would seem that one could hack sendmail so as not to accept non sendmail connections to port 25 from the local machine (it clearly knows from the socket info structures who is connected on the other end of the socket) or perhaps to refuse to accept user id from a port 25 connection on the local machine (instead indicating the origen of the mail as user "sendmail25" or something similar). The later approach could be refined by adding a header line to the mail indicating it came from port 25 rather than rejecting it - then all you would have to do is make sure that the legitimate mailers were configured to invoke sendmail as a process rather than via port 25, and the appearence of the warning header line would be a red flag that something irregular happened in the creation of the mail. It might be necessary to hack the permanent sendmail process listening on port 25 to accept mail from other spawned sendmail processes via a memory to memory transfer (most unixes support this these days) or via some other port than 25, or with an additional step of passing the process id so it could check the UID of the process sending it the mail to authenticate the sender. [I am writing this in a typically airheaded manner this afternoon without looking at the sendmail source I have on the machine so I am a little vague about how sendmail spawned talks to sendmail permanent to send mail, but whatever technique is used here ought to be subject to a pass the process ID or pass a magic cookie (hash of process ID and sendmail version perhaps?) and the process id approach]. Thus one need not bother with message signing at all, or if one wanted to use it, could use it only to authenticate one sendmail process on your local machine to another.