this is a request for this list to be digitally signed by the list processor. to all list members. if after reading this post you would like the list processor to digitally sign all posts please say so (and tell the list owner) so that the level of interest can be gauged. thanks. i'm making this request because i need a way to positively id the messages from this list. i'm spending way too much of my time culling spam from my real email even though i'm employing the latest spam filtering tools. please give me the one simple tool i know of that will allow me to positively differentiate the mail from this list from all others - a digital signature. signing all list messages won't be detrimental to list recipients not interested. it will however allow folks wishing to implement anti-spam measures around digital signatures to do so. mailing lists often require that recipients confirm their email address as an anti-spam measure for the list. please help list recipients implement their own anti-spam measures by allowing the list messages to be positively identified. to be clear, this is a limited scope spam solution, but it works. and it will continue to work provided the underlying cryptography is sound (unlike many other anti-spam technologies that are simply clever hacks in an escalating spam/anti- spam arms race). some folks say that there will be no spam solution as long as email is free. i say there will be no spam solution as long as you expect anyone to be able to send email to you without first proving they are not a spammer. part of finding a solution is to revision what email is. i argue that email can no longer be a method of unfettered *initial* contact. once that is accepted then this solution doesn't seem painful. i suspect that there won't be a solution until email is seen from this perspective. as noted above, mailing lists are essentially adopting this perspective (to better manage spam on the list side), it would be helpful if they took an additional small step that would enable list recipients to better manage spam on their end too. there's no need for a larger web of trust other than one that is personally maintained when using digital signatures to defend against the onslaught of spam. your personal web of trust (a.k.a. your keyring) is your unspoofable anti-spam whitelist. this is where the revisioning of email occurs. instead of email being the way you initially make contact with an entity, with digital signatures it can serve as a reliable communications channel *once* contact has been established. my intention is to implement a procmail recipe at the mail server level. the procmail recipe will be used to check incoming mail for whitelisted digital signatures that have been uploaded from each individual user. mailing lists could use the same recipe, no messages would be handed over to the listserv software unless it was signed by a whitelisted signature. again, this won't stop machines from being compromised but as soon as a machine is compromised that entity will be *immediately* notified by their peers. in the case of a mailing list *many* people will suddenly know who's compromised and the list can even have a mechanism that allows a whitelisted key to be removed once it becomes compromised. this would also serve the dual function of indirectly alerting the owner of the compromised host since they will investigate why they are no longer receiving list traffic. regarding whether to utilize inline or mime GPG, i say use either. the preferred solution will self- select over time. it is possible to create a procmail recipe that can handle both methods. Two key benefits of this anti-spam technology: 1. it works and will likely continue to work beyond the foreseeable future 2. it can be implemented without the consensus, from the bottom up below are my responses to posts in a few mailing list threads regarding digital signatures and spam. please read my responses as they will likely answer many of the questions that may result from reading what i wrote above. apologies to the folks whose comments i'm replying to for not referencing their names (i didn't have the time). looking forward to feedback. ciao, david -- spam is something we can eliminate by changing our personal behaviors and expectations and cooperating. and it can happen gradually. thread: ietf - proposal for built-in spam burden & email privacy protection ----- >>2. Except for senders in a whitelist (e.g., >>list mail), I bounce to the sender any email >>that is NOT encrypted with my public-key, >>providing my public-key and instructions for the >>sender to resubmit the message properly >>encrypted. > >Anything at all that generates a bounce message >on a mass-produced mailing acts as a "damage >amplifier" from the basic internet backbone's >point of view -- at least doubling the associated >automated traffic and wasted/misused resources. >These days such a bounce is especially fruitless, >as all viruses and quite a lot of SPAM have forged >headers that the stupid bounce agents cannot or do >not parse. > >This is pet peeve of mine as it is -- I got (and >continue to get) more bounce messages from mydoom >reporting that mail "from me" is contaminated than >I do copies of the virus itself. No virus for two >years now hasn't forged mail headers -- the From >field is totally irrelevant in all current viruses- >- yet all the AV programs in the world think they >are doing you a favor. NOT. > >Now imagine that sort of stupidity scaled out so >that every MTA in the world is checking esigs and >bouncing improperly signed mail. Imagine the >loops created when a legacy mailer or improperly >configured mailer bounces the bounce messages back >to the bouncer, to be bounced again. Nightmarish. solution - don't auto-respond, give out a keyword with your email address, this will allow initial contact to be more easily plucked from the sea of spam - in the long run as more people digitally sign email spam will become even less profitable because there will be even fewer responses - we'll never know what's possible if we don't try >encrypting for each of the list recipients is too >much of a burden for the list solution - don't encrypt, only digitally sign - not a burden >Don't get me wrong: encouraging people to use pgp >is a good idea, but making it a requirement before >accepting it is a policy decision that the end >user should be making, not the list. solution - by only digitally signing it is completely up to the end user to decide whether or not to add this tool to their anti-spam toolbox >Your proposal is in line with some existing ones, >at least one of which response to the seriously >problematic key management issue. solution - non-local, centralized key management is a huge problem, but key management isn't a problem if the only important keys are your personal ones and if you don't expect to be able to instantaneously have access to anyone's public key via a keyserver - keyservers aren't necessary for folks who exchange email with primarily a small group of people >I'm not saying to reject non esig mails, but to >held them for approval by moderators... If you >want your post to go through quickly, sign it... >It would be a worthwhile incentive. sounds like a great idea, but this is in addition to and isn't required for what i'm suggesting >Also note, there is an addition burden placed on >end users who rely on receiving encrypted email in >your proposal. Under your scheme, a user has to >go through the trouble of decrypting the message >just to see if it is spam or not. This eliminates >almost all forms of automated spam mitigation >except those related to the low-level SMTP, DNS or >other new authentication/authorization techniques. reminds me that signing and not encrypting still allows bayesian filters to continue to be useful >Unfortunately, requiring that they have a >published public-key *is* a burden to the average >user. J. Random Luser just wants to sit down at >his PC, boot up Winders, bring out Lookout, and >forward a garish HTMLified email full of stale >jokes to his buddies, complete with pictures, and >he wants it to go through, without a hitch, right >now. He thinks public keys are the ones hanging >on the gas station wall, for the bathroom. He >thinks crypto is someone from Superman's home >planet. He thinks the IETF is them guys whut >raided David Koresh. He has no clue what the ASRG >is, but he thinks it sounds dirty. again, no need for keyservers for folks that are exchanging email within a small group of people. also, let's stop trying to allow email to continue to be what it has evolved into, let those folks that want email to stay the way it is keep it that way, let's create a spam-free email environment that works and satisfies *us*, i suspect that if this is witnessed folks will eventually start thinking of email differently as their personal spam pain tolerances are exceeded. >Make it worth their while, by coming up with >infrastructure such that they won't get any spam >if they have a public key, and MAYBE they'll >bother doing it, IF the ISP will hold their hands >every step of the way (and not charge them too >much, including for issuing new keypairs when they >let the private ones slip out too much). Of >course, this means that all their equally >technically-enlightened friends have to know how >to USE his public key.... solution - accept that it will be a gradual process, let's just start with mailing lists signing all messages that get sent to list recipients - that's easy >This sounds very much like the use of extra >headerz, or a password on the subject line, but on >steroids. In the end, possibly useful, IF you can >get everybody aboard, but they won't go until >everybody ELSE is already on board, and meanwhile >it's a pain in the proverbial posterior to >everyone who wants to communicate with the people >using it. for me it is *less* pain than what i'm experiencing dealing with my current spam load, and digital signatures can be ignored if you don't want to verify them - also, if someone tells you that they are receiving so much spam that you will have to sign all email you send to them, are you going to tell them they are causing you too much pain? heck, just pick the phone up and call them then. >Second, even if the above weren't a problem, one >still has the problem that a virus infected user >will still be sending messages, just like everyone >else. this will still be a problem but with a digital signature solution in place infected computers will be identifiable and probably immediately disinfected, folks will become hyper-aware of allowing their machines to become compromised if suddenly they are unable to exchange email with their small and *important* group of people because their public key became blacklisted by these same folks - the very nature of digital signatures positively identifies infected computers >There is no scheme in which the rules can't be >broken by someone intent on breaking them. The >only path is to detect them, and prosecute them. >In the case of spam, detection is easy, but not >automatic. Prosecution is now possible. Its >still a whack-a-mole game. It won't end unless you >can get past the virus infection to the virus >operator, and hopefully, there aren't really too >many virus operators. Of course, we aren't >stopping spam either in a very real sense, but >rather abusers who are annoying and mailbombing >people. But by my count of my inbox, if you stop >those people, I can certainly handle the rest >which amounts to maybe 1% of my current junk mail. there's no known way to crack GPG, widespread adoption of digital signatures against spam will either help bring spam to and end or tell us what NSA might already know ;) - let's put those spammers to work! also, prosecutions by a central authority won't be necessary, peers will do the prosecuting by rejecting email from compromised systems, the owner of the infected system will be de facto "punished" because communications with their peers will end until they clean their system (or stop spamming). >>The "for pay" idea is just another scam from >>the people who would love to get a percentage of >>the pay. While I'm sure Microsoft and others would >>just love to get a cut of this (I know I would), >>it doesn't do anything to stop spam, and if >>implemented, would simply (and wrongly) charge >>users whose computers were virus infected. > >Wrongly? I'm not so sure. Something ought to be >done to stop the Typhoid Marys of the Internet. >Putting them on notice that they WILL be held >responsible for spreading the infection, or its >effects, just MIGHT result in them FINALLY taking >some responsibility for their "computer hygiene". >Sure, there will have to be several well >publicized example cases before most folk will sit >up and take notice, but in the long run, it might >be effective. i agree, trying to impose a burden (computationally or monetarily) on spammers will not work IMHO. i will leave it to others to explain this in more detail. and to repeat, prosecutions by a central authority won't be necessary, peers will do the prosecuting by rejecting email from compromised systems, the owner of the infected system will be de facto "punished" because communications with their peers will end until they clean their system (or stop spamming). >So even discussing adding a silly thing like >mandatory esigs and encryption as an antispam >measure is a waste of time, except possibly on a >local basis. If I set up a small mailing list (or >generalized group of individuals) and all of its >members agree to do this, there is little >"evolutionary pressure" for spammers to detect and >foil our scheme and we will be "immune" (at the >cost of a fair amount of extra work). If >everybody does it and the automated tools for >doing it without so much work are widely >disbursed, they will develop countermeasures in no >time at all and we'll lose our immunity. please explain how spammers will evolve past the public key encryption technology used in digital signatures? as noted earlier machine compromises will still occur but they will be able to be dealt with because peers of the compromised machine will immediately identify and neutralize the problem by ending communication (by blacklisting the compromised key). suddenly the owner of the compromised machine hears silence. >Automated text analysis will never be perfect, >because even human text analysis for >interest/disinterest (secretaries) aren't perfect. >But it can help sort things. I hand filter about >1500 messages a day. I get about 3500 over the >weekend. Monday's filtering doesn't take me any >longer than tuesdays filtering. unfortunately the approach you describe could likely be your undoing in the long run as spammers ratchet up the volume to the point were it *will* take you a long time using this approach. this is why even with 99.9% accurate bayesian filtering, all spammers need to do is ratchet up the volume to get more spam through the 0.1% error rate of the bayesian filter. >>>Then using the IETF list as an example, you >>>would need the entire list of recipients and their >>>public keys, and you would need to send a message >>>either directly to each of them, one by one, or >>>send a single message with a session key for each >>>recipient (thousands). This isn't going to work. >> >>Let's not mix apples with speedboats. These are >>some options with the proposal: >> >>#1: no encryption is used either way, the list >>address is in a whitelist for each recipient. >> >>#2: each recipient can only send encrypted msgs >>(possibly, also signed) to the list, with the >>list's key, for distribution. The listserver >>verifies and resends the messages in plain text, >>where #1 applies for each recipient. >> >>#3: the list receives messages as in #2 but the >>listserver sends the msgs as encrypted mail to >>each recipient, with each recipient's key. > >#4 (my preferred) the member send a message to >the list with his digital signature. The list >checks the digital signature (from keyserver or >from a member database) and post the message if >signature is valid. If the signature is not valid, >the message is held for approval. But yes this >scheme does not offer much more than restrict >posting to list members only, which the IETF had >to do last year(?). if the list server signs each message that then allows recipients to positively identify mail from the list. this is *HUGE*. if i have an email account that only receives mail from mailing lists that sign all messages then i can dump all incoming non-whitelisted digitally signed email at the server and *know* that all my email is legit. thread: ietf - how not to filter spam ----- >>first, there is an increasingly heated debate >>between folks who want to sign the message (TEOS, >>DomainKeys), versus others who want to secure the >>channel between sender and receiver (RMX, LMAP, >>SPF, etc.). > >What does it matter what the resolution is? >Neither solution eliminates the spam channel, and >solves the problem, as information theory shows. >Its just a silly debate over two schemes to thread >a needle that can't be threaded. think of spam as a river passing through multiple channels, let's find a channel we can change. folks talk about spammers taking advantage of email protocols. another angle is to say that spammers take advantage of people's behavior. it's much easier to change my personal behavior and expectations with regard to email than it is for me to change an established internet protocol. so stop thinking about eliminating the ability to send spam and focus on *absolutely* identifying real email. spam will dry up as people are able to absolutely identify real email. >>That sounds like the old "authentication solves >>spam" hope. It was wrong before SMTP-AUTH and it >>is still wrong. > >Guess what, it is impossible to "solve" spam the >same way it is impossible to "solve" burglary. At >least with authentication you get to have >whitelists that work. If you get a message with my >email address in the "from" line it could be from >anyone. If it is signed with my PGP key you know >it came from me personally or someone went through >a LOT of trouble to get access to my private key >and the key phrase. > >The usefulness of authentication could be further >extended by building a web of trust where people >vouch for the fact that others aren't spammers. >Obviously spammers will slip through from time to >time, but anyone who spams or keeps vouching for >spammers will be removed from the web of trust. >But even if this part doesn't work authentication >is still useful. exactly thread: tidbits - digital signatures in tidbits -- --- >As I said earlier, I don't see the point of doing >it for this list, but the mechanism itself isn't >so easily spoofed. Think of it as an address >based whitelist with addresses that can't be >forged. A spammer wouldn't be able to get his own >public key on the whitelist, and can't pretend to >be someone else because he doesn't have the >corresponding private key. I personally wouldn't >use such a system, since the Bayesian spam filter >I use (bogofilter) works well enough, but people >that are more annoyed with spam than I get might >find such a system attractive. exactly, my bayesian filter (POPFile) works great, but i get so much spam that the 1% of my email that doesn't get classified correctly is causing me too much pain. >>>Then you have to start allowing attachments on >>>the list...not a great idea. >> >>Not necessarily. This should work as text only >>with PGP 8. >> >>Attachment converted: HHBV HD:PGP.sig (pgDS/---- >>) (002B8C8F) > >Obviously, it does not work except by allowing >attachments... and it's hard to believe that >TidBITS Talk would ever come to that. no, digital signatures can be inline, the mime attachment method is more robust but not required. so tidbits can be signed without mime attachments. FWIW, most email clients do support the mime method. >>There are plenty of uses for digital >>signatures, but I don't think approving mailing >>list postings is likely to be one of them any time >>soon. > >Agreed. Remember the messages that slipped >through were approved by Adam because of poor html >formatting, except one that forged his email. If >he used digital signatures most of those messages >still would've been signed, and just like Habeas >headers, if you're spam filter auto-whitelists >signed messages they would come through. exactly, if the list is signed spam can still get through. what the signature does is allow the mailing list traffic to be positively identified amidst the personal flood of spam many folks receive. just like we help list maintainers out by taking extra steps to allow posting, maintainers could help us out by signing all list messages. dealing with spam requires cooperation. >>I think people should sign all of their >>messages. That will have several effects: - Peole >>will get suspicious if a message isn't signed, >>making forging mesages harder. > >How do you handle email from a kiosk, or a cell >phone, or someone else's computer? There are too >many instances in the real world where this >happens. It's one of the benefits of IMAP..you >don't HAVE to be on any particlular computer to >get your email. by locating signature verification at the mail server level. create a procmail recipe that will automatically tag all signed email as to whether or not the signature exists in the personal whitelist that has been uploaded to the server. >I do think we're getting off topic but -- any >modern approach to the spam problem must take into >account the fact that at any given time the >Internet contains millions of insecure computers >that can be taken over by viruses and used as >zombies to, among other things, send spam. If >digital signatures were actually used in some >standardized way, it would be trivial for the >virus to grab it and sign its messages. again, digital signatures as an anti-spam technology will be effective for folks who don't *need* to be able to be contacted by anyone on the internet prior to them verifying they're not a spammer. folks that need to be this accessible need to either modify this requirement, continue to rely on statistical spam filtering tools, solve the key distribution problem, and/or work to change established internet protocols. >This assumes that you already have all the keys >of potential correspondents in your keyring, >which makes this just another form of >whitelisting, albeit a cryptographically secured >one. The shortcomings of whitelisting systems are >well described here and elsewhere, but basically >you'll have to read all your (signed) spam just to >make sure there isn't a message there from someone >you haven't whitelisted yet. Remember, too, that >public keys really should expire, so you would >need a method for keeping your whitelist (keyring) >up to date. If you try to automate the whitelist, >you open the door to spammers again. you are assuming the receipt of email from a large previous unknown group of entities. if this is you then you won't benefit from digital signatures adopted on a small scale. but if you are one of the many folks who only receives email from a small group of people then digital signatures ensure that you will never miss one of their messages. >I'm a big proponent of cryptographic signatures; >they just aren't the Final Ultimate Solution to >Spam. digital signatures don't do anything whatsoever to end spam - they allow spam to be sent to > /dev/null >Whitelists work great for those corresponding to >just a few people. But they simply aren't pratical >for participation in mail lists. at the very least a digitally signed list (by the list software/moderator) allows list recipients to identify list traffic. i do have my doubts about how impractical it would be for the list software/moderator to check for digital signatures prior to posting messages from list members. think gradual implementation, let go of the notion of all members signing their posts, although they might, and for every list member that does sign that's one less post to be analyzed to see if it's spam. >>Whitelists work great for those corresponding >>to just a few people. But they simply aren't >>pratical for participation in mail lists. > >Sure they are. You are missing the whole point of >how digital signatures would/should be >implemented in a discussion list environment. > >It's not the end user who needs to verify the >signature, it's the list processor. > >I subscribe to a list. As part of that process I >provide the public half of my key. Any message I >submit to the list is signed by me using my >private key. The list manager software then >verifies my signature and passes the verified >message on to the list or to the list moderator. >This ensure that only messages written by bonefide >members of the list get past on to the members of >the list. > >The whole point is not to ensure that messages >coming from the list are signed but to ensure that >messages submitted to the list are signed. > >This also obviates the need for the list to >support attachments and makes pgp/mime a BETTER >alternative to inline signing. The list processor >receives the messages, verifies the signature and >strips the signature. I, as a subscriber to the >list, never see the signature. > >Maybe, the list processor itself signs the >messages it sends out. In which case I only need >to have the one key (the public key for the list) >in my keychain. well said. i differ only in that i would start by having the list processor sign the list (what i perceive to be a simpler yet positive step) rather than trying to get list members to sign in order to post. >If we stop all counterspam measures by pointing >out that they aren't the Final Ultimate Solution >To Spam (TM), the situation will never improve. here! here!