The userSMIMECertificate attribute must hold a signed message.
To create the contents of the userSMIMECertificate, sign an email message with an empty message body, then remove all mail headers except for those describing the signature attachment.
The result should like similar to this:
[...and so on...]
This can even be performed manually by signing an empty message using an email client, then saving that email in text format and removing the unwanted headers in an editor.
The userSMIMECertificate is designed to hold a signed message that is signed using the user's email certificate. Additionally, it can and it should also contain the other certificates needed for chaining and verifying the user certificate. It's also designed to provide details about the encryption algorithms which are supported and preferred by the email client. The format is based on RFC 2315: PKCS #7: Cryptographic Message Syntax.
However, I haven't been able to find a definite and exact definition of the userSMIMECertificate attribute contents. I base my answer on the following resources:
In a quote from an original discussion with the creators of the userSMIMECertificate LDAP attribute, one of the authors explains:
Now we come to the question of why we felt we needed a new directory attribute for S/MIME certificates. I was told by our directory engineers that the existing userCertificate attribute was defined as a single raw certificate. That leaves no place to store the other certificates needed for chaining, and no place to store the algorithm capabilities. We had an existing package available to us that could contain both the certificates and the capabilities. That package is an S/MIME signed message.
The format of the userSMIMECertificate attribute is an S/MIME signed message with a zero length body. It contains the user's entire certificate chain and the signed attribute that describes their algorithm capabilities.
Although there is a draft about the format of the data in userSMIMECertificate, it has expired in 2001, and there doesn't seem to be successor to it.