1: The advantage of S/MIME over PGP is that you sign/encrypt a complete mime entity, not a text. This makes it possible to sign/encrypt an entire message/rfc822. Yes, headers must be visible and changeable to the MTA, but that can be accomplished by taking the WHOLE mail, S/MIME sign or encrypt it, and then package the signed/encrypted S/MIME entity it in a new mail container. This accomplish can even be used to encrypt the subject, by having the inner (encrypted) subject be "Here is your credit report for your credit card number 1234-1234-1234-1234" and then the outer subject be "A encrypted mail from your bank!".
Most MUAs will react to a message/rfc822 container either by displaying a button, attached file, or Another UI element to open the "contained" message, or it will display the contained message inside the original message, like "iframes" work in browsers. Both of these allows you to validate all signed fields and all data, except for data that should be hidden according to the RFCs.
This makes it even possible to use even different from's for encrypted mail.
For example, the outer container has From: YourBank Info Department <info@yourbank.com> but the inner encrypted container has From: Name Namesson <name.namesson@yourbank.com>
However, there is one case, where its DANGEROUS to sign/encrypt/decrypt/verify a complete MIME container/entity instead of only plaintext. This is when someone signs/encrypt content that this someone hasn't created.
One example is a notary verifying that Im is a male, for example (I know it's a "stupid" example, but so you understand the dangers of signing MIME entities).
Let's say I ask the notary to sign the following:
Content-Type: multipart/alternative; boundary="1234";
--1234
Content-Type: text/plain
Im a male
--1234
Content-Type: text/html
Im a female
--1234--
If the signing is done with S/MIME, the notary will verify the content she/he see, lets say the notary's client is unable to view HTML mails and will then show the text/plain version. The notary signs is because the notary knows im a male.
I then forward the signed mail to a verifier, that has a HTML mail client, which will of course show "Im a female".
Another example is the following:
Content-Type: text/html
I authorize the transfer of $ 100<font color="#FFFFFF"> 000 000 000</font><br>
from your account to my account 1234 1234 1234
You can propably understand what happens if you as a account manager signs this, and the target mail client, lets say the bank employee's mail client strips off HTML from the mail after having verified the signature.
In this case, PGP can have a great security advantage over S/MIME, because in PGP, you know exactly what you signing, encrypting, decrypting or verifying.
2: In PGP its easy as appending the unsigned data outside of the -----BEGIN PGP...----- and -----END PGP...----- . In S/MIME this is done outside of the S/MIME container. This can be done as in 1, repackaging the whole signed mail into a new message/rfc822 container, and then adding the disclaimer to the outer container.
But if you need to add a disclaimer to S/MIME mail, I would recommend using a gateway signing solution like Ciphermail, where the disclaimer can be added Before signing the mail.
3: The MTA can modify all outer headers in both PGP and S/MIME mail. MTA's shouldnt touch inner headers anyways (unless its signing, encrypting, decrypting or verifying mail). Some MTAs might recode content from 8bitmime to qp in case the receiving server does not annouce support for 8BITMIME, why its best to Always send signed mail as quoted-printable.
4: S/MIME do sign all headers that has a effect on interpretation of content, like Content-Type, by moving these headers inside the S/MIME container.
PGP should completely ignore the container and Always sign plaintext, however, MUA's might display the content inside a PGP armor with formatting, when it should not. In some cases, this can also affect the signature validation, eg if the mail client sends the visible content (eg with stripped HTML tags) to the PGP verifier, the content will come out as invalid.
The best way of this, is when PGP is used, Always use a external solution where the PGP mail is copyed and pasted. Or use a central solution that can recode PGP mail as text/plain to ensure these do not have any effect on the interpretation of content.
5: For both S/MIME and PGP, the signed data will be visible to the end user even if their clients do not support S/MIME or PGP. In S/MIME, signed mail will appear to have a attachment of smime.p7s for non-S/MIME-aware clients that can be safely ignored if you dont want to verify mail. For PGP, it will look like this:
-----BEGIN PGP SIGNED MESSAGE-----
bla bla bla
Best regards, Name Namesson
-----BEGIN PGP SIGNATURE-----
fkjhdklghdflhilgnegdngnlbvilgbdgeetbugbzjbeu
-----END PGP SIGNATURE-----
Thus the mail client user can see the content of the message, even if the client do not support signatures at all. If you want to add verifying instructions, you can easly add tihs INSIDE the signed mail (so it gets signed).
If you want to add such instructions outside of signed content, you can refer to Point 2 of my answer. For encrypted mail, in PGP its the same as for signed mail - eg add it outside the BEGIN/END header lines. For S/MIME, you have to repackage the mail, so the encrypted mail is put inside a message/rfc822 container, that is then added to a plaintext container, containing decryption instructions.
6: Yes you can hide To and CC in S/MIME by simply moving these inside the encrypted message/rfc822 container. However, its recommended to have a To, that is directed to the original recipient, to prevent the mail from getting discarded by spam filters, because spam filters might compare To: to the envelope recipient, and if it wont match, it sees it as spam.
However, CC can be safely hidden to only be visible to those having a key.
In PGP, its not possible, since PGP encrypts the plaintext. However, you can manually add a text like:
"I did send a copy of this mail to name2@somehost.com and name3@someotherhost.com" aswell in the beginning of the plaintext mail.
7: Yes. Intermediate MTA's can verify signatures inside mail. For S/MIME, this can happen completely transparent. In PGP, this can only happen if the key is uploaded to a key server that the intermediate MTA knows about and downloads keys from. Note that for MTA to MTA integrity, I would recommend using DKIM, STARTTLS and SPF instead. You can example configure your MTA to force STARTTLS to the mail servers you know support TLS.
8: No. Signed and encrypted message is Always a sligtly Little bit larger. This is something you need to account for if you signing or encrypting mails to hosts that empose size restrictions. In the same way, S/MIME and PGP will make the mails as small as possible, so encrypted mails do in fact "leak" roughtly which size the message is. However, its possible to hide the "true" size of a enrcrypted message, by padding it with useless data. You could even add a notice like "This is a padding to ensure encrypted data Always has the same size." and then add large blocks of lorem ipsum text. Note that the size of lorem ipsum block must not be smaller than the largest mail, else people can see in the encrypted content which mails that are larger than a certain size.
Note that S/MIME signs or encrypt all text as once, in a large block, and then adds the smime.p7s attachment. A encrypted S/MIME mail will ONLY have the attachment smime.p7m , PGP does encrypt attachments separately, why the size leaks for those. PGP attachments are encrypted in whole. PGP attachments are signed by appending a new attachment to the mail that contains the signature . For example, Powerpoint.ppt is signed by appending the attachment Powerpoint.ppt.asc to the mail, so the mail contains both the Powerpoint.ppt and the Powerpoint.ppt.asc file.
However, if you want to hide size of attachments when encrypting, you can Always put the attachments in a .zip file, and then inside this zip, you put a useless file such as large that makes all your zip's a fixed size. Note that you then need to calculate the size of the useless file based on compression (or turn off compression), and the useless file needs to be random data. When you encrypt this zip containing your attachments and the useless file, it will be transformed in one single binary blob, where those that does not have the key, cannot see anything about the size, name or number of attachments you have sent.
9: Yes, provided that the gateway knows the private key of the receiver. This is valid for both PGP and S/MIME. If you want to gateway audit mails to recipient who you dont know the private key to, you can Always encrypt the mails from the gateway, and send the mails "unencrypted" to the gateway, but encrypted by some other means like STARTTLS, and/or PGP/SMIME encrypted with a key that the gateway knows the private key of. If the third-party is located off-site, you can Always add the 3rd party's key as recipient in both S/MIME and PGP, allowing the auditor to decrypt in addition to the real recipient.
