Re: email and spam (was: Re: namedroppers, continued)
Another thought on the spam problem and Frequently Proposed Solutions in general: as a community we have become obsessed with ephemeral information. That is, we all sit in front of our terminals, read our email, (re-)invent new ideas, and spew them instantly across the world; these ideas are lost and forgotten in a week. The web does go some limited way towards creating archival information -- ideas that remain and can be used to inform later idea -- but it does not go far enough. Ultimately, the only way we can avoid regurgitating the same ideas over and over is to invest some of our effort in converting ephemeral information into truly archival information. This is a shift with some analogy to the shift of civilization that resulted from replacing conversations around the campfire with written words on tablets and in books. Creating competant and useful archival material is hard intellectual work, harder than sitting in front of our terminals, reading our email, (re-)inventing ... etc., but I believe it is the only real path to progress. In the Internet community, the RFC series of docuemnts has been perpetuated as an archival document series for this purpose. Bob Braden
Re: email and spam (was: Re: namedroppers, continued)
From: Bob Braden [EMAIL PROTECTED] ... Another thought on the spam problem and Frequently Proposed Solutions in general: as a community we have become obsessed with ephemeral information. That is, we all sit in front of our terminals, read our email, (re-)invent new ideas, and spew them instantly across the world; these ideas are lost and forgotten in a week. The web does go some limited way towards creating archival information -- ideas that remain and can be used to inform later idea -- but it does not go far enough. Ultimately, the only way we can avoid regurgitating the same ideas over and over is to invest some of our effort in converting ephemeral information into truly archival information. ... Archiving is useless unless people consult those archives. Those who continually re-invent (non-)solutions for spam will not be detered by archives any more than IPv8 advocates are bothered by the difficulties some people claim to see in representing more than 4,294,967,296 things with 32 bits. For example, those who think that authentication could stop spam won't change their minds because someone writes something more. If written words mattered, they'd know about RFC 2554, RFC 2487, RFC 2645, and RFC 2476 instead of insisting that SMTP should be replaced with a mail protocol that authenticates senders. The stream of non-solutions to spam not only ignores the existing literature, but also ignores itself. If the people pumping out the stuff would pause and look just little at other proposals, they'd notice their wonderful new idea flying by. That's the crux of the anti-spam excitement. We're watching a dot-com boomlet of hopes and dreams to get rich or at least famous by Finally Stopping All Spam. As with b-to-b, b-to-c, disintermediation, CMR, multi-media, and the other SuperHypeWay crazes, people are rushing to market regardless of history, archives, or any other consideration. Vernon Schryver[EMAIL PROTECTED]
Re: email and spam (was: Re: namedroppers, continued)
--On Wednesday, 15 January, 2003 18:17 -0800 Dave Crocker [EMAIL PROTECTED] wrote: John, Before someone makes suggestions about the magic bullet that will solve spam problems, they should at least familiarize themselves with the rather interesting range of startup company approaches to handling the problem. Everything ranging from keyword filtering by a commercial version of spamassassin, to patenting a haiku. And they should become familiar with the public policy and politics debates on the topic. This is a multifaceted problem, including the minor fact that people's definition of spam is highly variable. At this stage it appears clear that no single magic bullet is possible and that we should start viewing spam the way we view roaches. We don't like them. They are bad. We do a range of things to get rid of them. It all helps. But we do not eliminate them. We simply reduce them to a tolerable level. Is there some part of this with which you assume I disagree? john
Re: email and spam (was: Re: namedroppers, continued)
Dave, John, at least in the case of spamming, it seems there is an agreement on the interest of cataloging the internet engineering frequently proposed solutions, to get a complet picture of the various existing and dropped propositions. This might both help not to repeat the same propositions and, may be, to discover usefull variations or, anyway, to help the thinking. I understand that the difficulties would be: - this could be perceived as a way to laugh at propositions. This is not the idea, and it can be adressed in having the author registering himself his suggestion, with a field reserved to quote the corresponding drafts and/or resulting RFC(s). It would help to quote references in drafts. - this has neither to be verbose nor too terse. I would suggest a character limit and a link to a position page or a site (case of a commercial proposition) of the author. - this should help debates. The author should be able to update his text and links. - one needs the resources and staff. I am ready with anyone interested to start working on this if it may help. I made registered iefps.org by world@wide to that end (so we may freely discuss it). May be could ut be understood as internet engineering first proposed suggestions to make it some kind of historical repository (showing this is a positive service). Also a way to pay our common due to the initial good idea's proposers (like for the Cluster or the Catenet issues?). To do that we could think of a ticket system, the author may register and update further on (but not delete to keep it serious). It would ask for some classifications or keywords permitting to sort them by themes? jfc On 03:17 16/01/03, Dave Crocker said: John, Before someone makes suggestions about the magic bullet that will solve spam problems, they should at least familiarize themselves with the rather interesting range of startup company approaches to handling the problem. Everything ranging from keyword filtering by a commercial version of spamassassin, to patenting a haiku. And they should become familiar with the public policy and politics debates on the topic. This is a multifaceted problem, including the minor fact that people's definition of spam is highly variable. At this stage it appears clear that no single magic bullet is possible and that we should start viewing spam the way we view roaches. We don't like them. They are bad. We do a range of things to get rid of them. It all helps. But we do not eliminate them. We simply reduce them to a tolerable level. d/ Tuesday, January 7, 2003, 3:22:06 PM, you wrote: John Almost all of the measures you have suggested have serious John side-effects or critical prerequisites. In the last analysis, John most of us would rather put up with a little spam than pay the John prices involved. Others are sufficiently fed up with spam that John they are willing to consider some very radical changes to how we John use email. But, regardless of how that comes out, the decisions John have been fairly explicit: people have thought of your John suggestions, and others, and their impact, and have made fairly John explicit decisions about preferences. My comment about X.400 of John a few weeks ago was intended to address those issues, but John apparently made a reference too far in the past, or too subtle, John for some of the people who have been participating in the John discussion. d/ -- Dave mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com t +1.408.246.8253; f +1.408.850.1850 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/02
Re: email and spam (was: Re: namedroppers, continued)
John, Before someone makes suggestions about the magic bullet that will solve spam problems, they should at least familiarize themselves with the rather interesting range of startup company approaches to handling the problem. Everything ranging from keyword filtering by a commercial version of spamassassin, to patenting a haiku. And they should become familiar with the public policy and politics debates on the topic. This is a multifaceted problem, including the minor fact that people's definition of spam is highly variable. At this stage it appears clear that no single magic bullet is possible and that we should start viewing spam the way we view roaches. We don't like them. They are bad. We do a range of things to get rid of them. It all helps. But we do not eliminate them. We simply reduce them to a tolerable level. d/ Tuesday, January 7, 2003, 3:22:06 PM, you wrote: John Almost all of the measures you have suggested have serious John side-effects or critical prerequisites. In the last analysis, John most of us would rather put up with a little spam than pay the John prices involved. Others are sufficiently fed up with spam that John they are willing to consider some very radical changes to how we John use email. But, regardless of how that comes out, the decisions John have been fairly explicit: people have thought of your John suggestions, and others, and their impact, and have made fairly John explicit decisions about preferences. My comment about X.400 of John a few weeks ago was intended to address those issues, but John apparently made a reference too far in the past, or too subtle, John for some of the people who have been participating in the John discussion. d/ -- Dave mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com t +1.408.246.8253; f +1.408.850.1850
Re: email and spam (was: Re: namedroppers, continued)
Folks, Monday, January 13, 2003, 1:47:57 PM, you wrote: * Could we not think of an FPS (frequently proposed solutions) John Absolutely. But such a hypothetical author would have to be John very motivated. Would there be some benefit in taking the first step of simply listing FPSs, without doing their detailed documentation? d/ -- Dave mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com t +1.408.246.8253; f +1.408.850.1850
Re: email and spam (was: Re: namedroppers, continued)
--On Tuesday, 07 January, 2003 13:33 -0500 Doug [EMAIL PROTECTED] wrote: Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. This may seem to be a bit basic for some of the people who have worked on this problem for years. My intention was not to prove that I had the latest and greatest solution to the spam problem. It was to get the ball rolling in an open discussion forum and present my ideas on the topic in the hopes that someone who knew more than me on the topic would as well. ... Ok, Doug. Let me take a shot at simultaneously explaining the problem here and why your suggested solutions are getting such resistance. Perhaps a different approach may succeed where Lloyd's didn't (not his fault, I'm sure). Almost all of the measures you have suggested have serious side-effects or critical prerequisites. In the last analysis, most of us would rather put up with a little spam than pay the prices involved. Others are sufficiently fed up with spam that they are willing to consider some very radical changes to how we use email. But, regardless of how that comes out, the decisions have been fairly explicit: people have thought of your suggestions, and others, and their impact, and have made fairly explicit decisions about preferences. My comment about X.400 of a few weeks ago was intended to address those issues, but apparently made a reference too far in the past, or too subtle, for some of the people who have been participating in the discussion. The people who have been through it are reluctant to start the discussion again because the dead horse has been kicked into an unrecognizable pulp. There has been a good deal of discussion, in many archives, that it would be good for you to read. If you then come up with a _new_ idea that doesn't revisit the old problems, many of us would be enthused about listening. It is only the old and discredited proposals that are met with intolerance. Let me take a closely-related pair of examples from your note. As I understand it, you would like ISPs (really email providers) to take responsibility for authenticating their customers. And you would like IP addresses shown in mail header traces to be reliable. Ok. Those two things turn out to be much more about trust relationships than they are about protocols: one can make major changes to protocols without changing the trust relationships at all, and can accomplish those things without any changes in the protocols. But, assuming that you aren't willing to trust anyone who can operate a mail-sending protocol, there are only a few ways that you can trust the source and origins of email. For example, we could, as a society, start licensing email providers, require each licensed provider to accept mail only from other licensed providers and from users they can authenticate (with severe penalties for violating those rules). That would make folks who would like to go back to business models in which they charge for every item of mail very happy. It would make many of the rest of us unhappy. But it would work... and, while some protocol enhancements might make it easier to support, nothing is really required beyond SMTP as it exists today. Similarly, you could decide to work with an email mailbox provider who would refuse to accept mail from any site with which it didn't have an agreement about user authentication and traffic and which, were relaying permitted, would insist that any site from which it accepted a relayed message impose the same requirements on its users. With some prototype agreement forms, this could be a way to build up a trust web similar to the licensing one, using a web of bilateral agreements rather than governmental action. But either of those approaches would result in less legitimate mail getting through. For instance, I run my own mail servers and, as far as I know, can authenticate anyone who originates mail here. But I have neither the resources nor the inclination to participate in a large collection of bilateral contractual agreements, nor to start applying for licenses. The issues with those bad IP addresses are similar. Most are spoofed. You can trust the information in Received headers only as far back as the last mail host you trust to report information accurately. If there is a spammer deliberately deciding to deceive you, anything earlier is likely to be trash, not because the wrong information is in the Whois tables, but because the data in the Received fields is being made up (either at random or in the hope of pinning the spam on someone else). And, again, formalizing the trust relationships through contracts or licenses would help a great deal, and might be the only solution, but those options carry a high price in terms of generally accessibility and usability of email. regards, john p.s. Asking
Re: email and spam (was: Re: namedroppers, continued)
Dear John, I am afraid that at this stage (e-mail + 40 or so years) telling someone to read the archives has no meaning. And telling him to post if he has a _new_idea either. Could we not think of an FPS (frequently proposed solutions) where each defeated solutions would be listed and quickly discussed. There would be two good reasons: 1. to provide a true list of what has been proposed. It would save time to all and provide a good negative check list for those with an idea. At least it would be new to the FPS: it would be added or used. 2. very often the roots of the true solution is something which has been half thought and overlooked. Or something triggered in someone's mind by another idea. jfc PS. From what you quote, you seem to consider that SPAM=spoofing? Are there statistics and trends about that? On 00:22 08/01/03, John C Klensin said: --On Tuesday, 07 January, 2003 13:33 -0500 Doug [EMAIL PROTECTED] wrote: Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. This may seem to be a bit basic for some of the people who have worked on this problem for years. My intention was not to prove that I had the latest and greatest solution to the spam problem. It was to get the ball rolling in an open discussion forum and present my ideas on the topic in the hopes that someone who knew more than me on the topic would as well. ... Ok, Doug. Let me take a shot at simultaneously explaining the problem here and why your suggested solutions are getting such resistance. Perhaps a different approach may succeed where Lloyd's didn't (not his fault, I'm sure). Almost all of the measures you have suggested have serious side-effects or critical prerequisites. In the last analysis, most of us would rather put up with a little spam than pay the prices involved. Others are sufficiently fed up with spam that they are willing to consider some very radical changes to how we use email. But, regardless of how that comes out, the decisions have been fairly explicit: people have thought of your suggestions, and others, and their impact, and have made fairly explicit decisions about preferences. My comment about X.400 of a few weeks ago was intended to address those issues, but apparently made a reference too far in the past, or too subtle, for some of the people who have been participating in the discussion. The people who have been through it are reluctant to start the discussion again because the dead horse has been kicked into an unrecognizable pulp. There has been a good deal of discussion, in many archives, that it would be good for you to read. If you then come up with a _new_ idea that doesn't revisit the old problems, many of us would be enthused about listening. It is only the old and discredited proposals that are met with intolerance. Let me take a closely-related pair of examples from your note. As I understand it, you would like ISPs (really email providers) to take responsibility for authenticating their customers. And you would like IP addresses shown in mail header traces to be reliable. Ok. Those two things turn out to be much more about trust relationships than they are about protocols: one can make major changes to protocols without changing the trust relationships at all, and can accomplish those things without any changes in the protocols. But, assuming that you aren't willing to trust anyone who can operate a mail-sending protocol, there are only a few ways that you can trust the source and origins of email. For example, we could, as a society, start licensing email providers, require each licensed provider to accept mail only from other licensed providers and from users they can authenticate (with severe penalties for violating those rules). That would make folks who would like to go back to business models in which they charge for every item of mail very happy. It would make many of the rest of us unhappy. But it would work... and, while some protocol enhancements might make it easier to support, nothing is really required beyond SMTP as it exists today. Similarly, you could decide to work with an email mailbox provider who would refuse to accept mail from any site with which it didn't have an agreement about user authentication and traffic and which, were relaying permitted, would insist that any site from which it accepted a relayed message impose the same requirements on its users. With some prototype agreement forms, this could be a way to build up a trust web similar to the licensing one, using a web of bilateral agreements rather than governmental action. But either of those approaches would result in less legitimate mail getting through. For instance, I run my own mail servers and, as far as I know, can authenticate anyone who originates mail here. But I have neither the resources nor the inclination to
Re: email and spam (was: Re: namedroppers, continued)
--On Monday, 13 January, 2003 17:23 +0100 jfcm [EMAIL PROTECTED] wrote: Dear John, I am afraid that at this stage (e-mail + 40 or so years) telling someone to read the archives has no meaning. And telling him to post if he has a _new_idea either. You are entitled to your opinion. I was only trying to suggest that people who come to the IETF list, and propose the same old, failed, ideas as if they had just received a relevation from on high are likely to get some resistance... and to explain that resistance. Could we not think of an FPS (frequently proposed solutions) where each defeated solutions would be listed and quickly discussed. There would be two good reasons: 1. to provide a true list of what has been proposed. It would save time to all and provide a good negative check list for those with an idea. At least it would be new to the FPS: it would be added or used. 2. very often the roots of the true solution is something which has been half thought and overlooked. Or something triggered in someone's mind by another idea. Variations on this idea have been proposed to the IESG and IAB several times, and have not gone anywhere. I'll leave explanations as to why to someone else, but at a minimum, there has been a shortage of volunteers to maintain a dumb ideas archive (I know, that isn't quite what you said) and a shortage of entities willing to shield such volunteers from liability. PS. From what you quote, you seem to consider that SPAM=spoofing? Are there statistics and trends about that? There is certainly non-spoofed spam, including the many materials that claim one has subscribed to an opt-in list or and others that claim they are conformant to some law which never passed. I don't have any statistics that go beyond the anecdotal. But, if you look at the mass e-mailing software packages that are frequently advertised (not exclusively by spam), most of very proud of their capabilities to hide actual message origins and to use the facilities of others as relaying in supposedly-undetectable ways. Similarly, as Doug and others have observed, spam often comes with headers that are sufficiently spoofed to make addresses and other data useless. I assume --but cannot prove-- that all of these symptoms are indications that spammers know that messages that use consistent and accurate origin information are easily filtered out and discarded and that most ISPs have terms and conditions of service that prohibits using their facilities to spam. regards, john
Re: email and spam (was: Re: namedroppers, continued)
* Could we not think of an FPS (frequently proposed solutions) * where each defeated solutions would be listed and quickly * discussed. There would be two good reasons: * * 1. to provide a true list of what has been proposed. It would * save time to all and provide a good negative check list for * those with an idea. At least it would be new to the FPS: it * would be added or used. * * 2. very often the roots of the true solution is something * which has been half thought and overlooked. Or something * triggered in someone's mind by another idea. * * Variations on this idea have been proposed to the IESG and IAB * several times, and have not gone anywhere. I'll leave * explanations as to why to someone else, but at a minimum, there * has been a shortage of volunteers to maintain a dumb ideas * archive (I know, that isn't quite what you said) and a shortage * of entities willing to shield such volunteers from liability. John, True. However, a useful, and perhaps feasible, approach would be for a person knowledgable about the problem area to write an Informational review RFC about it. Such an RFC would review the problem, the suggested solutions, and their up/downsides. Such a document would not have to be complete to be very useful; a snapshot at a particular time would be a big step forward. Bob Braden
Re: email and spam (was: Re: namedroppers, continued)
--On Monday, 13 January, 2003 20:51 + Bob Braden [EMAIL PROTECTED] wrote: * Could we not think of an FPS (frequently proposed solutions) * where each defeated solutions would be listed and quickly * discussed. There would be two good reasons: * * 1. to provide a true list of what has been proposed. It would * save time to all and provide a good negative check list for * those with an idea. At least it would be new to the FPS: it * would be added or used. * * 2. very often the roots of the true solution is something * which has been half thought and overlooked. Or something * triggered in someone's mind by another idea. * * Variations on this idea have been proposed to the IESG and IAB * several times, and have not gone anywhere. I'll leave * explanations as to why to someone else, but at a minimum, there * has been a shortage of volunteers to maintain a dumb ideas * archive (I know, that isn't quite what you said) and a shortage * of entities willing to shield such volunteers from liability. John, True. However, a useful, and perhaps feasible, approach would be for a person knowledgable about the problem area to write an Informational review RFC about it. Such an RFC would review the problem, the suggested solutions, and their up/downsides. Such a document would not have to be complete to be very useful; a snapshot at a particular time would be a big step forward. Bob, Absolutely. But such a hypothetical author would have to be very motivated. Posting of an I-D would almost certainly produce a large amount of mail. Some would be sympathetic, others would make useful suggestions, still others would want to debate particular points based on more or less realistic perceptions about how the world works, the morals of spamming. Then the document would go to the IESG and RFC Editor. While I agree with your observation that completeness would not be needed for utility, previous experience predicts that IESG members would nit-pick the document, or just stall, until all of the points that any IESG member considered important were covered, and covered in a way compatible with that IESG member's views. If views on the IESG conflicted, the document could easily be help up forever, and I note that there is no appeal against IESG delay or failure to take an action. Then, again based on experience, the odds seem high that the RFC Editor would delay it, requesting editorial and formatting changes that are not covered in any written style manual, not responding to questions about those requests for weeks or months at a time, and so on. The combination of these processes could easily lead to a delay of six to nine months or longer between the time the author thought he or had a finished document and the time of publication, by which time the document might well be obsolete (producing more abuse for the author). So, while I agree that such a document would be useful, I would imagine that someone would need to be either extremely motivated or quite naive about how IETF and the publication process functions to try writing it. It is, unfortunately, much easier to ignore repetitions of unworkable ideas and possibly to try to briefly explain the problems with them. regards, john
Re: email and spam (was: Re: namedroppers, continued)
On 21:06 13/01/03, John C Klensin said: --On Monday, 13 January, 2003 17:23 +0100 jfcm [EMAIL PROTECTED] wrote: Dear John, I am afraid that at this stage (e-mail + 40 or so years) telling someone to read the archives has no meaning. And telling him to post if he has a _new_idea either. You are entitled to your opinion. I was only trying to suggest that people who come to the IETF list, and propose the same old, failed, ideas as if they had just received a relevation from on high are likely to get some resistance... and to explain that resistance. I know and I agree. My point is 40 years of reading is somewhat long and uncertain. Could we not think of an FPS (frequently proposed solutions) where each defeated solutions would be listed and quickly discussed. There would be two good reasons: 1. to provide a true list of what has been proposed. It would save time to all and provide a good negative check list for those with an idea. At least it would be new to the FPS: it would be added or used. 2. very often the roots of the true solution is something which has been half thought and overlooked. Or something triggered in someone's mind by another idea. Variations on this idea have been proposed to the IESG and IAB several times, and have not gone anywhere. I'll leave explanations as to why to someone else, but at a minimum, there has been a shortage of volunteers to maintain a dumb ideas archive (I know, that isn't quite what you said) and a shortage of entities willing to shield such volunteers from liability. h. Let take it another way. Would it help if we set-up a place where each proposition could be registered in a few lines by the proposer or dead ends documented by old-timers? Instead of flaming proposers, they could just advise them to register their propositions first. The flaming would still be here but the register would be built. As to know if it would be a dumb or a too brillant ideas archive :-) jfc
Re: namedroppers, continued
In that environment, anybody can get around what you're proposing by setting up their own first hop mail server. Or n hop mail server, for that matter. Melinda
Re: namedroppers, continued
On Mon, 06 Jan 2003 18:08:44 EST, Doug said: You can tell the difference between 1, 2, and 3 because they all have a different DNS/IP footprint. They do? Are you sure of this? I'll give you a hint - if you're outside the two /16's of our network, and you get an inbound SMTP connection from us, looking up the PTR to get the hostname will almost certainly *NOT* have the string 'mail' in it. And the inbound and outbound mail servers at ietf.org are called 'odin' and 'ran', respectively.. Not much info there. And last I heard, about 30% of the PTR space is broken beyond use due to cluenessness on the ISP's part, so you can't get a DNS name you can trust. So what DNS/IP footprint were you planning to use? You can send email directly to the IETF mail server? Yes, sometimes multiple times an hour if I'm in a verbose mood... Do you have an account on that server? Nope, no account there. Don't need one, works fine.. I myself use a SMTP server to send out my email. It goes from my email client to the SMTP server I happen to be using and it then gets relayed through the network until it reaches the destination email server. OK.. to be *very* pedantic, I use an SMTP server as well. My MUA (Mail User Agent) exmh hands the mail to the SMTP server I happen to be using, and the SMTP server relays mail everyplace. It just happens that my preferred SMTP server happens to be already running on my laptop I am not suggesting that the destination email server should ask for authentication for every email it receives before it relays it on to another mail server or a client. I am saying that the originating server should ask for it before accepting it and relaying it on to the network. Aha. I see now. What you *want* is what all properly run mail servers *ALREADY* do. It's amazingly useful for tracking down users that are being silly and need a slap upside the head to clear the kloo blockage. What it's NOT useful for is stopping the determined spammer who doesn't use your mail server to inject the mail into the net The reason it doesn't stop spam is because you're missing an important point - you seem to think that if the sending server validates the user, we won't have spam.. authenticate with the server. This in effect means that you cannot use a different return/reply address (or a fake return/reply address) that Hmm.. so the mail I'm replying to wouldn't work, because I got it from the IETF server but it has your From: address on it - therefore the IETF server must be lying about who it is and who the sender is. Actually, that's not quite true - there's usually cannot be traced back to your account on the originating server by the recipient or an IP/DNS footprint that cannot be traced back to your machine or a point on your network by the recipient. This is to force the person sending the email to be accountable for the email sent. OK.. and this is *forcing* it *how*? Think carefully here - the receiving end is trusting what the sender sends. and account status on that server. The server would then tag information onto the email that would identify the machine on which the email client that sent the email resides (not the information of an unsecured proxy). In addition, the originating server should tag information that identifies the account (on the originating server/network) that the client used to send the email and force the originating client to provide a valid reply address that is associated with the account to the recipient of the email. And of *COURSE*, not even a SPAMMER would be so unrighteous as to forge a this mail was approved header. This mail has a 'X-Verified-Sender-Address:' header that identifies the originating address. Take a look at it, and tell me if you feel any better about having verified the origin. And remember that since I control my machine, I can make a similar change to any *OTHER* header (From:, Sender:, X-Authenticated:, or whatever). And the spammer controls his server /Valdis msg09916/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
At 13:05 07/01/03, Lloyd Wood wrote: Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. Doug has also come up with the idea of adding the IP address of the originating client machine (not necessarily using SMTP) in a header so that an attempt can be made to identify it - e.g. Hotmail has done that for years. missing mail admin experience, I think. This remarks shows that the problem is around for more than ten years and that no one found a satisfactory solution in using the present system. Would this feed back from real world not be enough for us to understand its 'cybernetic' (true meaning) lesson : the current mail system model is inadequate. Question now is : do we have to investigate a new one? or can an architectural change/addition may elegantly address the case? probably a mix of both due to the existing e-mail system use. ie a new e-mail system with a retro-compatibility with the current one. Or would it also be a new TCP/IP design, compatible with the old one? Or/and a new IPv6 compatible with the old one? May be Dick Clarke will tell us next week how much he wants to invest into such a Nextnet? jfc
Re: namedroppers, continued
Hello Mr. Wood, - Original Message - From: Lloyd Wood [EMAIL PROTECTED] To: Doug [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:05 AM Subject: Re: namedroppers, continued Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. This may seem to be a bit basic for some of the people who have worked on this problem for years. My intention was not to prove that I had the latest and greatest solution to the spam problem. It was to get the ball rolling in an open discussion forum and present my ideas on the topic in the hopes that someone who knew more than me on the topic would as well. Doug has also come up with the idea of adding the IP address of the originating client machine (not necessarily using SMTP) in a header so that an attempt can be made to identify it - e.g. Hotmail has done that for years. After examining the headers of many of the spam advertisments I get and trying to contact the administrator of the network it came from I find that it is usually futile because the network doesn't exist and the IP information is incorrect. I also find that most use false sender and reply address information (in an attempt to keep recipiants from filtering them). This makes it hard (at least for me) to do anything about them. I have experimented with filters for subject wording but this unfortunately hits on some of my wanted email as well. This reduces my ability to to block them on the receiving end. Even if I could it doesn't help the net congestion they cause or do anything about the processing time it is using across the net. These things leads me to propose that a more global solution needs to be implemented. The problem here is that when you bring this up for discussion in a professional environment like this one people don't want to discuss it. Instead they consider it a problem that has no solution and just want to forget about it. L. missing mail admin experience, I think. Very true. I have never administered anything other than my http and ftp servers. I have thought of turning on the mailserver but I do not know enough about administering it yet and I really have no need for it. I certainly hope that nobody thought I actually ran my own mail server because I was not my intention to pretend that I did. It is nice to see someone with more knowledge and/or experience on the topic than me taking the time to think (and talk) about it. Thanks for the input, Doug Asking questions, presenting possible solutions, and learning from mistakes is how we get solutions. ---snipped previous for sake of size--
Re: namedroppers, continued
On Tue, 07 Jan 2003 13:33:28 EST, Doug said: After examining the headers of many of the spam advertisments I get and trying to contact the administrator of the network it came from I find that it is usually futile because the network doesn't exist and the IP information is incorrect. I also find that most use false sender and reply address information (in an attempt to keep recipiants from filtering them). This makes it hard (at least for me) to do anything about them. The trick here is to remember that except for the relative few spammers that are advocating a religious/political/philosophical viewpoint (a la Uncertainty Principle is Untenable!), the spammers *WANT* you to be able to contact them via *some* means - they can't extract money (their usual goal) from you if you can't get back to them. Moreover, it has to be relatively simple to find - it has to be simple enough that even a victim who doesn't have enough kloo to stop to wonder why the confidential and private Nigerian scam arrived via spammage can figure out how to get aboard -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09919/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Tue, 07 Jan 2003 15:26:55 -0500, [EMAIL PROTECTED] wrote: The trick here is to remember that except for the relative few spammers that are advocating a religious/political/philosophical viewpoint (a la Uncertainty Principle is Untenable!), the spammers *WANT* you to be able to contact them via *some* means - they can't extract money See www.camblab.com/nugget/extermin.htm If the contact data are invalid, report to RIR or to ICANN. They are obliged to correct the data. Jeffrey Race
Re: namedroppers, continued
Doug, This topic comes up quite often. It has been discussed at length many times. Do not take criticism of your ideas too harshly, it is just that most people here have seen these same solutions proposed by many people over many years. It gets a bit old and, patience gets a bit short. A very quick summary of the solutions proposed during these discussions is as follows: A) Anybody can send mail to anybody (what we currently have.) B) Mail servers check that the sender is authorized to send mail to the users of its system. C) Sending mail requires some sort of computationally expensive to compute, easy to check, data to be sent along with messages (probably based on sender address, receiver address and message) Unfortunately, B requires that there be some way to authenticate users of other systems. The only way that has been thought of to do this is to have some central authority to do this. While it is certainly possible, this is thought to be a bad idea for many reasons, the most prominent of which is the potential for abuse. Lacking a central authority, this can be done on mail servers already, with no need to involve the IETF (an example would be whilelists.). Unfortuantely, C would have to be computable in a reasonable amount of time in order not to be a major headache. This means that the spammers large cluster of powerful computers would still be able to send many messages. It would also wreak havoc with mailing lists. It would also become easier to compute as time goes on, due to the ever progressing nature of computers. This does not even take into account that we would be creating a standard with the sole purpose of inefficiency, which probably makes most engineers wince and, although that may not seem like such a horrible idea right now, this standard could survive far into the future, with implications yet to be known (keep in mind the scale on which these standards will be implemented.) If another solution is implemented in the future, this may come back to bite us. At the moment, it seems the IETF consensus (notice the *seem* here, this is my personal opinion taken from reading the discourse on these lists) is that the best solution is A. At some point another solution may hold the majority favor, but that time is not now. Of course, it is possible that there is a solution that has not been thought of, in which case it is a bad idea to discourage people from thinking about it. Know, however, that this list contains many extremely arrogant (many of them justifiably so) experts in their chosen field, who dislike their time being wasted. I encourage you, if you have further ideas, to do the required research to see if it would work before sending a message and, be very thorough. Also know that if you choose to get into a flame war with people on this list, that some them have likely been doing this for decades and, are probably much better at it than you are. It is likely to do nothing but frustrate you. If you have another idea and, have questions about how to check that it is at least feasable, I would be happy to point you in the right direction. -Daniel Pelstring - Original Message - From: Doug [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Lloyd Wood [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 1:33 PM Subject: Re: namedroppers, continued Hello Mr. Wood, - Original Message - From: Lloyd Wood [EMAIL PROTECTED] To: Doug [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:05 AM Subject: Re: namedroppers, continued Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. This may seem to be a bit basic for some of the people who have worked on this problem for years. My intention was not to prove that I had the latest and greatest solution to the spam problem. It was to get the ball rolling in an open discussion forum and present my ideas on the topic in the hopes that someone who knew more than me on the topic would as well. Doug has also come up with the idea of adding the IP address of the originating client machine (not necessarily using SMTP) in a header so that an attempt can be made to identify it - e.g. Hotmail has done that for years. After examining the headers of many of the spam advertisments I get and trying to contact the administrator of the network it came from I find that it is usually futile because the network doesn't exist and the IP information is incorrect. I also find that most use false sender and reply address information (in an attempt to keep recipiants from filtering them). This makes it hard (at least for me) to do anything about them. I have experimented with filters for subject wording but this unfortunately hits on some of my wanted email as well. This reduces my ability
Re: namedroppers, continued
--On mandag, januar 06, 2003 02:01:27 -0500 Doug [EMAIL PROTECTED] wrote: Your proposal would fix the problem, but end up tossing a large quantity of babies out with the bathwater. The problem is that for the case of a mailing list, you have *4* (at least) things to keep track of: There are many comercial email servers that require the people sending email with their server to log into the server using a valid username and pass before doing so. I doubt they are losing any valid emails. All it does is to keep unauthorized users from using the server without a valid password. The reason to require that the sender address in the outgoing email matches the email address refrenced in the account is to keep people from sending spam from these email servers and using fraudulant return and/or sender address. I fail to see how this throws out any babies. perhaps I am missing something. wellthink about how mail from someone who is not an user of that system (like me) can send mail there how does your system tell the difference between a remote mail server and a malicious user? Harald
Re: namedroppers, continued
On Mon, 06 Jan 2003 02:01:27 EST, Doug said: There are many comercial email servers that require the people sending email with their server to log into the server using a valid username and pass before doing so. I doubt they are losing any valid emails. All it does is to keep unauthorized users from using the server without a valid password. The reason to require that the sender address in the outgoing email matches the email address refrenced in the account is to keep people from sending spam from these email servers and using fraudulant return and/or sender address. I fail to see how this throws out any babies. perhaps I am missing something. What you're missing is that I can configure *MY* server so it will only: 1) Accept mail *TO* a local recipient. 2) Allow relaying of mail to a *remote* recipient after doing some sort of authentication that it's one of my users. And in fact, the last I heard, open relays were only 1% or so of the total mailservers out there - so the above is already the usual state of affairs. Note there's no requirement that *inbound* mail be authenticated, which is the basic source of the spam problem. Your mail server will probably accept mail for your userid from anyplace without authentication. Now let's say you *do* start requiring authentication for inbound mail. Let's consider this piece of mail, which is being sent to both you and the IETF list... 1) What userid/password does the IETF mailserver use to authenticate itself to your mail server? Remember in your answer to note that forcing users to manually update a whitelist of mailing lists they are on is a helpdesk nightmare, and hard to scale - our main mailserver has some 80K mailboxes/aliases on it, and I'm on a lot of lists. However, just because *I* am on a list hosted at some site doesn't mean that any other users on my mail server wants to accept mail from that site. However, even if you decide *that* cost is toleralble, there's still: 2) What userid/password does my laptop use to authenticate itself to your mail server? And note that you can't just say my laptop has to send it to my mail server - because then you need to get the userid/password pair to my mail server. Remember that your answer has to scale to 40 million .coms, and that it has to work on a sender/recipient pair basis (otherwise, it's like inviting a vampyre in - if they can get one person at your server to OK the mail, then they can commence spamming all your users). Note that answers like the reply to this message to prove you're not a spammer schemes are *NOT* a long-term solution - if any of those packages becomes widespread enough to actually impact the spam problem, the spammers will have a little Perl program scanning the bounces and canning the yes I'm not a spammer responses. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09901/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
I believe the answer to your first question is you would send mail using your own mail server not someone else's. Although...I do see unique issues involved in people using mail servers that are not part of their network (hotmail, yahoo...) to send email if they try to authenticate you as part of their network before allowing you to send email. I believe the solution to that problem is that those commercial mail servers (free or premium) would not be able to authenticate you as part of their network before allowing you to send your email. They would then require clients logging into those accounts (with valid user names and passwords) to send email from a valid IP address with no unsecured proxy services running on them (much like many IRC servers are doing) and transmit this IP information along with the email being sent. This would allow for pinpoint identification of the sender's using IP addresses MAC addresses and time stamped logs for the specific purposes of taking legal action against these network abuses. Your second question is a bit harder for me to answer. I believe (I may be incorrect) that there is already a difference between a receiving mail server's transaction with a sending or relaying mail server and a mail client. I would never claim that it is impossible for a malicious user to do anything (I know better). On the other hand if we can achieve authentication before sending email and it becomes a requirement of the system then it should make the actions of a malicious user stand out in the logs of the server allowing for tracking, blocking, and prosecution of those users for the unauthorized access and (mis)use of private network resources. My solution does NOT have a way of completely stopping spam from being sent but perhaps in conjunction with other actions it can stop a majority of spam from being sent. Additionally, my solution makes it easier for end users and administrators to track the actions of spammers and find their virtual locations. I would further suggest that once this information is gathered and verified with the spammers ISP subpoenas, court orders, cease and desist orders, fines under existing laws, and criminal prosecution could do the rest. I am not claiming that this will eliminate spam on it's own. I am claiming that it will make it harder for the offending parties to get away with sending spam in a manner that is not compliant with TOS agreements and the law. This solution would require a concerted effort by the administration comunity as a whole and I think that is where the problem truely is. - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: Doug [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 10:00 AM Subject: Re: namedroppers, continued --On mandag, januar 06, 2003 02:01:27 -0500 Doug [EMAIL PROTECTED] wrote: Your proposal would fix the problem, but end up tossing a large quantity of babies out with the bathwater. The problem is that for the case of a mailing list, you have *4* (at least) things to keep track of: There are many comercial email servers that require the people sending email with their server to log into the server using a valid username and pass before doing so. I doubt they are losing any valid emails. All it does is to keep unauthorized users from using the server without a valid password. The reason to require that the sender address in the outgoing email matches the email address refrenced in the account is to keep people from sending spam from these email servers and using fraudulant return and/or sender address. I fail to see how this throws out any babies. perhaps I am missing something. wellthink about how mail from someone who is not an user of that system (like me) can send mail there how does your system tell the difference between a remote mail server and a malicious user? Harald
Re: namedroppers, continued
On Mon, 06 Jan 2003 14:38:09 EST, Doug [EMAIL PROTECTED] said: I believe the answer to your first question is you would send mail using your own mail server not someone else's. Although...I do see unique issues involved in people using mail servers that are not part of their network (hotmail, yahoo...) to send email if they try to authenticate you as part of their network before allowing you to send email. You're still missing the point. How do you tell the difference between: 1) The IETF mail server sending for the IETF list. 2) The large SUN box across the hall that's the main vt.edu mail server. 3) My laptop. Currently, my laptop will send directly to the destination. The problem is that although it would be trivial to change it so that it uses the central Virginia Tech mail hub, that doesn't fix your problem - there's still no authenticator for the vt.edu mail server at your mail server either Oh, and don't even suggest chasing MX records - the MX for vt.edu points at one set of boxes, but you will almost certainly *NOT* get a connection from them, as our outbound servers are at different addresses. And no, we won't change this unless you first manage to get hotmail.com and aol.com to not use different inbound and outbound addresses first, as they do the same thing for the same reasons. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09908/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
I am apparently missing something here but I am going to give it a shot anyway. You can tell the difference between 1, 2, and 3 because they all have a different DNS/IP footprint. You can send email directly to the IETF mail server? Do you have an account on that server? I myself use a SMTP server to send out my email. It goes from my email client to the SMTP server I happen to be using and it then gets relayed through the network until it reaches the destination email server. The validation I have been referring to would take place between the mail client and the originating server. The entire point would be to verify the identity of the person sending the email or at least the account it is being sent from. I am not suggesting that the destination email server should ask for authentication for every email it receives before it relays it on to another mail server or a client. I am saying that the originating server should ask for it before accepting it and relaying it on to the network. The originating server would then be able to assure correct header information by not allowing an email to be sent unless the outgoing email was tagged with the proper DNS/IP footprint (not that of an unsecured proxy server or a spoofed IP) and a return/reply address that is associated with the account that the client used to authenticate with the server. This in effect means that you cannot use a different return/reply address (or a fake return/reply address) that cannot be traced back to your account on the originating server by the recipient or an IP/DNS footprint that cannot be traced back to your machine or a point on your network by the recipient. This is to force the person sending the email to be accountable for the email sent. I am not suggesting that the recipient or even the relaying server should be allowed to connect back to the originating mail server or the client that sent the email. That would create security risks for networks hosting mail servers and clients sending the email. I am suggesting that before someone drops an email onto an originating mail server that the server should take what I consider to be reasonable steps to authenticate the user and confirm their identity and account status on that server. The server would then tag information onto the email that would identify the machine on which the email client that sent the email resides (not the information of an unsecured proxy). In addition, the originating server should tag information that identifies the account (on the originating server/network) that the client used to send the email and force the originating client to provide a valid reply address that is associated with the account to the recipient of the email. I am not suggest that originating servers should be tagging the exact virtual location of an inbound or outbound server to anything or changing MX records to reflect the correct virtual location to the outside world. In fact, if this is not done it helps keep those outbound email servers hidden from the outside world and helps keep malicious users from finding them and exploiting them in some way to send their email without authorization. I do feel that I should be able to identify the actual network on which that server resides so I can contact someone there to help track down someone who is sending spam. Does the above clear up any confusion? Is there anything I am missing here? If so please tell me what because I would welcome the opportunity to learn something new. There may very well be big gaps in this plan I am just unaware of what they are so I welcome the opportunity to learn that you or anyone may pointing them out would bring. Doug [EMAIL PROTECTED] 704-721-0212 P.S. As a side note if anyone thinks this is not a proper forum for exchanging ideas about this please do tell me. It is not my goal here to disrupt anything. I am just trying to exchange some ideas with a large body of professionals in the hopes of learning something and hopefully contributing something helpful. I would also like to invite the moderators of this forum to contribute what they think of this line of discussion. If they think it is unproductive I would be more than willing to drop it and never breath another word about anything unless it falls into any guidelines they would like to set forth. Please, anyone, do feel free to respond with anything you feel would be helpful constructive or apropriate on this subject. - Original Message - From: [EMAIL PROTECTED] To: Doug [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 3:36 PM Subject: Re: namedroppers, continued I believe the answer to your first question is you would send mail using your own mail server not someone else's. Although...I do see unique issues involved in people using mail servers that are not part of their network (hotmail, yahoo...) to send email if they try to authenticate you as part of their network before allowing you to send
Re: namedroppers, continued
Hello everyone, It seems to me if the mail server administrators would make the decision to require people that send emails from their servers to log into a valid account on that server and use the same valid account on the server as a return address it would negate the ability of a large percentage of the spamers to send the spam anon. This would allow easier filtering of many of the offending messages by domain. Additionally, the sending account field and the reply to field should be equal and clients should be required to use an email address that is associated with the account used to log into the server in the first place. This will need to be implemented in the beginning by administrators who run software capable of it, and it would be implemented later as part of the email client and/or server software using new software releases, patches, and individual customizations of existing software. I know that there are many people who will scream and gnash their teeth at this suggestion as it will force them to identify themselves to anon mailing lists but I think it would be an acceptable compromise if we could eliminate a major portion of the spam clogging our inboxes. Clients need to be identified by ISP based email servers using their DNS and IP address footprints and clients attempting to send email with improper footprints should be disregarded (making it very difficult to send email from the server if you truly are not a valid subscriber to the service, much like many of the current news servers do). Then to deal with the anonymous email servers out there (hotmail, yahoo, etc...) the operators of those services should require clients logging into those accounts to send email from a valid IP address with no unsecured proxy services running on them (much like many IRC servers are doing) and transmit this IP information along with the email being sent. This would allow for pinpoint identification of the senders of spam using IP addresses MAC addresses and time stamped logs for the specific purposes of taking legal action against these network abuses. I know it will be argued that this will require cooperation between ISPs and that some systems are already implementing these measures but if all administrators as a single body insist that everyone adhere to these rules or be excluded from sending email to clients of their services and enforced this through IP block and domain blocking the stragglers would be forced to adhere to these rules. Further, if a body such as the IETF stood behind this and perhaps drafted specifications for administrators, and software developers to follow when making new clients/servers and updating existing clients/servers it would hold added weight in the market place. The extra cost associated with such actions could be offset by saved resources, and additional revenues made as a result of higher subscription rates justified by superior spam filtering techniques and a greater number of subscribers to the service due to better service quality. I would also like to suggest that the California law that requires all unsolicited emails be appended with adv: in the subject line be expanded to a federal law and additionally require emails that are solicited by signing up for a service include exact information about who the sender bought your email address from in the email. These are just some ideas I have had on eliminating spam and should in no way be considered a flame against anyone. I know there is no way that this will stop all unsolicited email from being sent or received. I just thought they might help to get some people rolling on a solution and that it would be better than complaining about it. After all doesn't a global solution make more sense than venting about what should be done to keep it out of this mailing list. Thank you for your time and attention, Douglas Huyler [EMAIL PROTECTED] 704-721-0212 P.S. I am sorry this email comes so long after the original post was made but I don't read the list very often and after reading this thread from the begining to December 6th I thought I would reply. If someone else has brought these things up after this point I am sorry, but I haven't caught up with the list yet. - Original Message - From: Fred Baker [EMAIL PROTECTED] To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 06, 2002 4:41 PM Subject: RE: namedroppers, continued At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely
Re: namedroppers, continued (flamed in less than an hour. figure s)
On Mon, 06 Jan 2003 15:46:08 +1200, Franck Martin said: Some people on the IETF as being technos lack people skills, that's why they work with computers... I usually explain it as We're talking here about a collection of people who are paid vast sums of money for their ability to carry on productive conversations with inanimate objects. It's usually easy to see the need for the cutting of slack at that point. ;) If your ego can pass that, you will be admitted to the IETF confrerie and be able to do the same to newbies... Can anybody provide the original citation for the statement (similar to): The flame you are complaining about did not cast any aspersion on your parentage or dietary preferences, and as such was mild by IETF standards? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09883/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Sun, 05 Jan 2003 19:04:41 EST, Doug said: It seems to me if the mail server administrators would make the decision to require people that send emails from their servers to log into a valid Your proposal would fix the problem, but end up tossing a large quantity of babies out with the bathwater. The problem is that for the case of a mailing list, you have *4* (at least) things to keep track of: 1) The RFC821 recipient address. For your copy of this posting, it's your email address. 2) The RFC821 sender address. It should be available in the Return-Path: header in most well-behaved mail systems as you look at your mail. 3) The RFC822 From: address. 4) The RFC822 To: address. Another problem is that I am (fortunately) still receiving more mail each day that counts as legitimate unsolicited (problem reports about our servers, people who have seen my name and are looking for technical advice, etc) than I do actual spam. It's not as easy as it looks... :) /Valdis msg09885/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
- Original Message - From: [EMAIL PROTECTED] To: Doug [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 1:23 AM Subject: Re: namedroppers, continued It seems to me if the mail server administrators would make the decision to require people that send emails from their servers to log into a valid Your proposal would fix the problem, but end up tossing a large quantity of babies out with the bathwater. The problem is that for the case of a mailing list, you have *4* (at least) things to keep track of: There are many comercial email servers that require the people sending email with their server to log into the server using a valid username and pass before doing so. I doubt they are losing any valid emails. All it does is to keep unauthorized users from using the server without a valid password. The reason to require that the sender address in the outgoing email matches the email address refrenced in the account is to keep people from sending spam from these email servers and using fraudulant return and/or sender address. I fail to see how this throws out any babies. perhaps I am missing something. 1) The RFC821 recipient address. For your copy of this posting, it's your email address. 2) The RFC821 sender address. It should be available in the Return-Path: header in most well-behaved mail systems as you look at your mail. 3) The RFC822 From: address. 4) The RFC822 To: address. I know what the recipient address, sender address, from address, and to address in headers look like. The problem is that many spammers use false information here and change it on a regular basis. This makes it impossible to block their email at the client end. My proposal is very basically to make it mandatory to put valid information in these fields in order to be able to send the email. Another problem is that I am (fortunately) still receiving more mail each day that counts as legitimate unsolicited (problem reports about our servers, people who have seen my name and are looking for technical advice, etc) than I do actual spam. I also never intended for servers to be using filters on unsolicited emails just because they are unsolicited. My intention was to suggest that people who were sending unwanted and unsolicited comercial email should be blocked. I suggested that servers that refused to cooperate with the rest of the spam hating world could be blocked just in case but, this may be a bit harsh. In addition the steps I mentioned would allow for the person receiving these emails to gather information to allow them to easily take legal action against the spammers that still managed to get through. IE if everyone is forced to use valid information in the headers to be able to send the email without using some exploit on the server then it should be easy to track them down. If of course they are forced to use exploits to send their anon spam then the admins of the system would eventually find this and take action to block them and/or prosecute them. Perhaps you could be scanning header information as well on the receiving server (not the client or the sending server) to allow you to check for nonsense return addresses like [EMAIL PROTECTED] or fraudulant source DNS and IP information. Another thing that could be checked for is wether the sending account matches the reply to address. It's not as easy as it looks... :) Oh no I never said it was easy and I also never said I knew it all. I am just making a suggestion as to a possible solution to the problem. :) Doug /Valdis P.S. I do seriously want to know how this would stop valid email users from getting/sending their email.
RE: namedroppers, continued
Dave, It's not all that unclear either. The really nasty spammers use anonymity in at least two ways: to avoid filtering and to avoid being billed for wasting our time, storage capacity, bandwidth and other resources. Taking anonymity away from these people would be the long overdue end of their free lunch on everyone else's tab. On top of that, some spammers are actually breaking the law. Gotten any South African my late died and left me ... mail lately? Those people belong in jail... Eric W. Gray Systems Architect Celox Networks, Inc. [EMAIL PROTECTED] 508 305 7214 ... The general idea behind pursuing simple authentication presumes that the really nasty spammers would not want to be identified. It's not clear how valid this presumption really would be. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise http://www.tribalwise.com t +1.408.246.8253; f +1.408.850.1850
Re: namedroppers, continued
I checked 39USC and 39CFR955 I guess the postal service maintains a list if you want to not receive mailing for sexually oriented materials, sweepstakes, and pandering solicitations. But that's about it. As far as the USPS goes. I have not yet tried filing a form 1500, but, if you believe the folks at junkbusters.com [1] [2], and page 13 of Postal Bulletin 21977 [3], it's clear that the courts have ruled that porn is in the eye of the beholder. Postmasters may not refuse to accept a Form 1500 because the advertisement in question does not appear to be sexually oriented. Only the addressee may make that determination. - Bill [1] http://www.junkbusters.com/self.html#prohibit [2] http://www.junkbusters.com/dmlaws.html [3] http://www.usps.com/cpim/ftp/bulletin/1998/pb21977.pdf
Re: namedroppers, continued
On Tue, 10 Dec 2002 08:57:59 EST, Gray, Eric said: On top of that, some spammers are actually breaking the law. Gotten any South African my late died and left me ... mail lately? Those people belong in jail... Or this: http://ars.userfriendly.org/cartoons/?id=20021209 (OK, so it's a REALLY bad pun ;) msg09754/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
For those of you who are in the Boston area, the following presentation might be of interest, given recent discussions about methods of compating SPAM. It is hosted by the MIT Laboratory for Computer Science's Applied Security Reading Group. - Ted ASRG TALK - in NE43-941 at 400 p.m. this THURS Open to the Public Date:THURSDAY, DEC 12th Time:4:00 p.m. - 5:00 p.m. Place: NE43-941, 200 Tech Square Speaker: Cynthia Dwork, Microsoft Research, Silicon Valley Campus Title: Fighting Spam May Be Easier Than You Think Abstract: In CRYPTO'92 Dwork and Naor proposed the following simple technique for combating spam: If I don't know you, and you want your e-mail to appear in my inbox, then you must attach to your message an easily verified proof of computational effort, just for me and just for this message. If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. The recent proliferation of spam has lead to a renewed interest in these ideas. This talk surveys recent work on both the choice of functions that can be used to yield easily verifiable proofs of computational effort, and architectures for implementing the proof of effort approach. Filtering and/or forcing senders to pay in other currencies, such as human attention and money, will be covered as time permits. Hosted by the Applied Security Reading Group http://pdos.lcs.mit.edu/asrg/
RE: namedroppers, continued
Every domain would have to have a public key that the public could find. Then every mailserver would have to check every message. And spammers could still send spam, because they are authorized to send email from some ISP, using that ISP's domain, and that ISP mailserver will sign their email. Spam isn't a security problem that can be solved technically. Spam is the exact same problem as when Randy Bush harrasses someone by abusing his privileges as administrator. There isn't a technical solution, other than removing the privileges. Then the new administrator could abuse the privileges, if they were so inclined. There isn't a technical way to give someone privileges that they can't abuse, if so inclined. --Dean On Fri, 6 Dec 2002, Fred Baker wrote: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to listname[EMAIL PROTECTED] and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely available to all who need to use it. The issue here is not us corporate types who have a business reason to buy the software, it is the students who often lack the funds. The big issue would be the procedures for posting one's key to the appropriate place - what is to stop a spammer from posting a key and sending the spam anyway? I'm not proposing a mechanism, but someone who is good at such things might well find it of value. It doesn't address the off topic issue. As you say, that could be left to a working group chair equiped with formal procedures developed by consensus within the work group or adopted by the working group from a more general place (ie, the IETF could suggest a procedure, and the WG could adopt it if it didn't feel another procedure would be better). I have had a private exchange, over the past few days, with someone who wished that the IETF would please document some good spam-elimination procedure, so that it could be used world-wide to completely eliminate spam. I think that boils down to provide a global PKI in this solution, and presumes that spammers are incapable of using one. That might be a great research topic. Too bad nobody has ever thought of it before; we could really use the outcome of that research. (OK, so it's a lame attempt at humor...) I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/
RE: namedroppers, continued
And how much before Randy was moderator? I'm on other large, subscriber-restricted, public lists, where this isn't a significant problem. --Dean On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote: How much spam is going to namedroppers? Well none since Randy Bush and a bunch of others turned on the moderator bit. The problem here is that having Randy Bush moderate is not a scalable solution to the problems of Spam in general. Phill
RE: namedroppers, continued
--On Friday, 06 December, 2002 16:22 -0700 Vernon Schryver [EMAIL PROTECTED] wrote: From: Marc Schneiders [EMAIL PROTECTED] ... It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start. That's another stupid crackpot spam solution that just won't go away. You cannot have abuse control built into a protocol that allows strangers to send each other mail. Any mail protocol that lets you receive mail from a stranger must also let the stranger send the same message to you and to 30,000,000 of your closest friends. On the other hand, if you want to only accept mail from people who are not strangers, you can use any of the many official and ad hoc SMTP extensions to ensure you only receive mail from them. If your computer system, mail protocol, or whatever knows that a stranger is not a spammer, then the stranger is not really a stranger. Actually, Vernon, there is a well-known, established implementation of this approach. It depends on no one being able to deliver mail to anyone else except through a network of trusted intermediaries, who are interconnected with bilateral agreements. Each of those intermediaries is essentially required to authenticate any user sending a message, which they naturally tend to do because the system strongly assumes a per-message and per-recipient charging model with settlements between the originating and receiving intermediary systems. If spammers tried to use it, they would rapidly become discouraged, first of all because the per-message charging would destroy their free to us, steal resources from others business model and second because the accounting and authentication machinery that is essential to the business models of the intermediary system vendors (let's call them ADMDs for short) would make tracking them down fairly easy. And, of course, the bilateral agreements would make it fairly easy to isolate and punish an ADMD who didn't control its spammers or pay it settlement bills. I suppose I can leave the name of this high-quality, significantly overengineered, widely-deployed system as an exercise. Been there, wasted a lot of time, energy, and resources, gave up. john
RE: namedroppers, continued
Don't discount the unexloited features already supported in the deployed base. In particular most mail servers support inline SSL connection upgrades, or can be upgraded to do so with minimal hassle. Another instance in which a self signed cert is possibly sufficient authentication - although when you consider the security you get from upgrading the connection to SSL the price of the cert is kinda de minimis but I'll play along with the rulling IETF assumption of millions for hardware, not a cent for software. Phill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 3:59 PM To: Marc Schneiders Cc: Fred Baker; Hallam-Baker, Phillip; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: namedroppers, continued I'v been saying about need for more radical change in mail protocol for years now on mailing lists. I'd rather work on smtp itself, but some people who were involved in original protocol do not want any serious changes to what they'v done, though its clear that abuse and other holes with current system is creating too many problems. In any case, by next ietf meeting in san francisco, I'll bring complete proposal for new protocol and might even try some practical tests. I do still believe that smtp can be saved, but not without more complex authentication system during delivery of email and that can't be done with current protocol design or current available extension process. Also were there any discussions or more complete discription of this algorithm for checking if host had sent an email and if so is this available on website or archive to read more about? If answer is yes, can somebody send me url or approximate date of discussions so I could lookup in archives. And am I correct here in understanding what was proposed is that smtp conversation id be such that receiving mail server could verify with sender (callback?) that it deed indeed initiate the email. If so I do not quite understand how MD5 helps there, plus I see quite a few problems with creating some special mx-like record in dns just for verification. If this is indeed what was proposed its better to go with paul vixie's proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt On Fri, 6 Dec 2002, Marc Schneiders wrote: On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote: I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. Spammers would be the first to set up your mailid host. They will have had years of experience to find holes in the system before you've convinced everyone to adopt or accept the mailid. It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start. smime.p7s Description: application/pkcs7-signature
Re: namedroppers, continued
Vernon Schryver wrote: It's been years since it was possible to be amused by the number of people who assume that spammers are more ignorant and less competent than they are, and so propose spam solutions predicated on spammers being unable to register as many names, keys, identities, or whatever as needed or as many as everybody else can. The problem I've seen repeatedly, including in an off-list discussion I'm having about this topic, is people confusing authentication with authorization. Even if you can authenticate every sender of every piece of email, that gains us virtually nothing -- not to mention it's a reasonably well-solved problem, e.g. PGP, S/MIME. As Vernon notes, spammers can create authentic credentials just as easily as anyone else. The devil is in determining what senders are authorized once we've authenticated them. My fear is the only effective solution may turn out to be closed lists with permission grants, such as the IM services introduced to keep spammers out. That will greatly reduce the utility of email. S
Re: namedroppers, continued
Paul Vixie wrote: - many ISPs won't let you forward or submit mail through someone else's SMTP server, even if you have permission to do so. so you can't forward your mail through your home ISP's mail server to allow the mail from check to work. in that case you'd be wise to not insert a MAIL-FROM MX for your domain. The vast majority of users do not have the ability to make that decision. The curious thing is that it is in an ISP's best interests _not_ to implement this draft, since doing so will likely mark nomadic users' email as suspect and potentially lose a customer. Most companies only support the public good to the extent it doesn't cost them any revenue. S
RE: namedroppers, continued
This seems clever, however, it will also take significant computational effort to verify the computational effort was actually done. Even if a class of functions are found that are easier to verify than to compute, they will no doubt still take up a significant fraction of time. Also, all outgoing messages would need this computation, since a mailserver does not know who it has sent mail to in the past, and whether they are still in receipt of the verification. So then you would only be able to send 8000 messages a day, too. Clearly, that doesn't scale very well. It seems unlikely that this would change the percentage of spam, since it would merely reduce the total amount of mail sent. I haven't observed a recent proliferation of spam, however. Spam seems to be level. --Dean On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar (UMKC-Student) wrote: this is the work all about (yesterday's seminar in a MIT group) If I don't know you, and you want your e-mail to appear in my inbox, then you must attach to your message an easily verified proof of computational effort, just for me and just for this message. If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. The recent proliferation of spam has lead to a renewed interest in these ideas. This work is about both the choice of functions that can be used to yield easily verifiable proofs of computational effort, and architectures for implementing the proof of effort approach. Filtering and/or forcing senders to pay in other currencies, such as human attention and money, will be covered as time permits for more details http://research.microsoft.com/research/sv/PennyBlack -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/
Re: namedroppers, continued
This doesn't adequately describe backup relays. If uunet is providing an alternate relay service, then all or any of uunet's relays might be providing that service. So it would have to be able to recursively look up uunets mail-from mx's, and the mail-from mx's of any subdomains listed by uunet. This process might contain loops. Additionally, the mail forwarding behavior is highly undesirable. A large mail site does not want to have to manually configure essentially the whole of the internet as possible multi-stage mail relays so that its users can forward mail from other servers to their mailbox. Indeed, even a relatively small site would not want to do that. However, even this approach won't stop spam, since a spammer will still be able to use their ISP's mailservers, with a stolen, or disposable account. There are plenty of KLEZ viruses out there, and plenty of stolen passwords. And it won't have any effect at all on spam from real commercial operators like Exactis who don't forge the from addresses. Essentially, I'm convinced after years of interaction with some radical anti-spammers that most of the non-commercial spam (and quite a lot of the forged-address spam) is sent by anti-spammers trying to essentially terrorize their way to some kind of technical solution that they think exists. However, no such solution exists. If there were such a solution, we could prevent all kinds of evils, like government corruption, embezzlement, misuse of all kinds of property. But there is no substitute for honesty and responsibility. If someone has possession of a privilege, (however that privilege was obtained--it may have been stolen), and they are so inclined to abuse that privilege, the only way to stop them is to remove the privilege. --Dean On Sat, 7 Dec 2002, Paul Vixie wrote: it's difficult to imagine a mailing list for which this thread is on-topic. I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. -- here was my attempt at this, which i didn't really know where to go next with: IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition this e-mail came from where it says it came from. 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to reject all e-mail claiming to be from HOTMAIL.COM since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server
RE: namedroppers, continued
On Fri, 6 Dec 2002, Ayyasamy, Senthilkumarwrote: If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. Wouldn't something like this cause problems for (large/free) email providers? They would probably need a lot of extra hardware to do all this computation. And until something like this is included in the standard, the receiver must accept mail from senders that don't implement this yet. I personally like the idea behind qconfirm (http://smarden.org/qconfirm/) and TMDA (http://tmda.net/). If I receive an email that I do not recognize or otherwise find to be authentic, a mail is sent back to the sender, requesting that they send a verification mail to a unique secret address. When a mail is received at this secret address, the original mail is delivered to me, and the secret address is removed. For a spammer, it is too expensive to receive and reply to all these mails. Ketil
Re: namedroppers, continued
To make them do all the work, and you do little to verify, you need a lot of things done independently, so that a random sample can be selected that is much smaller than the work they had to do. This will get bulky. The less they send, the larger the fraction of work you have to do in relation to theirs. And of course, you have to do the same amount of work on your outgoing messages as they do. The result is that it costs you much more than it costs the spammer. (since you have to do the work for both sending and receiving, and the spammer only has to do the work for sending. This would not result in a reduction of spam, as a percent of total mail. If everyone used this, it might (at best or worst) reduce the total mail sent, since the billions of legitimate messages sent each day would require significantly more work to send. Further, it would open one up to a denial of service type attack where garbage is sent, and you have to do the work to check the (invalid) signature, thereby wasting your cpu resources. Essentially, this shoots oneself in the foot. Or perhaps the CPU. --Dean On Sat, 7 Dec 2002, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Dean An derson writes: This seems clever, however, it will also take significant computational effort to verify the computational effort was actually done. Even if a class of functions are found that are easier to verify than to compute, they will no doubt still take up a significant fraction of time. In fact, that's the easy part. You could demand that the sender compute 1,000,000 HMACs of the text, the envelope, the time of day, and a counter. The verifier could check 100 randomly-chosen ones -- if any fail, there's a forgery. (Well, you probably wouldn't want those values, since 1,000,000 HMACs would be a lot of data to transmit. But you get the general idea.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book) -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/
RE: namedroppers, continued
On Sun, 8 Dec 2002, Lloyd Wood wrote: Sender pays is good. The penny black stamp effectively introduced a flat-rate tax on sending letters, rather than a variable-rate tax on receiving them, effectively turning mail into a common good available to all society. You assume this really means the spammer pays [more]. But that isn't the case. This is based on the myth that somehow the receiver pays the entire cost of a spam message. This isn't true, and never was true. The sender is already paying, whether they are spammer or mailing list operator, or regular end user. The fact is that email is so cheap that it costs almost nothing per message to send and receive. It gets cheaper every day, as disks and bandwidth get cheaper and cheaper. The receiver doesn't pay any more than the sender pays. Real commercial spam happens because the cost of sending spam is less than the cost of sending letters or postcards. If you artificially made email expensive, it would be expensive for list operators and regular people as well. You mentioned a rate of one cent per message. That would not be enough to deter spam. A rate of ten cents per message would still be cheaper than postal mail, and so spammers would still exist. Much non-commmercial spam is sent by KLEZ or Nimda viruses. This sort of abuse would not be affected whatsoever. Note that KLEZ infections are already illegal. Think how much it would cost to send out namedroppers, (and the entire bulk of IETF standards related email) if each message to each recipient cost, say $0.10. Or even one cent per message per recipient. This proposal would essentially wipe out many if not most mailing list operators, and most ISPs. I made a proposal back in 1997 that would not eliminate spam, but would keep it out of your mailbox. My proposal was rejected because radicals demanded a complete ban on spam. In 1998, there was an opportunity to get anti-spam legislation passed. Unreasonable anti-spam radicals passed up that opportunity when they insisted on unrealistic demands, and exaggerated and factually wrong assertions about the cost of spam. They assumed they could shout down any opposition, as they shouted down more reasonable proposals. They were understandably and easily crushed by the Direct Marketing Association (DMA). You can still see my proposal at http://www.av8.com/H.4581/better.html This proposal would have been difficult for the DMA to challenge since they already accept these restrictions on postal mail. You have the radical anti-spam leadership to thank for your spam, and the fact that you don't have a universal opt-out list. The anti-spam effort was for all practical purposes completely crushed when Exactis successfully sued MAPS and demonstrated that blacklists are subject to the Sherman Anti Trust Act and that blacklists weren't protected by the First Amendment. I told Vixie this would happen in 1997. He assured me that anti-spammers could win by technical means. If it wasn't clear that he was wrong in 1997, (and it seemed pretty obvious even then), it is now painfully obvious that Vixie and the rest were very wrong. It is really time for new, reasonable, anti-spam leadership, not artifical changes to the cost of email, or schemes to try to make sending mail more expensive for the senders, and certainly not gyrations in the sending of namedroppers. Thanks to the ineptitude, lack of foresight, irrationality, and general unreasonableness of the anti-spam leadership, spam is here to stay. It is just a matter of degrees of how bad it will be. I note there is some legislation before the house and senate (HR 1017) on spam control, that reportedly isn't opposed by the DMA. However, these only control fraudulent spam. HR 1017 proposes extensions of 18 USC 1030, which makes it a fraudulent spam a crime, but the FBI probably won't bring charges for small violations. There is no provision for a civil action. Another bill (S.630) would require each spammer to maintain an opt-out list. You would have to contact each spammer, and have your email address added to their list, one by one. There would be thousands of spammers to contact. Note that my proposal would had a single opt-out list (the Post Office already maintains such a list for postal junk mail), and my proposal probably could have been passed into law in 1998. --Dean
Re: namedroppers, continued
From: Stephen Sprunk [EMAIL PROTECTED] ... The problem I've seen repeatedly, including in an off-list discussion I'm having about this topic, is people confusing authentication with authorization. ... Yes, that's a good way of putting the problem, but only for those able and willing to see the differences among authorization, authentication, confidentiality, non-repudiation, and so forth. It's sad that weak as dishwater authentication as authorization (and everything else) snake oil sells so well, as witnessed by Verisign's PKI and Microsoft's ActiveX. ...My fear is the only effective solution may turn out to be closed lists with permission grants, such as the IM services introduced to keep spammers out. That will greatly reduce the utility of email. That has already happened about as much as it is going to happen or could happen, as witnessed by the IETF lists. The variations in effectiveness and mechanisms among the IETF lists are minor details. The notion of limiting submissions to known authors was once very controversial here, but it's now accepted as necessary and desirable. I don't see any reduction in utility as a result. Individual mailboxes differ. Because people value its utility, personal addresses will continue to accept mail from strangers who might be sending the same message to 100,000 others. Various technical and administrative defenses will limit spam. Except for those few of us who are obsessed with spam, filters that are sufficent and require little effort will be used. Popular choices will be what people can do for themselves such as private and DNS white- and blacklists, SpamAssassin, Brightmail, Postinni, Cloudmark/Razor, and the DCC. (Do for themselves includes hiring a competent ISP.) Filters that require joint actions by the sender and receiver, including the computing-cost and authenticating DNS RR proposals, will never be popular. Because they won't be popular, installations that start to use them will switch to sufficient equivalents such as simple white-listing. Sufficient existing protocols are never vulnerable to slightly better replacements. Joint action is an enormous barrier. It is a cost that is justified only in special cases. That is why we are not routinely using PGP or S-MIME for our private mail. That's also why I see many more SMTP-TLS connections to my SMTP server than I expected (many including from spammers), and why almost none of them are authenticated. To use SMTP-TLS you need only install and configure a current SMTP server. To use authenticated SMTP-TLS, you must use PKI or exchange keys. Vernon Schryver[EMAIL PROTECTED]
Re: namedroppers, continued
On Mon, 09 Dec 2002 11:52:26 CST, Stephen Sprunk [EMAIL PROTECTED] said: The problem I've seen repeatedly, including in an off-list discussion I'm having about this topic, is people confusing authentication with authorization. Authentication: Yes, you seem to be Jeffrey Dahlmer. Authorization: You say you'd like to borrow a steak knife? Usually clears up the confusion in all but the most sluggish mind.. ;) However, authorization usually implies authentication beforehand. Does anybody have a reference on an authorization scheme that doesn't imply any authentication? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09712/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
Thus spake [EMAIL PROTECTED] Authentication: Yes, you seem to be Jeffrey Dahlmer. Authorization: You say you'd like to borrow a steak knife? Usually clears up the confusion in all but the most sluggish mind.. ;) That's a very clear example, thanks. However, authorization usually implies authentication beforehand. Does anybody have a reference on an authorization scheme that doesn't imply any authentication? In a sense: the IETF lists (and most others) use a null authentication method, i.e. you trust whatever is in the message. After that (null) step, we apply weak authorization, i.e. whether the sender is on the approved list. I've seen lots of proposals to improve the former-- hardly difficult -- but none for the latter. Perhaps using precise terminology will help focus efforts in the right area. S
Re: namedroppers, continued
At 16:53 -0500 12/9/02, [EMAIL PROTECTED] wrote: However, authorization usually implies authentication beforehand. Does anybody have a reference on an authorization scheme that doesn't imply any authentication? World readable files. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: namedroppers, continued
I haven't personally tried myself to opt out. But I've read they have the form. If they told you they don't have a form to sort out junk mail for you I'd say they were full out it. I'd call the Postmaster General's office. - Original Message - From: Stephen Sprunk [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Sent: Monday, December 09, 2002 12:56 PM Subject: Re: namedroppers, continued Can you tell me where to get this form? When I spoke to the USPS, they said they're legally obligated to deliver all junk mail addressed to me, regardless of whether I want it. Now, the DMA (not the USPS) does have an opt-out list you can join, but unfortunately that only drops about half the junk mail I get -- many local mailers don't join the DMA because of cost. S Bill Cunningham wrote: How about passing a law that makes eveyone install a BIOS patch to block out spam. ;-) On the serious side Vernon has a point. Even with snail mail you can go to the post office and the USPS will provide you with a form to fill out and they will not put advertisements into your mail. If ISPs would only do the same. As of yet, if all else fails, deleting a email box is easier and more effective than taking a ballbat to a snail mail box. --Bill - Original Message - From: Vernon Schryver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 09, 2002 12:09 AM Subject: Re: namedroppers, continued From: [EMAIL PROTECTED] ... The bootstrap problem will exist no matter what scheme we decide on. There are many spam solutions that do not have the bootstrapping problem. Examples include effective laws and honest intent and action by ISPs. Before saying those are hopeless, please note that the many bootstrap-limited proposals don't have proven prospects. The point I was addressing was that there's been two major classes of scheme proposed ... However, the partitions created by each scheme are quite complementary, ... Your observation of how those two solutions fit together is interesting...or would be if they did not suffer from other problems. ... Moore's law causes a bunch of problems for the computing idea. ... It may not be as big of a problem as we think. Rough back-of-envelope calculations now: Let's say we assume a function X designed to take 10 seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to 8K messages/day. http://www.intel.com/home/desktop/pentium4/ suggests state of the commodity art is about twice that, which lets a spammer send 16K msgs/day. Moore's law is still a treadmill that you don't want to fight. Now, this same function will take around 2 minutes on a 133mz processor and be restricted to 800 mails/day. ... I would put the lower limit at around 48 MHz on 80486s, or ~8 times slower than a 133 MHz Pentium. Such machines go back less than 10 years. Would you expect your conservative correspondents to spend 15 minutes to send you a message, or would you just white-list them? Once you start white-listing, it's hard to have much enthusiasm for more fancier solutions. Now how many people are still using a 133 system to do that much outbound mail themselves (and *NOT* just relaying all outbound mail to a smarthost)? I think recent FreeBSD and sendmail would still work fine at 48 MHz, although you probably want to stuff the thing to the gills with 64 MByte of RAM, or more if it can take it. There are many computing tasks that don't need 3 GHZ and 3 GByte. Aren't busy smarthosts significantly busier than 80K msgs/day? From my old experience, that was true even when they were running at less than 50 MHz and with perhaps 100 MByte. Besides, no matter what inmates of glass houses and big ISPs would have you think, SMTP is a peer-to-peer protocol. A major damage spam is doing is helping government commissars and ISP salescritters convince people that the ancient Compuserve/AOL/Prodigy/whatever dumb-terminal- connected-to-central-servers is the only way to do public networking and computing. And even *MORE* to the point, what are the chances that a system that old will be upgraded software-wise to support a scheme, even if it takes zero additional CPU? ... Would you whitelist it for the next 10 years? If there are very few, white-listing works. If not, you've got that bootstrapping problem, and you've invited the white-listing camel into your tent. Vernon Schryver[EMAIL PROTECTED] | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Design Consultant :|||: :|||: Cisco Advanced Services .:|||:..:|||:.Richardson, Texas, USA
Re: namedroppers, continued
Does anybody have a reference on an authorization scheme that doesn't imply any authentication? You will deliver the satchel to the one who presents the matching half of this hundred-euro note.
Re: namedroppers, continued
On Mon, 09 Dec 2002 17:47:58 EST, Edward Lewis said: Does anybody have a reference on an authorization scheme that doesn't imply any authentication? World readable files. We know how to do that already ;) I was thinking more along the lines of a zero-knowledge proof or something like that - a scheme where you can prove you're authorized to do something(*) without having to prove who you are first. (*) and explicitly ruling out the 'null check, everybody is allowed' case ;) /Valdis msg09723/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
--On Monday, 09 December, 2002 16:17 -0600 Stephen Sprunk [EMAIL PROTECTED] wrote: Thus spake [EMAIL PROTECTED] Authentication: Yes, you seem to be Jeffrey Dahlmer. Authorization: You say you'd like to borrow a steak knife? Usually clears up the confusion in all but the most sluggish mind.. ;) That's a very clear example, thanks. However, authorization usually implies authentication beforehand. Does anybody have a reference on an authorization scheme that doesn't imply any authentication? In a sense: the IETF lists (and most others) use a null authentication method, i.e. you trust whatever is in the message. After that (null) step, we apply weak authorization, i.e. whether the sender is on the approved list. Actually, it is a very common situation: Think about almost any case in which possession of a token authorizes one to do something, but no identification/ authentication is implied. For what is perhaps one of the older examples, can you go to a store where you are not known, in some part of your country where you are not frequently present, and buy something. Of course you can: you pass an authorization token, typically called cash across the counter and get some merchandise in return. The quantity of tokens you possess and their value even determines the extent of your authorization. Credit card companies often draw an analogy to that situation, which is one of the reasons they have stayed far out of the _public_ part of the PKI business: they don't really care who you are, or who uses the credit card, as long as the bill gets paid. Anything they do or require that involves authentication has to do with the the bill will get paid without protest property, not your identity. john
Re: namedroppers, continued
[EMAIL PROTECTED] wrote: Does anybody have a reference on an authorization scheme that doesn't imply any authentication? From:-line based email filters. -- Cos (Ofer Inbar) -- [EMAIL PROTECTED] http://cos.polyamory.org/ -- WBRS (100.1 FM) -- [EMAIL PROTECTED] http://www.wbrs.org/ OSI is a beautiful dream, and TCP/IP is living it! -- Einar Stefferud [EMAIL PROTECTED], IETF mailing list, 12 May 1992
Re: namedroppers, continued
Stephen, Monday, December 9, 2002, 9:52:26 AM, you wrote: Stephen The devil is in determining what senders are authorized once we've Stephen authenticated them. The concept of being authorized to send someone mail has good logic, but goes against established human communication practises for mail and telephone. (Filtering is common to both, but is different from authorization.) Some time ago, Mike O'Dell put forward the idea of accountable, in the sense of being able to reach back to the sender, to hold them accountable for their actions. The general idea behind pursuing simple authentication presumes that the really nasty spammers would not want to be identified. It's not clear how valid this presumption really would be. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise http://www.tribalwise.com t +1.408.246.8253; f +1.408.850.1850
Re: namedroppers, continued
Blinded coins a la digicash http://www.law.miami.edu/~froomkin/articles/oceanno.htm#xtocid583124 On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: On Mon, 09 Dec 2002 17:47:58 EST, Edward Lewis said: Does anybody have a reference on an authorization scheme that doesn't imply any authentication? World readable files. We know how to do that already ;) I was thinking more along the lines of a zero-knowledge proof or something like that - a scheme where you can prove you're authorized to do something(*) without having to prove who you are first. (*) and explicitly ruling out the 'null check, everybody is allowed' case ;) /Valdis -- Please visit http://www.icannwatch.org A. Michael Froomkin |Professor of Law| [EMAIL PROTECTED] U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm --It's warm here.--
Re: namedroppers, continued
--On Monday, 09 December, 2002 17:49 -0500 Bill Cunningham [EMAIL PROTECTED] wrote: I haven't personally tried myself to opt out. But I've read they have the form. If they told you they don't have a form to sort out junk mail for you I'd say they were full out it. I'd call the Postmaster General's office. Bill, For the US Post Office, they don't have the form. In another context, I've been over this with the Postal Inspection Service. They have two other forms and models, one of which is probably getting confused with this. (1) You can decline to receive the particular form of junk mail that is addressed to occupant, boxholder, or similar generic terms. For that, there is a form. (2) You can also decide that particular types of materials, identifed by specific description (nearly impossible in most cases) or source is obscene. Once you do that, and perform the relevant rituals, it becomes illegal for identified sources to send the stuff to you. In general, you can't get the post office to open all of your mail and do content filtering to be sure it doesn't meet your criteria for obscenity. And you probably wouldn't want to, since that would require authorizing them to open and read all of your mail. But it can be an effective way to prevent a particular sender for sending you specific kinds of materials, since the penalties for sending obscene materials through the mails are quite severe. If it is addressed to you, by name and matching address, they are, as Stephen indicated, legally required to deliver it (unless it falls under the prohibitions of (2) above). So, oddly, you can opt out of untargeted mailings, but not out of targeted ones. john
Re: namedroppers, continued
- Original Message - From: John C Klensin [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: Stephen Sprunk [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, December 09, 2002 9:16 PM Subject: Re: namedroppers, continued --On Monday, 09 December, 2002 17:49 -0500 Bill Cunningham [EMAIL PROTECTED] wrote: I haven't personally tried myself to opt out. But I've read they have the form. If they told you they don't have a form to sort out junk mail for you I'd say they were full out it. I'd call the Postmaster General's office. Bill, For the US Post Office, they don't have the form. In another context, I've been over this with the Postal Inspection Service. They have two other forms and models, one of which is probably getting confused with this. (1) You can decline to receive the particular form of junk mail that is addressed to occupant, boxholder, or similar generic terms. For that, there is a form. (2) You can also decide that particular types of materials, identifed by specific description (nearly impossible in most cases) or source is obscene. Once you do that, and perform the relevant rituals, it becomes illegal for identified sources to send the stuff to you. In general, you can't get the post office to open all of your mail and do content filtering to be sure it doesn't meet your criteria for obscenity. And you probably wouldn't want to, since that would require authorizing them to open and read all of your mail. But it can be an effective way to prevent a particular sender for sending you specific kinds of materials, since the penalties for sending obscene materials through the mails are quite severe. If it is addressed to you, by name and matching address, they are, as Stephen indicated, legally required to deliver it (unless it falls under the prohibitions of (2) above). So, oddly, you can opt out of untargeted mailings, but not out of targeted ones. john I checked 39USC and 39CFR955 I guess the postal service maintains a list if you want to not receive mailing for sexually oriented materials, sweepstakes, and pandering solicitations. But that's about it. As far as the USPS goes.
Re: namedroppers, continued
On Fri, 06 Dec 2002 16:48:46 CST, Ayyasamy, Senthilkumar (UMKC-Student) said: If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. Those of us who run mail servers that are currently resource-constrained while doing 8K msgs/hour worry anytime we hear that sort of idea. On the other hand, I wouldn't mind taking a 10-second hit every time *I* send a message. Possibly what is needed is a hybrid approach: 1) If you're a big mail server, you can probably prevail on your DNS admins to list you in whatever DNS-based verification system (in our entire 2 /16s of address space, there are less than 10 boxes that would have a major resource issue, but would benefit froma DNS-based solution. 2) If you're not listed in the DNS, you have to do a compute-intensive proof. What would people think of that idea? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09679/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
From: [EMAIL PROTECTED] ... Possibly what is needed is a hybrid approach: 1) If you're a big mail server, you can probably prevail on your DNS admins to list you in whatever DNS-based verification system (in our entire 2 /16s of address space, there are less than 10 boxes that would have a major resource issue, but would benefit froma DNS-based solution. 2) If you're not listed in the DNS, you have to do a compute-intensive proof. What would people think of that idea? Is the goal to block spam? If so, what do you do about third case of senders that don't participate with either #1 or #2? For the first years, most of the 10,000,000s of legitimate SMTP clients (sending mail servers) will do neither #1 or #2, because their operators will not have heard about it. You will have to configure your receiving mail servers to require #1 or #2 only in exceptional cases. When the operators of the other 10,000,000s of servers finally hear about the new regime, they'll generally to not get around to installing either sort of proof of virtue, because their mail is working without it and they have real problems to worry about, from installing the latest security patches to thinking about considering IPv6. Even people who turn on requirements for #1 or #2 for incoming mail to reduce spam will often delay supporting it on outgoing mail, because no one competent likes to break things that are working. In other words, such tactics might work for the exceptional cases of biggest, otherwise hopeless sources of (not really) forged spam such as Hotmail as a sort of half-blacklisting, but I can't see it working in general. Moore's law causes a bunch of problems for the computing idea. There is at at least a factor of 100 in CPU speeds of current hosts. How do you ensure that the fastest commodity CPU that a spammer might use is forced to slow down more than the limit already imposed by network bottlenecks without making old systems useless? Vernon Schryver[EMAIL PROTECTED]
Re: namedroppers, continued
- Original Message - From: Lloyd Wood [EMAIL PROTECTED] To: Ayyasamy, Senthilkumar (UMKC-Student) [EMAIL PROTECTED] Cc: Fred Baker [EMAIL PROTECTED]; Hallam-Baker, Phillip [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 5:29 PM Subject: RE: namedroppers, continued On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar (UMKC-Student) wrote: If I don't know you, and you want your e-mail to appear in my inbox, then you must attach to your message an easily verified proof of computational effort, just for me and just for this message. If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. tracking moore's law could be a problem. The recent proliferation of spam has lead to a renewed interest in these ideas. This work is about both the choice of functions that can be used to yield easily verifiable proofs of computational effort, and architectures for implementing the proof of effort approach. Filtering and/or forcing senders to pay in other currencies, such as human attention and money, will be covered as time permits Sender pays is good. The penny black stamp effectively introduced a flat-rate tax on sending letters, rather than a variable-rate tax on receiving them, effectively turning mail into a common good available to all society. Lloyd, in the US we pay .37 to mail a first-class letter. I don't know how many pence you pay in the UK but we still have spam bulk rate unwanted solicitations. Forcing the sender to pay doesn't solve a spam problem. I don't see how in could. It would force everyone to have to pay a price. The government also undercut private messaging operators and effectively put them out of business, but could use money earned towards other services for society (having simplified and saved on its operational costs along the way). So, computing as a social good - you want to send an email to someone you're unknown to, you've got to provide proof that you're participating in SETI@home, searching for big primes, in a distributed crypto challenge, working on processing public GIS information, autocomparing versions of typed ascii out-of-copyright texts (or raw CD rips?) for accuracy, processing gene data or archived NASA tapes or otherwise doing good things -- guess this would make each computing charity (give us your spare cycles) the ticket server or PKI manager, although you might want to try distributing that too. for more details http://research.microsoft.com/research/sv/PennyBlack I don't see any discussion there of the computation as a social good, or computational functions as utility functions. Microsoft, eh? http://www.glassinesurfer.com/f/gsrowlandhill.shtml -- and here's the obligatory mention of Jeremy Bentham. L. http://www.ee.surrey.ac.uk/Personal/L.Wood/[EMAIL PROTECTED]
Re: namedroppers, continued
From: [EMAIL PROTECTED] ... The bootstrap problem will exist no matter what scheme we decide on. There are many spam solutions that do not have the bootstrapping problem. Examples include effective laws and honest intent and action by ISPs. Before saying those are hopeless, please note that the many bootstrap-limited proposals don't have proven prospects. The point I was addressing was that there's been two major classes of scheme proposed ... However, the partitions created by each scheme are quite complementary, ... Your observation of how those two solutions fit together is interesting...or would be if they did not suffer from other problems. ... Moore's law causes a bunch of problems for the computing idea. ... It may not be as big of a problem as we think. Rough back-of-envelope calculations now: Let's say we assume a function X designed to take 10 seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to 8K messages/day. http://www.intel.com/home/desktop/pentium4/ suggests state of the commodity art is about twice that, which lets a spammer send 16K msgs/day. Moore's law is still a treadmill that you don't want to fight. Now, this same function will take around 2 minutes on a 133mz processor and be restricted to 800 mails/day. ... I would put the lower limit at around 48 MHz on 80486s, or ~8 times slower than a 133 MHz Pentium. Such machines go back less than 10 years. Would you expect your conservative correspondents to spend 15 minutes to send you a message, or would you just white-list them? Once you start white-listing, it's hard to have much enthusiasm for more fancier solutions. Now how many people are still using a 133 system to do that much outbound mail themselves (and *NOT* just relaying all outbound mail to a smarthost)? I think recent FreeBSD and sendmail would still work fine at 48 MHz, although you probably want to stuff the thing to the gills with 64 MByte of RAM, or more if it can take it. There are many computing tasks that don't need 3 GHZ and 3 GByte. Aren't busy smarthosts significantly busier than 80K msgs/day? From my old experience, that was true even when they were running at less than 50 MHz and with perhaps 100 MByte. Besides, no matter what inmates of glass houses and big ISPs would have you think, SMTP is a peer-to-peer protocol. A major damage spam is doing is helping government commissars and ISP salescritters convince people that the ancient Compuserve/AOL/Prodigy/whatever dumb-terminal- connected-to-central-servers is the only way to do public networking and computing. And even *MORE* to the point, what are the chances that a system that old will be upgraded software-wise to support a scheme, even if it takes zero additional CPU? ... Would you whitelist it for the next 10 years? If there are very few, white-listing works. If not, you've got that bootstrapping problem, and you've invited the white-listing camel into your tent. Vernon Schryver[EMAIL PROTECTED]
Re: namedroppers, continued
How about passing a law that makes eveyone install a BIOS patch to block out spam. ;-) On the serious side Vernon has a point. Even with snail mail you can go to the post office and the USPS will provide you with a form to fill out and they will not put advertisements into your mail. If ISPs would only do the same. As of yet, if all else fails, deleting a email box is easier and more effective than taking a ballbat to a snail mail box. --Bill - Original Message - From: Vernon Schryver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 09, 2002 12:09 AM Subject: Re: namedroppers, continued From: [EMAIL PROTECTED] ... The bootstrap problem will exist no matter what scheme we decide on. There are many spam solutions that do not have the bootstrapping problem. Examples include effective laws and honest intent and action by ISPs. Before saying those are hopeless, please note that the many bootstrap-limited proposals don't have proven prospects. The point I was addressing was that there's been two major classes of scheme proposed ... However, the partitions created by each scheme are quite complementary, ... Your observation of how those two solutions fit together is interesting...or would be if they did not suffer from other problems. ... Moore's law causes a bunch of problems for the computing idea. ... It may not be as big of a problem as we think. Rough back-of-envelope calculations now: Let's say we assume a function X designed to take 10 seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to 8K messages/day. http://www.intel.com/home/desktop/pentium4/ suggests state of the commodity art is about twice that, which lets a spammer send 16K msgs/day. Moore's law is still a treadmill that you don't want to fight. Now, this same function will take around 2 minutes on a 133mz processor and be restricted to 800 mails/day. ... I would put the lower limit at around 48 MHz on 80486s, or ~8 times slower than a 133 MHz Pentium. Such machines go back less than 10 years. Would you expect your conservative correspondents to spend 15 minutes to send you a message, or would you just white-list them? Once you start white-listing, it's hard to have much enthusiasm for more fancier solutions. Now how many people are still using a 133 system to do that much outbound mail themselves (and *NOT* just relaying all outbound mail to a smarthost)? I think recent FreeBSD and sendmail would still work fine at 48 MHz, although you probably want to stuff the thing to the gills with 64 MByte of RAM, or more if it can take it. There are many computing tasks that don't need 3 GHZ and 3 GByte. Aren't busy smarthosts significantly busier than 80K msgs/day? From my old experience, that was true even when they were running at less than 50 MHz and with perhaps 100 MByte. Besides, no matter what inmates of glass houses and big ISPs would have you think, SMTP is a peer-to-peer protocol. A major damage spam is doing is helping government commissars and ISP salescritters convince people that the ancient Compuserve/AOL/Prodigy/whatever dumb-terminal- connected-to-central-servers is the only way to do public networking and computing. And even *MORE* to the point, what are the chances that a system that old will be upgraded software-wise to support a scheme, even if it takes zero additional CPU? ... Would you whitelist it for the next 10 years? If there are very few, white-listing works. If not, you've got that bootstrapping problem, and you've invited the white-listing camel into your tent. Vernon Schryver[EMAIL PROTECTED]
Re: namedroppers, continued
On Mon, 09 Dec 2002 03:14:43 GMT, Lloyd Wood said: The act of subscribing to a list indicates that you know the list, and you're less likely to reject mail from people you don't know that comes or also comes via the list, since you're interested in reading that list -- unless the list is a simple exploder with no filtering mechanisms itself, in which case, subscribers pester each other (rather than the list) for computational proofs until the list implements spam filtering. Let's look at some of the headers of the message I'm replying to: Received: from fan.cc.vt.edu [198.82.161.8] by localhost with POP3 (fetchmail-5.9.0)for valdis@localhost (single-drop); Sun, 08 Dec 2002 22:41:03 -0500 (EST) This is where my laptop picked up my mail via POP3. My laptop can be aware of the fact that I'm subscribed to IETF. However, this is too late to make the check effectively - it's already hit our central mail server. Received: from steiner.cc.vt.edu ([10.1.1.14]) by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2001.05.04.11.50.p10) with ESMTP id [EMAIL PROTECTED]; Sun, 8 Dec 2002 22:43:06 -0500 (EST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by steiner.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ATX04442; Sun, 08 Dec 2002 22:42:56 -0500 (EST) Unfortunately, steiner is the machine which *should* be doing the filtering (in fact, it's one of our front-end virus scanners). But there's no good way for it to know what I'm subscribed to - and a good case can be made that often the mail server should *not* know what I'm subscribed to (for privacy reasons). You *could* sell me on a concept where I tell the mail server accept any mail that presents a token that hashes to this, where I provide a test that doesn't provide any information regarding the sender. Why? Because I don't trust my government to resist the temptation. (Nor do I trust any OTHER national goverment, for that matter). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09687/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Mon, 09 Dec 2002 00:47:45 EST, Bill Cunningham [EMAIL PROTECTED] said: How about passing a law that makes eveyone install a BIOS patch to block out spam. ;-) There exist systems that don't have a BIOS. ;) (Making this reply mostly because there's been serious DRM proposals that have this same exact problem). msg09688/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
[EMAIL PROTECTED] (Keith Moore) writes: I've had a look at vixies proposal and it's a good one. I certainly would welcome something like the mailfrom dns record. actually I'd call it a nonstarter in its current form. given that - mail from is used for nondelivery reports and other notifications; users need to make sure it gets set to an address that they'll read that problem doesn't change. all the mailfrom draft says is that you need to be coming from a designated server to be able to set MAIL FROM. - nomadic users have valid reasons to post from random places on the net (including multiple ISPs) and keep the same mail from address. then, i'm sorry that i'm such a poor writer. i tried to cover this case: 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back home may become a necessary first hop for mobile e-mail. - many ISPs won't let you forward or submit mail through someone else's SMTP server, even if you have permission to do so. so you can't forward your mail through your home ISP's mail server to allow the mail from check to work. in that case you'd be wise to not insert a MAIL-FROM MX for your domain. -- Paul Vixie
Re: namedroppers, continued
[EMAIL PROTECTED] writes: actually I'd call it a nonstarter in its current form. I would have to agree. ... In addition to these valid concerns I'd add that various sorts of autoforwarding exist that don't change the MAIL FROM. These would also tend to break if such a scheme were implemented. i apologize for being such a poor writer. what the draft actually says is: 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if [EMAIL PROTECTED]'s account has a .forward file pointing at [EMAIL PROTECTED], then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as multistage inbound relays. This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) I'm also concerned about the management aspects of having lists of authorized multistage relays and all that implies. then you probably would not want to insert a MAIL-FROM MX in your domain. Perhaps the real problem here isn't the use of MAIL FROM but rather the assumption that binding ipsource to the MAIL FROM domain is a useful validation check. A specific ipsource is just not a property a legitimate user of a given domain can be expected to have. Although I am reluctant to suggest anything involving public key crypto, another approach would be to put a public key in the MAIL-FROM DNS record and add a new header field containing a signature covering the message's MAIL FROM and the current date. i love that plan. we all know that ip source addresses make poor passwords. however, it has to be an envelope thing, not a header thing, since it's hop by hop. perhaps MAIL FROM:$address $sig as an ESMTP thing? -- Paul Vixie
Re: namedroppers, continued
- nomadic users have valid reasons to post from random places on the net (including multiple ISPs) and keep the same mail from address. then, i'm sorry that i'm such a poor writer. i tried to cover this case: 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back home may become a necessary first hop for mobile e-mail. - many ISPs won't let you forward or submit mail through someone else's SMTP server, even if you have permission to do so. so you can't forward your mail through your home ISP's mail server to allow the mail from check to work. in that case you'd be wise to not insert a MAIL-FROM MX for your domain. what this seems to require is to have different sets of domains for use in MAIL FROM addresses - those for which source verification can be expected and those for which it cannot. there are some current domains which are naturally and exclusively in the former category - say hotmail.com; but most domains are probably not exclusively in either category. so it would require establishment of new domains and reconfiguration of systems to use those domains to be effective - along with the educational effort that this entails. and it would still leave a significant portion of mail without a way to identify its source. Keith
Re: namedroppers, continued
- many ISPs won't let you forward or submit mail through someone else's SMTP server, even if you have permission to do so. so you can't forward your mail through your home ISP's mail server to allow the mail from check to work. in that case you'd be wise to not insert a MAIL-FROM MX for your domain. what this seems to require is to have different sets of domains for use in MAIL FROM addresses - those for which source verification can be expected and those for which it cannot. yes. there are some current domains which are naturally and exclusively in the former category - say hotmail.com; but most domains are probably not exclusively in either category. yes. so it would require establishment of new domains and reconfiguration of systems to use those domains to be effective - along with the educational effort that this entails. i think most of the reconfiguration effort would be around existing domains. and it would still leave a significant portion of mail without a way to identify its source. so far, working toward a single solution that covers all cases and is easy (low cost) for spam victims and infrastructure owners to take part in, has not worked. what you see in the mailfrom draft is just a point solution. i am reminded by this thread that the most powerful force on the internet continues to be a single voice saying that something cannot be done.
Re: namedroppers, continued
In message [EMAIL PROTECTED], Dean An derson writes: This seems clever, however, it will also take significant computational effort to verify the computational effort was actually done. Even if a class of functions are found that are easier to verify than to compute, they will no doubt still take up a significant fraction of time. In fact, that's the easy part. You could demand that the sender compute 1,000,000 HMACs of the text, the envelope, the time of day, and a counter. The verifier could check 100 randomly-chosen ones -- if any fail, there's a forgery. (Well, you probably wouldn't want those values, since 1,000,000 HMACs would be a lot of data to transmit. But you get the general idea.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book)
Re: namedroppers, continued
i am reminded by this thread that the most powerful force on the internet continues to be a single voice saying that something cannot be done. well, I've certainly seen it happen. (though I think the most powerful force on the internet is large numbers of voices insisting that something be done whether or not it makes sense - not that this is what is happening here.) I don't want to discourage you from developing the mail from dns idea further, but neither do I think it will help the spam problem much. my biggest concern is that it will be used as an excuse to constrain where people can send mail from, and at a time when ill-conceived spam countermeasures are already a serious operational problem and probably the most significant cause of failure to deliver legitimate mail. Keith
RE: namedroppers, continued
One of the main reasons why anti-spam measures are failing is that the spam-artists are fraudulently hijacking people's email addresses so as to bypass anti-spam filters. My reading of the open enrollement policy is that anyone can contribute. I don't think that a secondary manual filter by which the first post to the list by an individual was only forwarded after moderation would breach that principle - but it would be one heck of a lot less work for the chairs than having to moderate every message. I certainly do not consider it an imposition on those who want to pontificate on Internet protocols to require them to actualy eat the company dog food and sign their messages with either PGP or S/MIME. I am not pushing a corporate interest here, a self signed certificate would be fine. I think that one of the problems for the PKI world is that the perfect has been the enemy of the good. OK you can argue that it would not exactly hurt VRSN if more people started to use security routinely, I don't think that would hurt the IETF either. Phill -Original Message- From: Aaron Swartz [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 10:43 AM To: Hallam-Baker, Phillip Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: namedroppers, continued Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed [and] to require the subscribers to register their signing key And how do we prevent spammers from registering their signing key? Are you suggesting that we change the IETF's open enrollment policy? -- Aaron Swartz [http://www.aaronsw.com] smime.p7s Description: application/pkcs7-signature
Re: namedroppers, continued
From: D. J. Bernstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: namedroppers, continued ... Okay, Bush: Put [EMAIL PROTECTED] on the list of addresses from which submissions are automatically accepted. sorry bernstein. as your message also was addressed to lists to which i subscribe, the copy to namedroppers-owner was deleted locally due to dupe message-id: detection. erik and harald pointed it out, and rob just forwarded a copy to me. so i have done the addition. thanks, as approving all your postings was becoming a pain in the butt. randy
RE: namedroppers, continued
How much spam is going to namedroppers? I haven't seen any. So, don't you think this has gone a little of the deep end? --Dean On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote: One of the main reasons why anti-spam measures are failing is that the spam-artists are fraudulently hijacking people's email addresses so as to bypass anti-spam filters.
RE: namedroppers, continued
Hi - Message-Id: [EMAIL PROTECTED] Date: Fri, 06 Dec 2002 13:41:52 -0800 To: Hallam-Baker, Phillip [EMAIL PROTECTED] From: Fred Baker [EMAIL PROTECTED] Subject: RE: namedroppers, continued Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] .com ... I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely available to all who need to use it. The issue here is not us corporate types who have a business reason to buy the software, it is the students who often lack the funds. The big issue would be the procedures for posting one's key to the appropriate place - what is to stop a spammer from posting a key and sending the spam anyway? I'm not proposing a mechanism, but someone who is good at such things might well find it of value. ... At least for now, the stuff with forged addresses aimed at the IETF lists I handle can be stopped simply by blocking multipart/alternative, multipart/mixed, and text/html. Is this generally true, or am I working with a particularly old-fashioned subscriber base? On non-IETF lists I manage, I've had to permit these types, and resort to finer-grained (read costlier) spam-blocking measures. -- Randy Presuhn BMC Software, Inc. SJC-1.3141 -- My opinions and BMC's are independent variables. --
RE: namedroppers, continued
At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely available to all who need to use it. The issue here is not us corporate types who have a business reason to buy the software, it is the students who often lack the funds. The big issue would be the procedures for posting one's key to the appropriate place - what is to stop a spammer from posting a key and sending the spam anyway? I'm not proposing a mechanism, but someone who is good at such things might well find it of value. It doesn't address the off topic issue. As you say, that could be left to a working group chair equiped with formal procedures developed by consensus within the work group or adopted by the working group from a more general place (ie, the IETF could suggest a procedure, and the WG could adopt it if it didn't feel another procedure would be better). I have had a private exchange, over the past few days, with someone who wished that the IETF would please document some good spam-elimination procedure, so that it could be used world-wide to completely eliminate spam. I think that boils down to provide a global PKI in this solution, and presumes that spammers are incapable of using one. That might be a great research topic. Too bad nobody has ever thought of it before; we could really use the outcome of that research. (OK, so it's a lame attempt at humor...) I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses.
Re: namedroppers, continued
In message [EMAIL PROTECTED], Fred Bake r writes: At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely available to all who need to use it. The issue here is not us corporate types who have a business reason to buy the software, it is the students who often lack the funds. The big issue would be the procedures for posting one's key to the appropriate place - what is to stop a spammer from posting a key and sending the spam anyway? I'm not proposing a mechanism, but someone who is good at such things might well find it of value. Well, it's also the availability of the right signature facility in the myriad email clients people use. I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. Wasn't me... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book)
RE: namedroppers, continued
On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote: I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. Spammers would be the first to set up your mailid host. They will have had years of experience to find holes in the system before you've convinced everyone to adopt or accept the mailid. It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start.
RE: namedroppers, continued
Too bad nobody has ever thought of it before; we could really use the outcome of that research while researchers has not thought about global PKI, their are research which focus on spam elimination. this is the work all about (yesterday's seminar in a MIT group) If I don't know you, and you want your e-mail to appear in my inbox, then you must attach to your message an easily verified proof of computational effort, just for me and just for this message. If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. The recent proliferation of spam has lead to a renewed interest in these ideas. This work is about both the choice of functions that can be used to yield easily verifiable proofs of computational effort, and architectures for implementing the proof of effort approach. Filtering and/or forcing senders to pay in other currencies, such as human attention and money, will be covered as time permits for more details http://research.microsoft.com/research/sv/PennyBlack
RE: namedroppers, continued
From: Fred Baker [EMAIL PROTECTED] ... I think that boils down to provide a global PKI in this solution, and presumes that spammers are incapable of using one. That might be a great research topic. Too bad nobody has ever thought of it before; we could really use the outcome of that research. (OK, so it's a lame attempt at humor...) It's been years since it was possible to be amused by the number of people who assume that spammers are more ignorant and less competent than they are, and so propose spam solutions predicated on spammers being unable to register as many names, keys, identities, or whatever as needed or as many as everybody else can. ... host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. That's not a powerful solution, because it assumes the existence of a central mail authenticator for every domain that might send mail. As long as most SMTP clients don't have such authenticators, the spammers would simply avoid the few that do, just as they already avoid providers that break the financial kneecaps of spammers. As far as I can tell, the familiar claim that most spam carrying surprising header or envelope From adddresses is forged is mostly wrong. The claim seems to be based in large part on the knowingly misleading descriptions of the situation by free mail providers. The free providers claim that almost all spam implicating them is forged. If you read the fine print in their announcements of terminated accounts, responses to spam reports, and related messages, you'll discover that free provider spam is forged in the same sense your picture postcards would be if you were evicted from your home while travelling. That suggests that such authenticator servers would help reduce spam using free provider drop-boxes. However, a better solution that does not involve the rest of the network subsidizing the advertising agencies that are the free providers is to reject all mail apparently from free providers. Doing extra processing that is made necessary only because the free providers cannot be bothered enforce sufficiently painful terms and conditions on their users is a subsidy. The free providers could stop spammers from using their services if they would launch lawyers, require bonds (e.g. creditcard numbers), or any of many other things, but anything would cost them money. Vernon Schryver[EMAIL PROTECTED]
RE: namedroppers, continued
From: Marc Schneiders [EMAIL PROTECTED] ... It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start. That's another stupid crackpot spam solution that just won't go away. You cannot have abuse control built into a protocol that allows strangers to send each other mail. Any mail protocol that lets you receive mail from a stranger must also let the stranger send the same message to you and to 30,000,000 of your closest friends. On the other hand, if you want to only accept mail from people who are not strangers, you can use any of the many official and ad hoc SMTP extensions to ensure you only receive mail from them. If your computer system, mail protocol, or whatever knows that a stranger is not a spammer, then the stranger is not really a stranger. Vernon Schryver[EMAIL PROTECTED]
Re: namedroppers, continued
On Fri, 06 Dec 2002 14:34:14 PST, Hallam-Baker, Phillip said: The problem here is that having Randy Bush moderate is not a scalable solution to the problems of Spam in general. We could clone him, but that's probably not scalable either msg09660/pgp0.pgp Description: PGP signature
RE: namedroppers, continued
I'v been saying about need for more radical change in mail protocol for years now on mailing lists. I'd rather work on smtp itself, but some people who were involved in original protocol do not want any serious changes to what they'v done, though its clear that abuse and other holes with current system is creating too many problems. In any case, by next ietf meeting in san francisco, I'll bring complete proposal for new protocol and might even try some practical tests. I do still believe that smtp can be saved, but not without more complex authentication system during delivery of email and that can't be done with current protocol design or current available extension process. Also were there any discussions or more complete discription of this algorithm for checking if host had sent an email and if so is this available on website or archive to read more about? If answer is yes, can somebody send me url or approximate date of discussions so I could lookup in archives. And am I correct here in understanding what was proposed is that smtp conversation id be such that receiving mail server could verify with sender (callback?) that it deed indeed initiate the email. If so I do not quite understand how MD5 helps there, plus I see quite a few problems with creating some special mx-like record in dns just for verification. If this is indeed what was proposed its better to go with paul vixie's proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt On Fri, 6 Dec 2002, Marc Schneiders wrote: On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote: I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. Spammers would be the first to set up your mailid host. They will have had years of experience to find holes in the system before you've convinced everyone to adopt or accept the mailid. It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start.
RE: namedroppers, continued
This is note quite right. While its impossible to built open system that would prevent all abuse, you can first of all built system that would provide good verification of who sender is and you can do a lot to make it difficult to send thousands of same emails or at least make it easy to identify who is doing it and give tools for sysadmins to monitor and prevent such activity. On Fri, 6 Dec 2002, Vernon Schryver wrote: From: Marc Schneiders [EMAIL PROTECTED] ... It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start. That's another stupid crackpot spam solution that just won't go away. You cannot have abuse control built into a protocol that allows strangers to send each other mail. Any mail protocol that lets you receive mail from a stranger must also let the stranger send the same message to you and to 30,000,000 of your closest friends. On the other hand, if you want to only accept mail from people who are not strangers, you can use any of the many official and ad hoc SMTP extensions to ensure you only receive mail from them. If your computer system, mail protocol, or whatever knows that a stranger is not a spammer, then the stranger is not really a stranger. Vernon Schryver[EMAIL PROTECTED]
RE: namedroppers, continued
On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or I've had a look at vixies proposal and it's a good one. I certainly would welcome something like the mailfrom dns record. regards joe baptista
Re: namedroppers, continued
it's difficult to imagine a mailing list for which this thread is on-topic. I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by vector of prime numbers resulted in vector of remainders. I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. -- here was my attempt at this, which i didn't really know where to go next with: IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition this e-mail came from where it says it came from. 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to reject all e-mail claiming to be from HOTMAIL.COM since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form use PGP and use SSL are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid (wanted) e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in we can be sure that this did not come from where it claims and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is MAIL-FROM, whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from [EMAIL PROTECTED], the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4 So, the inbound mail server set partially overlaps with, but differs from, the example outbound mail server set. This is quite common in the Internet, and is the reason why the normal inbound mail server set described by a domain's apex MX RRset cannot be used for repudiation purposes. Vixie Experimental [Page 2]
Re: namedroppers, continued
proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or I've had a look at vixies proposal and it's a good one. I certainly would welcome something like the mailfrom dns record. actually I'd call it a nonstarter in its current form. I would have to agree. given that - mail from is used for nondelivery reports and other notifications; users need to make sure it gets set to an address that they'll read - nomadic users have valid reasons to post from random places on the net (including multiple ISPs) and keep the same mail from address. - many ISPs won't let you forward or submit mail through someone else's SMTP server, even if you have permission to do so. so you can't forward your mail through your home ISP's mail server to allow the mail from check to work. In addition to these valid concerns I'd add that various sorts of autoforwarding exist that don't change the MAIL FROM. These would also tend to break if such a scheme were implemented. I'm also concerned about the management aspects of having lists of authorized multistage relays and all that implies. trying to reuse any of the existing return addresses in email as a spam identifier just won't fly. a separate identifier might work. But there's also a problem with NOT using the MAIL FROM -- one of the things that's being counted on here is that mailing list expanders will (optionally) check the MAIL FROM against this new DNS record, but then change it unconditionally to an address associated with the list expander rather than with the originator. (actually Sender is the closest thing to what is needed here, unfortunately it's routinely munged by mailing lists) To the extent that sender is munged by mailing lists to refer to the list expander it would actually be a feature here, not a bug. But just as you cannot count on it being left alone, you also cannot count on it being changed. Perhaps the real problem here isn't the use of MAIL FROM but rather the assumption that binding ipsource to the MAIL FROM domain is a useful validation check. A specific ipsource is just not a property a legitimate user of a given domain can be expected to have. Although I am reluctant to suggest anything involving public key crypto, another approach would be to put a public key in the MAIL-FROM DNS record and add a new header field containing a signature covering the message's MAIL FROM and the current date. Ned
RE: namedroppers, continued
OK.. Almost plausible. However note that currently, the PGP web-of-trust covers only a small percentage of the subscribers to the IETF list, and there's no *really* good PKI for S/MIME yet (hint - we don't seem to even understand how to apply 'basicConstraints', so if you think we're going to have working CRLs anytime soon, please share the name and address of your pharmaceutical supplier.. ;) OCSP scales fine for revocation checking. We can use the same platform that currently serves 6 billion DNS queries a day. I don't have a pharmaceutical supplier at hand, however I can provide you with the name of a company that has a nice line in herbal viagra if you are interested. I propose to you that using a Thawte free S/MIME cert proves approximately zero - a spammer can just get one for each run (and remember that no matter how much a spammer tries to hid their identity, they *still* have to provide a working way to reach them (via smtp or http or whatever) or they don't get any feedback) If the spammer wants to perform custom operations for each constituency they want to spam. I don't think they do, they have to be able to spam millions of people at a time or the response rate is simply too low. Reported response rates are in the thousandths of a percent, so spamming the entire IETF gets less than a tenth of a customer. Phill smime.p7s Description: application/pkcs7-signature
RE: namedroppers, continued
The fact that OCSP scales fine for revocation checking doesn't mean that you have a system that scales fine for the *TOTAL PROCESS*. Stop blustering, you clearly did not know the difference between a CRL and OCSP and certainly have no real world experience of operating PKI on which to base your broad assertions. Also, there's the added issue that the DNS cuts down on traffic by way of caching. The ATLAS cluster that runs the core DNS (.com, .net, .org) is supporting six billion queries a day. The caching in the secondary servers goes some way to reduce load but not as much as many think. Unfortunately, that's the LAST thing you want a CRL to be doing (in particular, negative caching is an extreme no-no). No it is not. If you knew what a CRL is you would know that they are issued on a periodic basis and that caching is therefore exactly what Windows or any other sensible O/S does with a CRL. You appear to be confusing CRLs with OCSP. Try reading the OCSP spec, I wrote the original section on caching responses. Phill smime.p7s Description: application/pkcs7-signature
Re: namedroppers, continued
On Tue, 03 Dec 2002 08:21:22 PST, you said: Stop blustering, you clearly did not know the difference between a CRL and OCSP and certainly have no real world experience of operating PKI on which to base your broad assertions. I said total process. The process failure described in the CERT advisory didn't care if it was a CRL, OCSP, a X.509 certificate, or a piece of paper scotch-taped to one end of a tin-cans-and-string link that says Don't use unless your name is Fred. I admit I don't do any PKI per se. What I *do* have is over 2 decades of making a good living at cleaning up the mess when people misconfigure things. So I'm reading RFC2560 and see this in section 5: A denial of service vulnerability is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating the situation. Unsigned error responses open up the protocol to another denial of service attack, where the attacker sends false error responses. and I combine that with the research out of CAIDA I cited earlier that showed 98% of DNS queries to a root nameserver being broken, and my experience tells me that This Is A Train Wreck Waiting To Happen. The only mitigating factor here is that section 2.5 allows the precomputing of a response and associated signature. You appear to be confusing CRLs with OCSP. Try reading the OCSP spec, I wrote the original section on caching responses. Hmm... I've checked RFC2560, and didn't find anything significant about caching other than beware HTTP proxies with broken caching (or did you mean the precomputation of responses in section 2.5)? Also, is there a spec for a DNS RR to supplement the serviceLocator extension of 2560 section 4.4.6? That would also help to minimize and distribute the load (as the OCSP RR could be lumped in with the other DNS RR's for DNSSEC processing - handing back the OCSP info in an additional info field then saves you another resource hit when an OCSP query gets made. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09608/pgp0.pgp Description: PGP signature
RE: namedroppers, continued
This whole discussion should be taken to the YWKTIEDNWWFALNORIBNLTICSADEWSIFOSTFSTNOML working group. (yes we know that internet email does not work well for a large number of reasons, including but not limited to, incorrect code, spam and dare we say it failure of smtp to fully support the needs of mailing lists). The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. While this would require a moderate degree of work on the part of the list users it would eliminate the need for moderator action. Problem posters could be dealt with by means of a formal process. Thawte still provides free S/MIME certificates, however for the purposes of this proposal it would suffice to use a self signed certificate. SPAM is becomming a serious problem - as Bersnteins own rather offensive spam protection measures atest. The only way to resolve that problem in the long run is to start authenticating the good signal at source. The strategy of attempting to isolate the bad signal from the good is failling progressively as the spam companies employ counter measures. The relevance of this to DNS is that the ability to authenticate an SRV record provides an imense amount of leverage in automating this process. For example I can have some form of information service set up linked to the DNS that tells people that I sign every one of my emails without exception and that any unsigned mail message can be rejected. SPAM is a security problem. If we don't fix it the signal to noise ratio will fall way below acceptable levels for many users. Phill -Original Message- From: Pekka Savola [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 30, 2002 8:00 AM To: D. J. Bernstein Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: namedroppers, continued [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to listname[EMAIL PROTECTED] and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On 29 Nov 2002, D. J. Bernstein wrote: Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. No, it's not 'end of problem'. If I cross-post a reply to some message with was cross-posted to a list I'm subscribed at and a list I'm not, in the general case I do *not* want to subscribe to the other list to be able to send my cross-post reply to both. Waiting for moderator approval is just fine for me, much better than requiring to subscribe or do something else. It's not black and white. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ smime.p7s Description: application/pkcs7-signature
Re: namedroppers, continued
Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed [and] to require the subscribers to register their signing key And how do we prevent spammers from registering their signing key? Are you suggesting that we change the IETF's open enrollment policy? -- Aaron Swartz [http://www.aaronsw.com]
RE: namedroppers, continued
First off, the problem of SPAM is one of the perfect being the enemy of the good. If we can cut the spam by 95% then that is a pretty useful achievement. So, no I don't think that the folk selling feather luggage, herbal viagra, p0rn etc are likely to go to that length in great numbers, unless that is the Internet as a whole adopts the same type of measure following our lead. However I have thought ahead to the issues of scale here, let us imagine that a large number of groups use the same scheme, that email agents that filter based on signatures are available and widely used. First, consider the effect of a minor authentication requirement on certificate issue, the ability to read email sent to the address specified in the certificate. Using that technique we could eliminate spams with bogus addresses which itself would be a major advance. The amount of spam that comes through with a valid email address is vanishingly small. Second consider that if the whole internet follows our lead and starts to use cryptography routinely there are a lot of additional steps that then become possible that are not practical until most people have a public key and there is a means of discovering that via a DNS linkage. Third one of the things we could do in an extended enrollment process would be to get participants to agree to the following set of terms: 1) Thou shalt not SPAM. 2) Thou shalt permit your messages to be posted in the archives. 3) Thou shalt provide timely notice of any intellectual property claims. 4) Thou shalt not take the name of the chair in vain unless she deserves it. 5) etc. Then we could sue the b*#*@#ds if they spammed after that. People have been looking for a test case for digital signatures for ages, so don't worry about the cost. A side benefit of this is that it would cause a lot of people to start using secure email and thus start to create some critical mass for email security. What we need is for someone to take Majordomo or the like and merge in some sort of filter to check S/MIME and PGP signatures. Then find a group that wanted to serve as a guinea pig (S/MIME or PKIX perhaps?). Alternatively we should perhaps form a group 'Deployment of secure email' which could apply this rubric. Phill -Original Message- From: Aaron Swartz [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:43 PM To: Hallam-Baker, Phillip Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: namedroppers, continued Hallam-Baker, Phillip wrote: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed [and] to require the subscribers to register their signing key And how do we prevent spammers from registering their signing key? Are you suggesting that we change the IETF's open enrollment policy? -- Aaron Swartz [http://www.aaronsw.com] smime.p7s Description: application/pkcs7-signature
Re: namedroppers, continued
On Mon, 02 Dec 2002 08:28:57 PST, Hallam-Baker, Phillip said: The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. OK.. Almost plausible. However note that currently, the PGP web-of-trust covers only a small percentage of the subscribers to the IETF list, and there's no *really* good PKI for S/MIME yet (hint - we don't seem to even understand how to apply 'basicConstraints', so if you think we're going to have working CRLs anytime soon, please share the name and address of your pharmaceutical supplier.. ;) Thawte still provides free S/MIME certificates, however for the purposes of this proposal it would suffice to use a self signed certificate. Unfortunately, although a self-signed cert works really nicely for some purposes (for instance, it's quite sufficient to get an SSL tunnel started so passive snooping doesn't work), it's inadequate here. The problem is that there's no good way to tell my self-signed cert from Dan Bernstein's self-signed cert from J. Slimy Spammer's self-signed cert. I'd be interested in knowing what quality of a self-signed cert would denote that the poster was possessed of the Non-Spammer Nature. I propose to you that using a Thawte free S/MIME cert proves approximately zero - a spammer can just get one for each run (and remember that no matter how much a spammer tries to hid their identity, they *still* have to provide a working way to reach them (via smtp or http or whatever) or they don't get any feedback) /Valdis msg09571/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Mon, 02 Dec 2002 11:12:36 PST, Hallam-Baker, Phillip said: First, consider the effect of a minor authentication requirement on certificate issue, the ability to read email sent to the address specified in the certificate. Using that technique we could eliminate spams with bogus addresses which itself would be a major advance. The amount of spam that comes through with a valid email address is vanishingly small. You don't need a cert for this - a simple OK this magic cookie confirmation scheme (as supported by almost all mailing-list management software) is enough. Then we could sue the b*#*@#ds if they spammed after that. People have been looking for a test case for digital signatures for ages, so don't worry about the cost. People have been looking for somebody ELSE to be the test case for ages. The EFF is in the business of raising money to fight legal battles. The IETF isn't. You might want to ask the IESG if they have the budget for this - and remember that quite often, there *isnt* case law about some interesting point because one party or the other decides it's easier and cheaper to just settle rather than take it to court. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09572/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Mon, 02 Dec 2002 14:33:16 PST, Hallam-Baker, Phillip said: If the spammer wants to perform custom operations for each constituency they want to spam. No - you need a single custom cert/identity for each spamming run of several million. Unless you were *really* intending to cross-check the 3,000 spams they dropped on the IETF lists against the ones they sent to yahoo.com's mailers, and the ones to AOL, and the ones to MSN, etc etc.. The worst part is that they would then present the *same* credentials to the main IETF list and all the working groups. This ends up leveraging one of the strong points of digital signatures - if a signature is well known because it's seen widely, it gets taken more seriously. And there's no really good way to tune this - I'm sure I post more to IETF lists than most spammers do, so you can't even say if they post more than X/day they're spammers I don't think they do, they have to be able to spam millions of people at a time or the response rate is simply too low. Reported response rates are in the thousandths of a percent, so spamming the entire IETF gets less than a tenth of a customer. But they got a tenth of a customer for *ONE* piece of outbound mail. Which is an extraordinary response rate. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09577/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On Mon, 02 Dec 2002 14:33:16 PST, Hallam-Baker, Phillip said: OCSP scales fine for revocation checking. We can use the same platform that currently serves 6 billion DNS queries a day. The fact that OCSP scales fine for revocation checking doesn't mean that you have a system that scales fine for the *TOTAL PROCESS*. Remember - the tough part isn't checking the list - the tough part is getting entries *INTO* the list in a secure manner. Go back and re-read the issue at http://www.cert.org/advisories/CA-2001-04.html and ask yourself if a CRL would have been handled any differently. Remember - it was a *process* failure, not a software failure. The DNS may answer 6 billion DNS queries a day. But I can name some DNS registrars that would take *MONTHS* to correctly transfer a domain. (The continuing refrain for *years* on NANOG: Has *anybody* ever gotten PGP auth to work with these bozos?) Also, there's the added issue that the DNS cuts down on traffic by way of caching. Unfortunately, that's the LAST thing you want a CRL to be doing (in particular, negative caching is an extreme no-no). You can tell the ISP's DNS server to cache the SOA and NS entries for amazon.com. You can't tell the ISP's OCSP server to cache the fact that there aren't any CRLs for the SSL cert that www.amazon.com uses. /Valdis msg09578/pgp0.pgp Description: PGP signature
Re: namedroppers, continued
On 29 Nov 2002, D. J. Bernstein wrote: Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. No, it's not 'end of problem'. If I cross-post a reply to some message with was cross-posted to a list I'm subscribed at and a list I'm not, in the general case I do *not* want to subscribe to the other list to be able to send my cross-post reply to both. Waiting for moderator approval is just fine for me, much better than requiring to subscribe or do something else. It's not black and white. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: namedroppers, continued
D. J. Bernstein wrote: Bush stuck the following note into the top of my latest message to namedroppers: ... You're perfectly aware that many senders don't read messages to the list. ... Yet - you must be reading the list or you would not have seen it. Please cry elsewhere. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: namedroppers, continued
Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
RE: namedroppers, continued
Silly question, But you DO know what it will take to get your message to be immediately seen by the list, you just aren't willing to do it... I believe the problem is in your court, easily solved and it is not time to move on to something that might be slightly productive Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D. J. Bernstein Sent: Friday, November 29, 2002 3:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: namedroppers, continued Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
Re: namedroppers, continued
Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. Well, as long as the method for getting the message to the subscribers (a) is simple and not onerous, and (b) cannot be automated then I'd probably agree that this is an acceptable solution. I've seen lists for which the way that this was accomplished - subscribing or getting on the acceptable posters list - involved several email round-trips to get the address of the list bot, get the help file, send a command, get back a cookie, send back the cookie, find out that the list bot won't accept subscribe requests and/or cookies from a different address than that for which the subscription is requested, etc. Basically it amounted to a considerable barrier to posting by outsiders. These days, with a web interface, that level of complexity is no longer necessary. But if you make the process automatable spammers _will_ game it. Keith
