Re: digital signature request
Folks, I think this thread has deviated enough from its original intent that the best place to continue it is on the ASRG list -- there's no point in bothering the entire IETF with yet another anti-spam discussion. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 25 February, 2004 04:50 Subject: digital signature request > 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 forwar
Re: digital signature request
"Robert G. Brown" wrote: > > Work and time burdens are not uniform or static because of Moore's law > [snip] What? Gimme a break. I can impose the exact time burden I want at each s step in a protocol -- I simply do not reply before the time I want elapses. This is SOP in any attack protection or congestion-control toolbox. There is NO Moore's law here. Work burden, when well-engineered with a time burden, can also certainly be added specifically when desired and without penalizing everyone. For example, work burden can be demanded when a message has a non-verifiable envelope --- it will NOT burden senders that have verifiable envelopes. Regards, Ed Gerck
Re: digital signature request
On Wed February 25 2004 16:15, Dean Anderson wrote: > There are many ways to reasonably accurately identify mail to this > list and distinguish it from all others: It is sent "to: > [EMAIL PROTECTED]". Nitpick: [EMAIL PROTECTED] could be in the Cc, or worse yet Bcc, field. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: digital signature request
[EMAIL PROTECTED] wrote: > see above response. also, from my perspective digital > signature verification is simpler than maintaining a > filter list. i'm tired of the spam/anti-spam arms > race. i'm going to deploy a solution that is > unspoofable. No, you aren't. You're quite welcome to try, however... anything that slows the spammers down is progress. -- Jake
Re: digital signature request
On Wed, 25 Feb 2004, Dean Anderson wrote: > There are many ways to reasonably accurately identify mail to this list > and distinguish it from all others: It is sent "to: [EMAIL PROTECTED]". > > I haven't seen very much spam that has that characteristic, so I don't > think such spam is much of a problem, if any problem at all. > > --Dean In fact, if you look at the full header: Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail.phy.duke.edu (Postfix) with ESMTP id C9DACA7836 for <[EMAIL PROTECTED]>; Wed, 25 Feb 2004 16:24:55 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Aw6QN-0006qR-OK for [EMAIL PROTECTED]; Wed, 25 Feb 2004 16:18:35 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1Aw6Ot-0006nT-O0 for [EMAIL PROTECTED]; Wed, 25 Feb 2004 16:17:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15076 for <[EMAIL PROTECTED]>; Wed, 25 Feb 2004 16:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6Os-0005Mn-00 for [EMAIL PROTECTED]; Wed, 25 Feb 2004 16:17:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6Ny-0005Hp-00 for [EMAIL PROTECTED]; Wed, 25 Feb 2004 16:16:07 -0500 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6NZ-0005Cg-00 for [EMAIL PROTECTED]; Wed, 25 Feb 2004 16:15:42 -0500 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i1PLFBMN028275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Feb 2004 16:15:12 -0500 Date: Wed, 25 Feb 2004 16:15:11 -0500 (EST) From: Dean Anderson <[EMAIL PROTECTED]> X-X-Sender: [EMAIL PROTECTED] you'll note that one can really be pretty certain a) that the message is really from the ietf list; b) that it was originally sent from a registered host whose IP number agrees with its claim of identity and whose owner likes the notion of secured mail; c) that email to the list is generically spam-scanned before being forwarded; d) that the [EMAIL PROTECTED] who authored the note is really who he appears to be and is accountable and hence is not about to hawk a website purporting to portray coeds showering and playing with their doggies on webcam. [Where it is parenthetically amusing to note that "hawk" means both to sell and to clear one's throat to spit out corrupt and tainted slime...] This is all BEFORE examining content. Then one can apply content filters at YOUR end at whatever level of analysis and rejection you are comfortable with. Obviously too-quick a rejection on simple keywords like "coeds", "showering" and "doggies" would be a mistake. This is all technology and protocol that exists now and in fact is in place now, and doesn't require OTHER people to do a thing. YOU have to do something -- take charge of your own spam-destiny, so to speak. Parsing a header isn't horribly difficult, either for a human or for a piece of software. I routinely do it visually if I have ANY DOUBT about a message from a stranger or a friend being "really" from the purported sender (for messages that make it through spamassassin). I also routinely do it if a personal message from a vendor (sales, but not spam) makes it through SA and I am considering answering. Messages without a perfectly formed header and all hosts along the delivery path both registered and identified correctly are rejected to the bit bucket pro forma. Spamassassin uses data parsed from the header for several of its tests, and not just for blacklist checks. Digitally signing a message to or from ietf adds absolutely nothing to your ability to determine whether or not it is spam except the necessity of maintain YET ANOTHER complex mapping between identity and number. We don't use the DNS-based one that we have as the rigorous basis of a protocol-level accept/reject decision, in spite of the fact that it is ubiquitous (and indeed already a critical component of the mail transfer process), reliable and at least crudely secure. At most lookups are used to drive blacklists, but we don't automatically blacklist mail from all unregistered/anonymous sites. Why in the world does anyone think that digital signature maps with several orders of magnitude more entities to track, more complexity, and hence more opportunities for spoofing and finagling are going to succeed where simple DNS hostname lookup has failed? IMO a "no anonymous mail" rule (no mail accepted anywhere from unregistered hosts) coupled with pretty stiff fines and legal penalties for spam would associate accountabilit
RE: digital signature request
On Wed, 25 Feb 2004 [EMAIL PROTECTED] wrote: > i have ~98% accuracy thanks to bayesian filtering. i > haven't calculated my false positive rate, but i get > false positives. even *one* false positive is > unacceptable. even if my filter accuracy was 99.99% i > would still need to trawl my spam folder to check for > false positives. and as the spam volume continues to > grow trawling the spam folder takes more and more > time. i need to stop false positives and digital > signatures are one possible solution. But they aren't. They won't stop false positives and they won't keep you from having to traverse your spam folder if your criterion is "no false positives". As has been pointed out, it is effectively impossible to make a filter that passes only signal and no noise, only desired communications and never undesired (especially given that the final decision is essentially human and subjecting and too complex for ANY filtering tool but your own mind). There is real math behind this, but it is really a common sense conclusion as well. So if your criterion is "no false positives" (a goal that is up there with a 100% efficient heat engine, winning the publisher's clearing house sweepstakes, and a free lunch:-), not only will you need to trawl your spam folder, you'll need to trawl it repeatedly, as you yourself probably make mistakes on what is spam and what isn't one in 10^4 or 10^5 times, if not more, especially on a rapid scan of hundreds of messages almost all of which are spam. It has been pointed out several times now that unless you are willing to receive mail only from a small, closed group of individuals that all agree to use digital signatures and whose mail you whitelist while blacklisting EVERYTHING ELSE you are right back where you are right now. Since you don't blacklist everything else, it gets filtered (or not) and you have to go through the rejects in a final pass. Who knows, one of them might be your long lost cousin Jimmy, trying to get in touch with you but alas not possessed of either your phone number, a digital key and knowledge of how to use it, and hence the means to communicate it to you and hence get on your whitelist. It requires an out of band communication for him to be admitted to your channel, and if you reject everything not in your channel, Jimmy's out of luck. Then there is the cruel fact that you aren't going to convince all the list managers in the world to digitally sign their list traffic. You can of course decide never to subscribe to a list that doesn't, but that throws a whole lot of baby out with the bath water, and again leaves you trawling rejects. The only issue in controlling spam is whether one BOTHERS to trawl the rejects. This, in turn, is related to the level at which you reject spam -- the ratio between false negatives (spam that makes it to your regular spool) and false positives (mail that makes it into your spam spool). I set my spam filtering high enough that I don't check the rejects. I've spot-checked the rejects for quite some time, and any "real mail" that gets rejected is VERY likely to be something I will survive if I never get, and if it IS important and for any reason the sender is a friend they will almost certainly send me an out of band communication in my mostly OPEN filter channel saying "Hey, why didn't you respond to my note letting you know that you won the sweepstakes in Nigeria and are about to be presented with a check by the grandson of its prime minister? I put a dozen URL's to the website announcing the result into the message when I sent it from my laptop through the open WiFi net I happened to be passing by..." Others set the filter lower, but quick-scan the rejects. Still others might set one breakpoint VERY high (and reject 70% of it out of hand with "no" false positives), set a second low enough that no spam at all makes it into their regular spool, and quick scan the intermediate rejects. Just by examining the SA rating of spam that makes it through and the rating of regular mail that makes it through, it is pretty easy to see whether or not your active boundary is reasonable. Digital signatures won't change this a bit. It may permit you to identify a certain class of true negatives (and keep them out of the false positive bin), although I at least am cynical about even that. It won't keep you from having a wide range of mail that you still have to filter and still have to review, if your criterion is "no false positives" and you want to remain globally accessible to mail from strangers, and the additional work it will require to implement so that you can even afford to implement it at all greatly exceeds the work you're doing now, or could be doing with a bit of rearrangement. rgb -- Robert G. Brownhttp://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED
RE: digital signature request
> From: "Robert G. Brown" <[EMAIL PROTECTED]> > ... > It has been pointed out several times now that unless you are willing to > receive mail only from a small, closed group of individuals that all > agree to use digital signatures and whose mail you whitelist while > blacklisting EVERYTHING ELSE you are right back where you are right now. > ... If you are interested in that model, then you do not need any fancy cryptography, certs, pretty good encryption, S/MIME, or anything else not already present in all SMTP mail. You can whitelist using bits that are already associated with every SMTP mail message and in the body delivered to your MUA if your MTA is not broken junk. Ever mail message carries a practically unforgeable (for spammers) token identifying its source. That token is the IP address of the SMTP client. If your MTA is reasonable, it is included in the Received header it adds. You only need fancy extra stuff if you cannot arrange for your community to use only trustworthy MTAs or if your traffic is worth the thousands of dollars (or equivalent labor) that breaking security based on IP addresses requires. Yes, I've heard of Bellovin, Mitnick, RFC 1948, etc. so forth and so on and on. TCP ISN faking is harder now than it used to be. It was always incompatible with the "bulk" in "unsolicited bulk mail." The spam problem starts with accepting mail from strangers. Give up that design goal, and spam disappears. So does much of the justification for mail. Vernon Schryver[EMAIL PROTECTED]
Re: digital signature request
On 26-feb-04, at 15:05, Robert G. Brown wrote: It has been pointed out several times now that unless you are willing to receive mail only from a small, closed group of individuals that all agree to use digital signatures and whose mail you whitelist while blacklisting EVERYTHING ELSE you are right back where you are right now. If we can communicate the fact that a message is discarded because it was categorized as spam back to the sender without adverse side effects, then occasional false positives aren't much of a problem. As for signing list messages: some practical experience would be good here. I'm not sure this list is the best choice to gain it, though.
Re: digital signature request
Vernon Schryver wrote: > > The spam problem starts with accepting mail from strangers. This phrase is a good soundbite. I'd add: The spam problem starts with *freely* accepting mail from strangers. If we force strangers to jump some hoops before their email can reach our mailboxes, it seems clear to me that we can still keep receiving email from strangers. Accountability (as in the "email caller ID" proposal by Microsoft) and identification (by requiring digital signatures) are not enough. They are locally restricted in the application of laws, jurisdiction, and enforcement. Rogue messages due to spoofing, worms and virus cannot be prevented either. Spam could still contaminate list traffic, even if list messages are signed by the listserver. Rubbish in, rubbish out. Even though the pain is at the output, the problem is not at the output. The problem is at the input, when we freely accept email from strangers. We need to provide mechanisms (plural) for selectively locking the input. Comments? Cheers, Ed Gerck
Re: digital signature request
> From: Ed Gerck > ... > If we force strangers to jump some hoops before their email can reach > our mailboxes, it seems clear to me that we can still keep receiving > email from strangers. That is the e-postage and other...I'm sorry but the best phrase is "snake oil." There is no and can never be a hoop that is low enough to pass enough human strangers but exclude spammers' computers. If your hoop passes mail from - the deaf - the blind - those who don't understand the spoken form of your native tongue as well as a computer - those who don't use graphics (e.g. lynx) - whose whose computers don't play audio files (mine doesn't) - those who don't have computers made within the last 5 years - the tired, confused, or intoxicated - the lazy or disinterested - the mentally challenged or just plain stupid then it will also pass mail from spammer's computers. The idea of forcing your correspondents to jump through hoops that spammers' computers can't is fundamentally wrong and crazy. If there is one good characterization of the difference between human and mechanical minds it is that machines are far better at jumping through hoops than we are. Computers are happy to try a bazillion times until they get it right. We get bored. A spammer's computer will happily continue trying to guess the answer to your puzzle as long as you let it, or look for it in a crib sheet of 1,000,000,000 clues. We not only won't; we can't. Only the meta-hoop of fear of prosecution might work. 419 spam demonstrates its severe limitations. Vernon Schryver[EMAIL PROTECTED]
Re: digital signature request
Vernon Schryver wrote: > > The idea of forcing your correspondents to jump through hoops that > spammers' computers can't is fundamentally wrong and crazy. Correspondents are also computers, humans don't do SMTP. > A spammer's computer will happily continue trying to guess the > answer to your puzzle as long as you let it, or look for it > in a crib sheet of 1,000,000,000 clues. Spammers need scale (because they get a very low return). Therefore, part of the solution should be to deny scalability to spammers. You seem to think that is not possible. However, it is trivial for a receiver to impose and enforce *both* work and time burdens to receive emails from strangers -- at the MTA *and* at the MUA levels. For example, my MTA could enforce large time delays at every step to complete the SMTP session if the headers contain something suspicious like "Received: from ([127.0.0.1])". Also, my MTA could require message encryption and/or MAC using *my* PK (imposing a burden per message). Look up tables and computational power cannot help spammers in such case. "Jumping through the hoops" is not optional and will take work and time, that my MTA can increase at will -- as much as might be necessary to be an effective deterrent to abuse by strangers. Cheers, Ed Gerck
Re: digital signature request
Which is a royal pain for me: my email client (mandated by work) doesn't alllow me to filter on CC: or BCC: addresses. Yuck. >>> Dave Aronson <[EMAIL PROTECTED]> 2/26/04 05:29:04 >>> On Wed February 25 2004 16:15, Dean Anderson wrote: > There are many ways to reasonably accurately identify mail to this > list and distinguish it from all others: It is sent "to: > [EMAIL PROTECTED]". Nitpick: [EMAIL PROTECTED] could be in the Cc, or worse yet Bcc, field. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services. This email has been scanned for computer viruses. Clint (JOATMON) Chaplin
Re: digital signature request
On Thu, 26 Feb 2004, Ed Gerck wrote: > Spammers need scale (because they get a very low return). Therefore, > part of the solution should be to deny scalability to spammers. You > seem to think that is not possible. However, it is trivial for a > receiver to impose and enforce *both* work and time burdens to receive > emails from strangers -- at the MTA *and* at the MUA levels. a) Moore's law b) Economics c) Arithmetic d) Clustering e) Human nature among many other reasons why this idea will not fly. Work and time burdens are not uniform or static because of Moore's law -- a modern system might be eight to thirty-two times more powerful than a nearly obsolete system on the same network. Are we going to deny people on the obsolete system the ability to send mail because we're trying to slow down the fastest system enough to make a difference? Economics alone would crush the idea. A large institution is already paying large sums of money supporting its primary MTAs because they are receiving hundreds of thousands to millions of messages a day. You propose to ask them to what -- double? triple? ntuple where n is whatever integer you think it has to be to STOP SPAM? They'd implement institutional-level MTA-based spam filters before they did that -- it would be cheaper. Then there is arithmetic. What, exactly, is enough of a work burden sufficient to be a burden to a spammer? A spammer who sends anywhere from 1 to 1 messages a day can make money, from what I've read. That is order of a message every 1 to 10 seconds, and very little of this time would be spent consuming bandwidth. Note that this is a tens to hundreds of times as much time as is currently required, and is NOT easy to arrange. Since the amount of arithmetic determines the ntupling of server expenses for every large mail operation on the planet, you are facing pressure from above to keep it cheap and from below to make it effective. Clustering, alas, will frustrate you. A spammer can afford to add cheap hardware for solving the problem at the high end of Moore's Law faster than legitimate shops can afford to add expensive and reliable hardware to handle enterprise mail. It won't even cost them more bandwidth, since they can easily make their 100K/day nugget with a fairly cheap ISP connection fronting their whole cluster. Finally, there is human nature. You proposed solution is cumbersome and expensive, a cure literally worse than the disease. Spam now is a hassle, but automated tools ameliorate it to a large extent for most users. Too many agencies at all levels of the internet would find it a hindrance with little advantage. So it will never be adopted. > For example, my MTA could enforce large time delays at every step to > complete the SMTP session if the headers contain something suspicious > like "Received: from ([127.0.0.1])". Also, my MTA could require message > encryption and/or MAC using *my* PK (imposing a burden per message). Or it could just reject them out of hand. Remember, the burden per message simply cannot be scaled to where a spammer would care without bringing the entire Internet's mail transport system to its knees. > Look up tables and computational power cannot help spammers in such > case. "Jumping through the hoops" is not optional and will take work > and time, that my MTA can increase at will -- as much as might be > necessary to be an effective deterrent to abuse by strangers. It would indeed, and that's the problem. In order to be effective, your MTA has to increase it to where it is as big a "deterrent" to use by strangers as it is to abuse by strangers. rgb > > Cheers, > Ed Gerck > -- Robert G. Brownhttp://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
Re: digital signature request
Can we don't pretend we can solve the spam problem on [EMAIL PROTECTED] james Iljitsch van Beijnum wrote: On 26-feb-04, at 15:05, Robert G. Brown wrote: It has been pointed out several times now that unless you are willing to receive mail only from a small, closed group of individuals that all agree to use digital signatures and whose mail you whitelist while blacklisting EVERYTHING ELSE you are right back where you are right now. If we can communicate the fact that a message is discarded because it was categorized as spam back to the sender without adverse side effects, then occasional false positives aren't much of a problem. As for signing list messages: some practical experience would be good here. I'm not sure this list is the best choice to gain it, though.
Re: digital signature request
On Thu, 26 Feb 2004, Robert G. Brown wrote: > Why in the world does anyone think that digital signature maps with > several orders of magnitude more entities to track, more complexity, and > hence more opportunities for spoofing and finagling are going to succeed > where simple DNS hostname lookup has failed? The reason is a little clearer when one considers that the main proponents of this idea have businesses or business plans to sell services for running the necessary infrastructure. As Bill Gates proved, the quickest way to astronomical wealth is to sell something very cheap to nearly everyone on the planet. Since then, many people have been trying to come up with similar schemes. Few have succeeded. > IMO a "no anonymous mail" rule (no mail accepted anywhere from > unregistered hosts) coupled with pretty stiff fines and legal penalties > for spam would associate accountability and penalty and cause an > immediate and drastic reduction of the problem. Holding ISPs (and > providers of open relays and proxies) liable for the fines of their > clients if they bolt or "have no assets" would give ISPs a very strong > incentive to police their clients. Obviously, the two would have to > come about together -- it is less useful to have fines and penalties > when the originating hosts have unregistered IP numbers that change > every two days and are nearly impossible to trace. There are reasons to have "anonymous email" as well as reasons to operate open relays**. Many ISPs operate open relays, and while the number of open relays continues to grow--few are open by mistake--the number of "spammers" abusing open relays continues to decline. Last May, the FTC reported that only 5% of spam involves open relays. Recently, I had a hard time finding an open relay abuse example in my current spamfolder. I'd says its now even less than 5%. Open relays provide no benefits to spammers that they don't already have. We also have email senders that only send mail, but don't receive mail. This type of mail is indistinguisable from anonymous email, because there is no way to "verify" the sender. But there are also reasons to have license-plate anonymous email as well, where the message isn't truly anonymous, but unless it is part of a criminal act, no one can find out the identity. It is a mistake to assume that only people use email. Below are two recent messages on the subject of Verizon "testing" whether an email sender receives email. This "test" isn't helping Verizon filter spam. In both the case I was responding to, and the case that Randy Bush was responding to, the people were experiencing problems with temporary SMTP error messages, and wondering what the problem was. On Sat, 21 Feb 2004, Dean Anderson wrote: > > Verizon is trying to do a "sender verification test". This is a dumb > idea whose time didn't come. But no matter. > > Here is a message from Randy Bush on the subject. I frequently disagree > with Randy, but in this case, I think he has the right idea. > > --Dean > > > = > > > I think he's saying that they were unable to perform the > > validation hence the 450. If the validation was successful, > > they'd return a 200 series code, if it was unsuccessful, they > > would return a 500 series code. > > nice words, but crap. due to needs to spool mail for sites in > countries with very poor connectivity, mail spool time here is > quite long. if verizon and others seem unable to decide in weeks, > why should i pay the penalty? > > but, i guess the problem is easily solved with exim config. i have > set it so that if it can not deliver to verizon in say one hour, it > dumps the mail. > > verizon.net* F,1h,5m > > life is simple, except for verizon users i guess. > > randy > > On Sat, 21 Feb 2004, Dean Anderson wrote: > Shouldn't reply to my own message. But in case it isn't clear, the > reason this is a bad idea is: > > 1) Performance. Verizon's mail server has essentially doubled its load. > If a mail server or nameserver (theirs or yours) is slow, it will cause > a temporary failure, as you saw. If their nameserver is slow, or one > fails, it will cause a performance knee with a storm of increasing defer > retries which will quickly bring the server to its knees. > > 2) Many sites monitor "NOQUEUE" connections, and automatically blacklist > those IP addresses which make too many NOQUEUE connections. A lot of > "testing" by Verizon will automatically get them blacklisted. > > 3) There is no guarantee that a from: address receives email. This is a > feature that spammers certainly exploit, but there is are legitimate > reasons for this: many machine email senders send mail and never receive > mail. Any mail for those robots will be rejected. So the premise of the > test (that every sender can be verified) is invalid. Of course, any one > stupid enough to violate 1 and 2 above, will certainly be unable to > grasp the subtlety of this.
Re: digital signature request
I should also note that my own message below that I quoted is hypocritical on my part. If the mail was IETF mail or other important email, I would have a different opinion. Of course, It was hypocritical of me to say that mail to others is any less important to its senders and recipients. I should not have encouraged this type of behavior. It shows that I too can be disgusted with things, and encourage an inappropriate response to stupid behavior. It is certainly something that one should try to avoid in oneself, and criticize in others. --Dean > On Sat, 21 Feb 2004, Dean Anderson wrote: > > > > > Verizon is trying to do a "sender verification test". This is a dumb > > idea whose time didn't come. But no matter. > > > > Here is a message from Randy Bush on the subject. I frequently disagree > > with Randy, but in this case, I think he has the right idea. > > > > --Dean > > > > > > = > > > > > I think he's saying that they were unable to perform the > > > validation hence the 450. If the validation was successful, > > > they'd return a 200 series code, if it was unsuccessful, they > > > would return a 500 series code. > > > > nice words, but crap. due to needs to spool mail for sites in > > countries with very poor connectivity, mail spool time here is > > quite long. if verizon and others seem unable to decide in weeks, > > why should i pay the penalty? > > > > but, i guess the problem is easily solved with exim config. i have > > set it so that if it can not deliver to verizon in say one hour, it > > dumps the mail. > > > > verizon.net* F,1h,5m > > > > life is simple, except for verizon users i guess. > > > > randy > > > >
RE: digital signature request
> From: [EMAIL PROTECTED] > ... > false positives. even *one* false positive is > unacceptable. even if my filter accuracy was 99.99% i > would still need to trawl my spam folder to check for > false positives. and as the spam volume continues to > grow trawling the spam folder takes more and more > time. i need to stop false positives and digital > signatures are one possible solution. Digital signatures cannot stop false positives. Even if all mail were digitally signed, there would still be cases where the wrong key was used, the right key did not reach the mail recipient before the mail message, a cert expires, or something else hiccups. The underlying error rate for SMTP before spam appeared was worse than 0.01%. Do you think that 99.99% of HTTPS (HTTP over TLS or SSL) transactions work? If so, look again. If not, why would email be better? If you cannot afford even one false positive, then you had better give up on email. My spam load is more than 300 messages/day, counting only unsolicited bulk advertising. I receive 50-150 legitimate messages per day. It would be impossible for me manually filter that stream to 99.99% accuracy and so overlook fewer than 1 legitimate message per 10,000 or fewer than one per month. No one can look at 10,000 messages per month, never misclassify any as spam or not, and do any other work. Talk about not losing even one message makes sense only if you receive almost no spam. People who talk about 99.99% accurate spam filters as if they were possible - don't know how computers work in the real world (e.g. have no idea why the phrase "key distribution" makes some people cringe or assume the tooth fairy handles key revocation) - don't receive much spam - are innumerate - are charlatans. - are two or more of the above. At least weekly I'm told of yet another final ultimate solution to the spam problem with 100% accuracy. They are all frauds, like weight loss diets without hunger or any other inconveniences. Sometimes they have creative definitions of "spam" and "false positive." Usually they are merely obvious wishful thinking and nonsense, like the hoary old claim that authentication (including digital signatures) will stop spam. Vernon Schryver[EMAIL PROTECTED]
RE: digital signature request
On 25 Feb 2004 at 12:16, Neil Carpenter wrote: > > the value in having the list processor sign all posts > > is simple. guaranteed identification of the list > > traffic for any recipient who decides to verify > > signatures. > > This seems to solve a non-problem. Unless there are spam messages that > where the sender has, for instance, forged the existing "Sender: > [EMAIL PROTECTED]" header, signing these messages will add nothing of > value. It seems much more likely that a spammer would simply send > e-mail to the [EMAIL PROTECTED] list & allow the list itself to propagate it > than that they would specifically forge that header. again, i'm not imagining that having the list processor sign all mail will stop spam from entering the list. the problem i need to solve is how to stop spam from being sent *directly* to me. accepting only email with whitelisted signatures will solve my problem. btw, i thought you needed to be subscribed to the ietf list prior to being able to post to the ietf list? On 25 Feb 2004 at 11:26, Stephen Sprunk wrote: > You have yet to demonstrate the problem you are trying to solve even > exists. > > I've gotten over 2700 spams this month, and zero of them have "ietf" > anywhere in them, either header or body. Thus, I see no compelling > reason for the ietf's list software to sign anything when a simple MUA > filter on the Sender: line already achieves 100% accuracy. see above response. also, from my perspective digital signature verification is simpler than maintaining a filter list. i'm tired of the spam/anti-spam arms race. i'm going to deploy a solution that is unspoofable. On 25 Feb 2004 at 12:06, Vernon Schryver wrote: > > From: [EMAIL PROTECTED] > > > > > Having the latest tools means nothing, unless > > > they are used right. Are > > > > i'm using them correctly > > I, for one, am unconvinced. I have had no trouble > filtering unwanted mail from this list, thanks to > procmail. My various filters have no trouble > dealing with more than 99.9% of the unsolicited bulk > mail including viruses and worms directed at my > mailbox. For my mail, my filters have a total false > positive rate (legitimate rejected divided by total > legitimate) of less than 0.1%. Whether your filters > are doing as well as you want them to does not seem > like a concern of the IETF. i have ~98% accuracy thanks to bayesian filtering. i haven't calculated my false positive rate, but i get false positives. even *one* false positive is unacceptable. even if my filter accuracy was 99.99% i would still need to trawl my spam folder to check for false positives. and as the spam volume continues to grow trawling the spam folder takes more and more time. i need to stop false positives and digital signatures are one possible solution. > > ... > > the value in having the list processor sign all > > posts is simple. guaranteed identification of the > > list traffic for any recipient who decides to > > verify signatures. > > I think it would be simpler for all concerned and in > this case just as effective if the IETF list > processor would offer to do SMTP-TLS and for an > appropriate cert to be published on http://ietf.org/ > > However, I would not suggesting that for any > practical or operational reason. It would merely > set a good example. i'm not familiar with SMTP-TLS but i will go read about it. FWIW, i think that digitally signing all list messages would also set a good example, and it too is a simple implementation. david
Re: digital signature request
On Wed, 25 Feb 2004 [EMAIL PROTECTED] wrote: > this is a request for this list to be digitally > signed by the list processor. > 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. There isn't any relation between "positively identifying the messages to this list", and "time spent culling spam". Since there isn't any connection, being able to positively identify messages to the list won't save you any time culling spam. > 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. There are many ways to reasonably accurately identify mail to this list and distinguish it from all others: It is sent "to: [EMAIL PROTECTED]". I haven't seen very much spam that has that characteristic, so I don't think such spam is much of a problem, if any problem at all. --Dean
Re: digital signature request
David Morris wrote: It also supposes that the private keys aren't protected with a passphrase. Nope. All you need is a keystroke monitor. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |I'm not imaginary. I'm ontologically challenged.| \/
Re: digital signature request
On Wed, 25 Feb 2004, Dave Aronson wrote: > On Wed February 25 2004 09:53, John Stracke wrote: > > > Dave Aronson wrote: > > > Requiring digsigs on a list would help cut down on spammers forging > > > list members' addies to spam "only members can post" lists. > > > > Not necessarily. Spam viruses would then start collecting people's > > private keys. > > Theoretically possible, but at least it would significantly raise the > bar. Also, I would suppose that the people who use digsigs (at least > with the current level of difficulty) are mostly clueful enough to > avoid most viruses! B-) It also supposes that the private keys aren't protected with a passphrase. The applications I use which use a pp key pair insist on a pass phrase. Such protection will make bothering to collect private keys quite a bit less interesting. Dave Morris
Re: digital signature request
On Wed February 25 2004 14:50, [EMAIL PROTECTED] wrote: > On 25 Feb 2004 at 12:10, Dave Aronson wrote: > > However, what does it gain us? Authentication that the message in > > question, was indeed sent via the IETF list. What does THAT gain > > us? The ability to separate it out from the spam. (Note also the > > assumption that anything sent to, or at least received from, the > > IETF list is NOT spam. That may hold for this list, but certainly > > not for all.) > > my intention is to move in the direction of accepting > only signed email. this will allow me to route > anything that doesn't include a whitelisted signature > to /dev/null. that's what having the list signed will > gain me. That's what it gains *you individually*, because of *your* specific plans. But that's not what the IETF is about. What does it gain J. Random Luser, or even any notable fraction of the users or organizations on the net? Nothing. What does it even gain the extant subscribers of this precise list? Again, nothing. > FYI, i made no assumption that a signed list would not > contain spam. in fact, i would be surprised if it did > not. Then the whole deal gains you next to nothing as a spam filter either. The whole deal gains you *only* the benefit of being one step further towards your goal of having your current legitimate contacts send you email with whitelisted digsigs. Of course, any NEW contacts will be a whole 'nother story. > if signature validation is positioned at the mail > server level then the tools you mentioned above can > still be used. signature validation at the mail > server level can add a header line to indicate > signature validation status. additionally, if > signature validation is located at the mail server > level you might also choose to route all unwhitelisted > mail to /dev/null so you don't have to download it. I still don't think it's going to be worthwhile, but at least this sounds technically feasible, though I doubt many ISPs would be willing spend the extra cycles to check sigs for you. Go to the appropriate Working Group, discuss the concept, find out if any related work has yet been done, and come up with a draft telling us exactly what this header should say, how anything else would have to modified to deal with it, the security implications (don't forget about forgeability of the header lines), etc. You may even get it accepted as an RFC, 'cuz with that approach, it sounds like there MAY be some benefits to SOME of the people whose email servers do such a thing, especially if someone runs a server where all the accounts expect to receive only properly signed emails. But even so, don't expect everyone, let alone the IETF, to start signing their outbound email. To get you started, here's what pops into my pointy little head: The final MTA will be responsible for signature checking. All other MTAs in the chain will not create nor, if somehow present, alter the header line. The final MTA will insert "X-Signature-Verification-Status: $VERSION $FINGERPRINT $STATUS". $VERSION is a non-negative integer denoting the version number of the header line. This is version 0. Later versions may only add to previous versions; removing items is prohibited, so as to maintain backward compatibility. $FINGERPRINT is the fingerprint of the key used. $STATUS is "Success", "Failure", "Unsigned", or "Forged $OLDSTATUS". $OLDSTATUS is again any of the above, recursively. A "Forged" status indicates that the message arrived with an X-Signature-Verification-Status line already in it, with a $STATUS of $OLDSTATUS. I cannot think of any reason why this would be legitimate; if you can, feel free to use a different indicator, but methinks it should still be indicated. This scheme might be doable by simply passing the email through an add-on, rather than modding the MTA itself. The MUA, when receiving or sorting mail, could filter on that header line the same way as any other. This includes whitelisting (or blacklisting!) various key fingerprints. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: digital signature request
On 25 Feb 2004 at 12:10, Dave Aronson wrote: > On Wed February 25 2004 11:50, [EMAIL PROTECTED] wrote: > > > i am very much wanting dialogue > > around the issue of having the list digitally signed > > by the list processor. > > If the folks who actually run the list find themselves a spare moment to > breathe (not likely so soon before or after the meeting in Korea), it > might be fairly easy to implement. > > However, what does it gain us? Authentication that the message in > question, was indeed sent via the IETF list. What does THAT gain us? > The ability to separate it out from the spam. (Note also the > assumption that anything sent to, or at least received from, the IETF > list is NOT spam. That may hold for this list, but certainly not for > all.) my intention is to move in the direction of accepting only signed email. this will allow me to route anything that doesn't include a whitelisted signature to /dev/null. that's what having the list signed will gain me. FYI, i made no assumption that a signed list would not contain spam. in fact, i would be surprised if it did not. > On the other claw, using the Sender line for that purpose has been > working just fine for me. (It's forgeable, sure, but I see no sign > that spammers have bothered to do so, and don't think it's likely that > they will in the future.) That's also trivial to set up in any decent > MUA. Same holds for the List-ID, X-Been-There, and other markers used > by most other mailing lists. Most cannot filter so easily (or at all) > on the presence/absence or [in]validity of a digsig. Sure, advanced > tools such as procmail certainly can, but many of us don't even find it > necessary to use such things at ALL yet, and they're awfully difficult > for Joe Luser to set up for his mail from RANDOM-L. if signature validation is positioned at the mail server level then the tools you mentioned above can still be used. signature validation at the mail server level can add a header line to indicate signature validation status. additionally, if signature validation is located at the mail server level you might also choose to route all unwhitelisted mail to /dev/null so you don't have to download it. > Zero net gain, for at least some (and likely much) additional effort. > Why bother? again, for me a significant gain, and i perceive that generating a key pair and configuring automatic signing of all list traffic will require a minor amount of effort. david
Re: digital signature request
> From: [EMAIL PROTECTED] > ... > > Having the latest tools means nothing, unless they are used right. Are > > i'm using them correctly I, for one, am unconvinced. I have had no trouble filtering unwanted mail from this list, thanks to procmail. My various filters have no trouble dealing with more than 99.9% of the unsolicited bulk mail including viruses and worms directed at my mailbox. For my mail, my filters have a total false positive rate (legitimate rejected divided by total legitimate) of less than 0.1%. Whether your filters are doing as well as you want them to does not seem like a concern of the IETF. > ... > the value in having the list processor sign all posts > is simple. guaranteed identification of the list > traffic for any recipient who decides to verify > signatures. I think it would be simpler for all concerned and in this case just as effective if the IETF list processor would offer to do SMTP-TLS and for an appropriate cert to be published on http://ietf.org/ However, I would not suggesting that for any practical or operational reason. It would merely set a good example. Vernon Schryver[EMAIL PROTECTED]
Re: digital signature request
Thus spake <[EMAIL PROTECTED]> > > > apologies to the folks whose comments i'm replying to for > > > not referencing their names (i didn't have the time). > > > > You ask us to take the time to implement a new mechanism of dubious > > value. > > the value in having the list processor sign all posts > is simple. guaranteed identification of the list > traffic for any recipient who decides to verify > signatures. You have yet to demonstrate the problem you are trying to solve even exists. I've gotten over 2700 spams this month, and zero of them have "ietf" anywhere in them, either header or body. Thus, I see no compelling reason for the ietf's list software to sign anything when a simple MUA filter on the Sender: line already achieves 100% accuracy. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
RE: digital signature request
>the value in having the list processor sign all posts >is simple. guaranteed identification of the list >traffic for any recipient who decides to verify >signatures. This seems to solve a non-problem. Unless there are spam messages that where the sender has, for instance, forged the existing "Sender: [EMAIL PROTECTED]" header, signing these messages will add nothing of value. It seems much more likely that a spammer would simply send e-mail to the [EMAIL PROTECTED] list & allow the list itself to propagate it than that they would specifically forge that header.
Re: digital signature request
On Wed February 25 2004 11:50, [EMAIL PROTECTED] wrote: > if it's not > too much trouble i do request that you browse through > the rest of my post. Already deleted, and I can't be arsed to go trash-digging right now. > i am very much wanting dialogue > around the issue of having the list digitally signed > by the list processor. Okay, my three cents (inflation): If the folks who actually run the list find themselves a spare moment to breathe (not likely so soon before or after the meeting in Korea), it might be fairly easy to implement. However, what does it gain us? Authentication that the message in question, was indeed sent via the IETF list. What does THAT gain us? The ability to separate it out from the spam. (Note also the assumption that anything sent to, or at least received from, the IETF list is NOT spam. That may hold for this list, but certainly not for all.) On the other claw, using the Sender line for that purpose has been working just fine for me. (It's forgeable, sure, but I see no sign that spammers have bothered to do so, and don't think it's likely that they will in the future.) That's also trivial to set up in any decent MUA. Same holds for the List-ID, X-Been-There, and other markers used by most other mailing lists. Most cannot filter so easily (or at all) on the presence/absence or [in]validity of a digsig. Sure, advanced tools such as procmail certainly can, but many of us don't even find it necessary to use such things at ALL yet, and they're awfully difficult for Joe Luser to set up for his mail from RANDOM-L. Zero net gain, for at least some (and likely much) additional effort. Why bother? -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: digital signature request
On 25 Feb 2004 at 9:22, Dave Aronson wrote: > On Wed February 25 2004 05:50, [EMAIL PROTECTED] wrote: > > > 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. > > Having the latest tools means nothing, unless they are used right. Are i'm using them correctly > > 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. > > Requiring digsigs on a list would help cut down on spammers forging list > members' addies to spam "only members can post" lists. Also, this is > one of the few lists where I'd think most people would be clueful > enough to do it. > > However, would it be worth the bother? Unless there's some poor sod if it wasn't clear, having list members sign messages in order to post isn't my request. it was just a comment about an additional possibility. > Here's an alternate angle for you to chew on. Try coming up with some > sort of mechanism that could easily be built into all MUAs, MTAs, > mailing list managers, anti-spam "solutions", and all other programs designing a complex total solution isn't an approach that works for me. in my experience small foolproof steps in the direction of my vision have proven to be much more fruitful. > > apologies > > to the folks whose comments i'm replying to for > > not referencing their names (i didn't have the > > time). > > You ask us to take the time to implement a new mechanism of dubious > value. the value in having the list processor sign all posts is simple. guaranteed identification of the list traffic for any recipient who decides to verify signatures. > Meanwhile, you won't take the time to mention ournames so that > we can at least go quickly to the part of your email that concerns us, > nor break it up into individual pieces so as to at least preserve the > subject lines. Talk about cooperating the posts i was replying to were part of lengthy threads around the same issue. my intention was to collect various concerns and reply to them to help elucidate my perspective. it was more efficient than trying to write commentary from scratch that covered all the same points. i wasn't looking for specific dialogue with particular posters. just wanted to use the existing dialogue to create a summary of sorts. if you look you should notice that i did create three sections (for the three different threads i pulled posts from): thread: ietf - proposal for built-in spam burden & email privacy protection - thread: ietf - how not to filter spam - thread: tidbits - digital signatures in tidbits - the quotes under each section are taken from those particular threads. > As for the lengthy conglomeration of your replies to other messages, > forget it, I for one am not slogging through that mess, even though I > see you replied to something I wrote. sorry you found the structure of my post unhelpful. i did attempt to make it easy to peruse. if it's not too much trouble i do request that you browse through the rest of my post. i am very much wanting dialogue around the issue of having the list digitally signed by the list processor. peace, david
RE: digital signature request
Depend where the private key are, and this option at least will be a barrier to spammers. Ramiro Muñoz AC Camerfirma SA -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de John Stracke Enviado el: miércoles, 25 de febrero de 2004 15:54 Para: [EMAIL PROTECTED] Asunto: Re: digital signature request Dave Aronson wrote: >Requiring digsigs on a list would help cut down on spammers forging >list >members' addies to spam "only members can post" lists. > Not necessarily. Spam viruses would then start collecting people's private keys. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |How many roads must a man walk down before he admits he is LOST?| \/
Re: digital signature request
On Wed February 25 2004 10:27, John Stracke wrote: > Dave Aronson wrote: > >On Wed February 25 2004 09:53, John Stracke wrote: > > > Not necessarily. Spam viruses would then start collecting > > > people's private keys. > > > > Theoretically possible, but at least it would significantly raise > > the bar. > > Only one person needs to figure out how to do it. Think script > kiddies. True again, but I still don't think that this additional usage of private keys would provide sufficient incentive for a virus author. What do they gain out of snarfing someone's private key, that they wouldn't gain without this proposal? (For those tuning in late, it has unfortunately been pushed off the top, but boils down to mailing list processors being able to require and verify digital signatures on members' posts.) It nets them the ability to spam digsig-protected mailing lists that the victim is on, until the victim cleans out the infection and changes his key. BFD. I suppose some twerp might do so just because he can, but I don't think this will provide the incentive. Admittedly, there are *other* existing incentives, and will probably be more as digitally signed and/or encrypted email becomes more popular and easier to use, but that's a whole 'nother story. These other incentives may cause such a virus to be written, and this mechanism may suffer as a result. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: digital signature request
Dave Aronson wrote: On Wed February 25 2004 09:53, John Stracke wrote: > Not necessarily. Spam viruses would then start collecting people's > private keys. Theoretically possible, but at least it would significantly raise the bar. Only one person needs to figure out how to do it. Think script kiddies. -- /=\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"So we've strapped a Patriot missile onto Snorky here." "You said| |that was a PROP!" "It's a *functional* prop." -- What's New, by | |Phil Foglio. | \=/
Re: digital signature request
gnulinux (now that's a verifiable identity): please do the work yourself - collect signatures for your petition by mail to you, not to the list admins. They are busy trying to make next week's meeting work. And please - point to working examples of lists using what you propose. Harald
Re: digital signature request
On Wed February 25 2004 09:53, John Stracke wrote: > Dave Aronson wrote: > > Requiring digsigs on a list would help cut down on spammers forging > > list members' addies to spam "only members can post" lists. > > Not necessarily. Spam viruses would then start collecting people's > private keys. Theoretically possible, but at least it would significantly raise the bar. Also, I would suppose that the people who use digsigs (at least with the current level of difficulty) are mostly clueful enough to avoid most viruses! B-) -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: digital signature request
Dave Aronson wrote: Requiring digsigs on a list would help cut down on spammers forging list members' addies to spam "only members can post" lists. Not necessarily. Spam viruses would then start collecting people's private keys. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |How many roads must a man walk down before he admits he is LOST?| \/
Re: digital signature request
On Wed February 25 2004 05:50, [EMAIL PROTECTED] wrote: > i'm making this request because i need a way to > positively id the messages from this list. Look in the normally-hidden headers. Most lists have something unique there. Usually it's something like a List-ID or X-Been-There line. In this case: > Sender: [EMAIL PROTECTED] If your MUA doesn't allow filtering on any header line you choose (including ones that aren't usually there), I seriously suggest you look into getting a new MUA. Okay, so it can be forged much more easily than a digsig. Big deal. I don't think any spammer is going to bother emailing us directly and forging that header. > 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. Having the latest tools means nothing, unless they are used right. Are you keeping your spam definitions up to date, by either subscribing to someone else's updates, or constantly building and refining your own database (such as with Bayesian filters)? Are you applying whitelists, AND heuristics? Are you also very carefully applying blacklists? Are you observing very carefully, and tweaking, just how "spammy" your heuristics have to label an email before you dump it? Are you holding the borderline cases for review? > 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. Requiring digsigs on a list would help cut down on spammers forging list members' addies to spam "only members can post" lists. Also, this is one of the few lists where I'd think most people would be clueful enough to do it. However, would it be worth the bother? Unless there's some poor sod already spending tons of his own time filtering out such spam already, I'd say no. (If there is, THANK YOU! Been there, done that, ripped up the T-shirt in frustration. You're doing a great job.) I can't recall when I've last seen a spam here. > 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. Eh? Why would compromise necessarily change the keys? How will they be notified? Can you guarantee that the compromise won't include blocking such notifications? What's the mechanism you envision for all this? Lay out a rough roadmap, and maybe we can work it up into a draft, and then have it accepted as an RFC. Here's an alternate angle for you to chew on. Try coming up with some sort of mechanism that could easily be built into all MUAs, MTAs, mailing list managers, anti-spam "solutions", and all other programs involved, such that a user can take some simple action to sign up for an email list, and have all email from that list automagically added to his whitelist, at each step of the chain, AND the list owner can verify irrefutably that Joe Luser (or at least someone at that email address) asked to be on the list, AND in a way that would be at least difficult, if not impossible, for someone to accidentally trigger by such simple actions as "previewing" an HTML email or viewing a web page. Never mind whether the list ID can be forged by spammers, whether the list requires digsigs on submissions, or other such irrelevant details; I'm only interested in automating the verified signup and whitelisting process. (Tho if you can automate that enough that Joe Luser groks it, that would be great!) That's an idea I came up with a while back and haven't had the time to put serious work into. > apologies > to the folks whose comments i'm replying to for > not referencing their names (i didn't have the > time). You ask us to take the time to implement a new mechanism of dubious value. Meanwhile, you won't take the time to mention our names so that we can at least go quickly to the part of your email that concerns us, nor break it up into individual pieces so as to at least preserve the subject lines. Talk about cooperating > spam is something we can eliminate by > changing our personal behaviors and expectations > and cooperating. Long ago that might have been true. Welcome to the Everlasting September. > and it can happen gradually. It will probably have to! As for the lengthy conglomeration of your replies to other messages, forget it, I for one am not slogging through that mess, even though I see you replied to something I wrote. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Servic
