Re: [rt-users] S/MIME signed emails are detected as non-plaintext
On 20/08/2014 18:33, Alex Vandiver wrote: On 08/18/2014 11:12 AM, m...@fv-berlin.de wrote: we're running RT 4.2.5 and have noticed a minor annoyance. When you send an S/MIME-signed (not encrypted!) mail to RT to create a ticket, the email body will be added as quoted text because it's not plain text. You can click on the quoted text to read it perfectly fine, but this is still somewhat of an annoyance. Is this behaviour something I can configure, maybe in a list of acceptable content-types or something? Can you try enabling RT's S/MIME support, and see how that improves things? See: http://docs.bestpractical.com/RT_Config.html#Cryptography http://docs.bestpractical.com/RT/Crypt.html#CONFIGURATION http://docs.bestpractical.com/RT/Crypt/SMIME.html#CONFIGURATION The following should be a minimal implementation: Set( %SMIME, Enable = 1, AcceptUntrustedCAs = 1, ); Set(@MailPlugins, 'Auth::MailFrom', 'Auth::Crypt' ); - Alex That does seem to work, although I had to add the keyring and CAPath options because otherwise the rt-fulltext-indexer cron job would send an error email every 5 minutes indicating it didnt find the keyring. Now there's no log entries regarding s/mime whatsoever. This is good and bad: - good because emails in RT show up perfectly fine now. The change is not retroactive, but I didn't expect that, thats fine. - bad because if you try to sign outgoing response emails, the sent emails are empty (if Sign is left unchecked, they are fine). It is entirely possible this is an error on my end putting a wrong/incomplete keyfile there, but at least I wouldv'e hoped to find some INFO/WARN/ERR-type log entries regarding that, but sadly not. I might enable debug-logging and see what's going on later. Thanks for the help! -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] S/MIME signed emails are detected as non-plaintext
On 08/18/2014 11:12 AM, m...@fv-berlin.de wrote: we're running RT 4.2.5 and have noticed a minor annoyance. When you send an S/MIME-signed (not encrypted!) mail to RT to create a ticket, the email body will be added as quoted text because it's not plain text. You can click on the quoted text to read it perfectly fine, but this is still somewhat of an annoyance. Is this behaviour something I can configure, maybe in a list of acceptable content-types or something? Can you try enabling RT's S/MIME support, and see how that improves things? See: http://docs.bestpractical.com/RT_Config.html#Cryptography http://docs.bestpractical.com/RT/Crypt.html#CONFIGURATION http://docs.bestpractical.com/RT/Crypt/SMIME.html#CONFIGURATION The following should be a minimal implementation: Set( %SMIME, Enable = 1, AcceptUntrustedCAs = 1, ); Set(@MailPlugins, 'Auth::MailFrom', 'Auth::Crypt' ); - Alex -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] S/MIME signed emails are detected as non-plaintext
Hi, we're running RT 4.2.5 and have noticed a minor annoyance. When you send an S/MIME-signed (not encrypted!) mail to RT to create a ticket, the email body will be added as quoted text because it's not plain text. You can click on the quoted text to read it perfectly fine, but this is still somewhat of an annoyance. Is this behaviour something I can configure, maybe in a list of acceptable content-types or something? Such mails may look like this: MIME-Version: 1.0 Content-Type: multipart/signed; protocol=application/x-pkcs7-signature; micalg=2.16.840.1.101.3.4.2.1; boundary==_NextPart_000_001C_01CFBB05.63DBBF10 This is a multipart message in MIME format. --=_NextPart_000_001C_01CFBB05.63DBBF10 Content-Type: multipart/related; boundary==_NextPart_001_001D_01CFBB05.63DBBF10 --=_NextPart_001_001D_01CFBB05.63DBBF10 Content-Type: multipart/alternative; boundary==_NextPart_002_001E_01CFBB05.63DBBF10 --=_NextPart_002_001E_01CFBB05.63DBBF10 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable (The actual message body starts here) -- RT Training - Boston, September 9-10 http://bestpractical.com/training
