On Tue, 15 Dec 2015, Paul Stead wrote:
On 14/12/15 20:32, John Hardin wrote:
All:
Any objection to promoting __CT_ENCRYPTED and ENCRYPTED_MESSAGE out of
the sandbox to permanent rules, and giving ENCRYPTED_MESSAGE a
negative (nice) score (say, -1)?
I think that's fairly safe to do, as I doubt a spammer would impose
the overhead of decryption on their victims, and I'm not sure exactly
how well sandbox+masscheck works for "nice" rules.
header __CT_ENCRYPTED Content-Type =~
/^multipart\/(?:x-)?(?:pgp-)?encrypted|application\/(?:x-)?pkcs7-mime/
What's to stop the spammer using a very short public key? The overhead
for the victim would be minimal
Does this header distinguish between "signed" and "encrypted"? If it does
not, then I can see your objection as signature verification alone, absent
actual encryption of the contents, would probably be transparent to the
user.
Otherwise: the crypto key size doesn't matter. It would still cause the
recipient to have to decrypt the spam before they could see it. I'm more
focused on user interaction load than system load. If the user has to
enter a password to see the spam, it's much less likely they will see the
spam.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...to announce there must be no criticism of the President or to
stand by the President right or wrong is not only unpatriotic and
servile, but is morally treasonous to the American public.
-- Theodore Roosevelt, 1918
-----------------------------------------------------------------------
Today: Bill of Rights day
