The discussion revolves around Discourse’s default setting to block cryptographic signatures as attachments. maltfield points out that the default attachment blacklist includes ‘signature.asc’ files and questions the logic behind this decision. zogstrip explains that the intention was not to block cryptographic signatures specifically but rather signatures in general, which are often redundant. However, maltfield argues that cryptographic signatures are not redundant and serve a specific purpose in authenticating the message’s author and providing cryptographic integrity. danb35 notes that the email message is often altered during the process of being posted to the forum, which could break the signature’s validation.
It appears that, when attachment blacklists were added to Discourse on 2016-08-03, (commit e92f5e4fbf04a88d37dc5069917090abf6c07dec), the default value for the “attachment_filename_blacklist” variable became “smime.p7s|signature.asc” – or to block S/MIME & GPG cryptographic signature attachment files.
By the time the email message is munged into the forum, I’d be very surprised if the signature could validate anything. Even a single space will break the signature.
Is there an example of an email client that attaches a file to an email named signature.asc for signatures other than cryptographic signatures?
The .asc part signifies that it’s an ASCII-armored PGP signature, which I don’t believe is a standard outside of cryptographic signature files
EDIT: And I don’t use S/MIME, but the other one (smime.p7s) seems pretty specific to cryptographic signatures as well.
signatures which are often redundant
I agree that a typical signature is usually redundant, but cryptographic signatures are metadata specific to the message used for the purposes of authenticating the message’s author and providing cryptographic integrity of the message’s contents. Unlike a regular signature, a cryptographic signature is not redundant.