Re: Principles of Spam-abatement
Paul, PV but i'll bet my bank has ways of trusting your bank. ... PV if your bond is only $30/year then i probably wouldn't trust you no matter PV what my bank told me about your insurance company or what your insurance It depends upon what is being trusted and what the incentives are for violating the trust. Some trust does require a large, enforceable penalty for violations. Other trust can work quite well based only on history. A bank might give out small, unsecured loans based on that history, but might require a big loan to be secured. I might be willing to take a first-first email from someone who has a history of not-spamming, without requiring that they suffer a penalty (other than my reporting them to the third-party trust agency) if they violate that. d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: Principles of Spam-abatement
I might be willing to take a first-first email from someone who has a history of not-spamming, without requiring that they suffer a penalty (other than my reporting them to the third-party trust agency) if they violate that. no, you would not. dave, you're not thinking of this as information warfare. you have to. every time you consider a plan, ask yourself where are the loopholes? or how can it be abused? (and, what if 6 billion people did this?) identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing.
Re: Principles of Spam-abatement
From: Paul Vixie ... identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing. Stated that way, but perhaps with an unintended interpretation, I agree. Every mail sender is hooked by an entity that the mail receiver knows and that has its own reputation that can be checked today. The ISPs that own the IP addresses in every IP packet that Ralsky sends have their hooks in Ralsky. You can decide whether the implicit no-spam guarantee from that hooking agency is sufficient by checking your own blacklist or the blacklists of others via DNS or BGP. All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. - If you say that you cannot trust ISPs to terminate the accounts of spammers, then you must say that you cannot trust any other outfit to revoke the PKI cert or other assurance for spammers. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, than you must be willing to trust some ISPs to do the same and terminate accounts. - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. - You can be anonymous on the Internet only if your ISP protects you. No one is homeless on the Internet. The SYN-ACK for your SYN to port 25 must get back to your source IP address home at your ISP. The connection between you, the spam or mail target, and the ISP that has its hooks in the mail sender is better than any PKI or crypto related system could possibly be. It is not only much cheaper than anything Microsoft/Yahoo/AOL/Verisign would sell, but technically more reliable. IP address spoofing was practically impossible for spam even before RFC 1948 and related defenses, because it was too hard and unreliable if you need to make 10,000,000 successfully spoofed ISN predicted TCP connections per day. On the other hand, we all knew even before the bogus Microsoft Corporation certs or the discovery that those bogus certs could not be revoked that commercial PKI is eyewash. If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
On 3/17/2004 9:33 AM, Paul Vixie wrote: identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. Not applicable to sales@ or emergency@ type mailboxes. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Principles of Spam-abatement
Eric A. Hall wrote: On 3/17/2004 9:33 AM, Paul Vixie wrote: accepting incoming communication from someone the world has no hooks into is off the table. Not applicable to sales@ or emergency@ type mailboxes. Why? Should someone arrive at your Sales or Emergency window in your office, naked, what would you do? Off the table is IMO the correct action for an email address that is naked -- i.e., that has no verification information. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Cheers, Ed Gerck
Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Vernon Schryver) writes: ... If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. so, it's possible that there is some overlap between my universal privacy goals, and my support for the long-awaited dnssec extensions, and my support for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast deployment effort. -- Paul Vixie
Re: Principles of Spam-abatement
Vernon Schryver wrote: If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. I had some preliminary conversations with blacklist operators about this. There wasn't any interest in making a better protocol, but some people did expressed a need to document the existing one. Yakov
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Now, you may want to refer to that mythical element, the 'spam-free' protocol, a protocol that an information theory model says cannot be built. I guess we also agreed before that a 'spam-free' protocol is impossible. The IETF should not attempt to develop it. Thus, in asking for IETF technical solutions for spam, it is obvious that I do not mean spam filters or 'spam-free' protocols. We would all be very happy with a protocol that is almost spam-free -- in fact, I believe we would be quite happy with 90% at this time. Me thinks we don't need 100% ;-) An IETF technical solution to reduce spam is doable. Your comment on 'spam-free' is useful-free ;-) The IETF cannot reduce spam either. Protocol changes are simply gratiutious. One might say that there is very little spam on X.400 mail systems. But it is simply because spammers aren't interested, not because X.400 has some special immunity. Spammers will simply adapt to any gratuitous change. At best, only a temporary reduction would be obtained, until the spammers adapt. After they adapt, there is no reduction. However, I think there are things that show some promise that might be harder to adapt to, such as automated text summarization, bayesian filters, mail agents that filter on the user's interest in the message subject, and such. I think these are worth pursuing, but these are not subjects for the IETF. Further, there are still inverse methods for spammers, so even these will simply be temporary. But I think the benefit of intelligent agents and summarization and interest filtering could be very beneficial in filtering even non-spam mail. Ages ago, managers had secretaries filter there postal mail and phone calls. I'd love to have a 'secretary' filter my email, so that I could subscribe to noisy lists and see only the messages that I was interested in. But this is technology that isn't a protocol, nor does it seem to be in need of a protocol, so there is little or no reason for the IETF to be involved. No, it is quite useful: The IETF can do nothing to prevent spam. ;-) this mantra is becoming a spam. Or perhaps it is the mantra that the IETF can do something to reduce spam. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. The only thing that can acheive this is to turn off the computer. No, it's a matter of degree. Even if not all spam is preventable, preventing email address spoofing (even to a degree) would have a range of benefits. For example, I would no longer receive those undelivered messages for email that I purportedly sent, but actually never did. And people receiving email from me could actually trust to some extent the outcome of their filters. And, to be clear, I'm not talking about PKI. Actually, I want to receive those bounced messages. Otherwise I don't know if someone is out there trying to abuse me. Often, the perpetrator can be identfied from these bounce messages, since they usually include the original message and its mail headers, which give an IP address and a time of use. But it is easy to delete messages from Mailer Daemon if you don't want them. The problem here is to distinguish the real you from the not-real you. Or rather, to distinguish the unauthorized not-real you from both the authorized not-real-you and the real-you. Real users use relays. Real users also use agents, like cron jobs to send email. How do you know the cron job is not a spammer? It might be abuse. It might not be abuse. We don't know until we check on it. There is no way to avoid this check. RMX can't work, because real users need to be able to use a wide range of relays, which depends on their physical location as well as their arrangements for outsourcing, as well as the service offerings of multiple providers. For example, Av8 Internet provides relay services for users of earthlink, because those users have leased line services from Av8, but email services from Earthlink, and earthlink doesn't do relay service outside its IP address space. How is the relay to know if the message is really from you or not really from you? Password (or per-user account) style authentication (such as SMTP AUTH) hasn't had any effect on spam, and it doesn't scale well, and isn't widely supported. Passwords can be stolen by viruses, or by disgruntled users if they are well-known. If you
Re: Principles of Spam-abatement
On 3/17/2004 10:47 AM, Ed Gerck wrote: Eric A. Hall wrote: Not applicable to sales@ or emergency@ type mailboxes. Why? Should someone arrive at your Sales or Emergency window in your office, naked, what would you do? uh, public nudity is (mostly) criminal, so not a good analogy, although comparisons to a no shirt, no shoes, no service policy statement would be getting there. A better analogy is with new checking accounts. Many places won't accept checks numbered below 1000, since they indicate that the account has not established a track record. Other places will accept the checks after verification, other places will accept them with thumbprint or some other identifier. In all these cases, the organization is able to determine its risk limits and act accordingly. I'm not going to get sucked into this endless debate, but it is equally tyrannical to require everyone use some kind of hard trust as it is to require everyone use no trust (what we are moving away from, in blobbish fashion and pace). There must be consideration for exceptions; the swimming pool snack bar probably cannot enforce a no shirt... policy. Property rights (of which I am a big advocate) work because they can be selected and enforced at the owner's scale; people can put up no trespassing or no solicitation or no hunting or no shirt... signs to advertise their chosen policies. The same kind of mechanism is needed for property protection to work in networking as well. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Verification is different from trust. My position is that you need to be able to validate and verify before you can successfully apply any kind of trust (otherwise the trust is meaningless). Paul's message that I replied to was specifically describing a minimum threshold of trust (it was akin to the no checks below #1000 position). -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Principles of Spam-abatement
When you cannot trust people like Paul Vixie and Bill Manning to terminate sites that are engaging in plainly obvious and egregious defamation and harrassment claiming that IP address space is hijacked when a quick check of the registry indicates that it isn't, then you also can't trust them to be in charge of a trust system. They are people who have asked others to trust them. They are people who have said that trust is important. They are people who have said ISP's should have AUP's, and should enforce them against abusive users. The world certainly has its hooks into them. Yet, we find that they are associated with court-proven liars and other disreputable people, who have their own spiteful agenda, and they aren't even embarrassed by that finding. We find them misleading their subscribers, for example by blocking companies outside of their criteria, or just completely falsely for spite. This type of thing hasn't happened just once, but many times, by many blacklist operators. Quite obviously, we can't have a trust based system, because the anti-spammers are even less trustworthy than the spammers. --Dean On Wed, 17 Mar 2004, Vernon Schryver wrote: From: Paul Vixie ... identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing. Stated that way, but perhaps with an unintended interpretation, I agree. Every mail sender is hooked by an entity that the mail receiver knows and that has its own reputation that can be checked today. The ISPs that own the IP addresses in every IP packet that Ralsky sends have their hooks in Ralsky. You can decide whether the implicit no-spam guarantee from that hooking agency is sufficient by checking your own blacklist or the blacklists of others via DNS or BGP. All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. - If you say that you cannot trust ISPs to terminate the accounts of spammers, then you must say that you cannot trust any other outfit to revoke the PKI cert or other assurance for spammers. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, than you must be willing to trust some ISPs to do the same and terminate accounts. - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. - You can be anonymous on the Internet only if your ISP protects you. No one is homeless on the Internet. The SYN-ACK for your SYN to port 25 must get back to your source IP address home at your ISP. The connection between you, the spam or mail target, and the ISP that has its hooks in the mail sender is better than any PKI or crypto related system could possibly be. It is not only much cheaper than anything Microsoft/Yahoo/AOL/Verisign would sell, but technically more reliable. IP address spoofing was practically impossible for spam even before RFC 1948 and related defenses, because it was too hard and unreliable if you need to make 10,000,000 successfully spoofed ISN predicted TCP connections per day. On the other hand, we all knew even before the bogus Microsoft Corporation certs or the discovery that those bogus certs could not be revoked that commercial PKI is eyewash. If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Vernon Schryver wrote: (A bunch of beautifully said things that I agree with fully) If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. The one other place that I think there COULD be room for improvement is to make the process of identifying sites that are originating spam or viruses more rapid and automatic, and to create a better/more formal set of rules responding to a site (or an entire SP subnetwork) postmaster. Such work might actually spell out all the steps between reporting and being blacklisted. Right now I think it is safe to say that most users don't know anything about postmaster addresses. Nor do they know how to read a mail header (or they may be using a MUA that doesn't present the full header even as an option). Finally, complaining about spam takes time, especially when you have a lot and have to write an actual message about each one one at a time. Consequently 99+% of all users are effectively prevented from reporting spam to the hosting SP of the originator by a mix of inertia, ignorance, and inability. No wonder the SPs feel that they can ignore the problem -- instead of a million pieces of spam generating a million complaints and burying the poor postmaster admins of the enabling SP in an emergency consisting of rapidly filling mail spool files and writing procmail rules to handle them all so they can extract real communications from all the spam complaints, they get ten reports of spam, maybe, from ten hardnosed old timers who can read a mail header and care enough to report them (maybe because they make it through their filters). I no longer bother -- if I have to generate a complaint message per piece that my filters identify, I'll never get ANY work done. If every ten pieces of spam sent out of an SPs network -- even every 100 pieces -- generated a complaint message to postmaster with headers laid out that clearly identified the offending host/client, I think that it would provide SPs with a real incentive, AND the tools, to address the problem. I don't know if this is a problem that could be addressed in protocol, but it might be. I can think of several things that an MTA (or MUA) might do to facilitate a spam-bounce. a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. d) Take steps to ensure that SPs run a postmaster address, and maybe come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. So even though one could argue that adding a real protocol layer for a preformatted, standardized, spam/virus bounce is not strictly necessary because all the information is already IN the header, doing it anyway might codify and standardize a complaint so that the complaint always contains the essential information and so that a complaint to the right target is easy to generate (can even be generated automatically). It could then guide the development of compliant tools that can deal with this for
Re: Principles of Spam-abatement
Vernon Schryver [EMAIL PROTECTED] wrote: All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. Not so. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. ISPs operate in a _very_ different business environment than, say, UNICEF. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. ISPs offering $30-per-month service are very likely losing money (and worrying who to lay off next). Your bank, OTOH, is probably doing nicely on less than $30-per-month service charges. Also, some ISPs have no reason to worry much about their reputation, because they have in effect a government-mandated near-monopoly. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, then you must be willing to trust some ISPs to do the same and terminate accounts. Ah, yes, but _which_ ISPs? - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. The first part is actually true: I think we'd actually see that if such third-party services come into common use. :^) The second part (terminating) is not true, IMHO. There's a real danger of getting sued for that, not to mention the loss of revenue. However, donning Pangloss's hat, I do hope that they might activate some port-25 bandwidth-limiting. ;^) If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. Current DNS blacklists are, IMHO, trying to do an impossible job. However, this is merely a matter of optimization or elegance. I disagree: it's a matter of biting off more than you can chew. -- John Leslie [EMAIL PROTECTED]
Re: Principles of Spam-abatement
Hello folks, Eric A. Hall wrote: uh, public nudity is (mostly) criminal Too bad! Actually, what is often proscribed is lewd behavior, and nudity is often wrongly considered lewd. Anyway it's awfully difficult to really reconcile nudity with criminal behavior. Regards, Charlie P.
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Eric A. Hall wrote: A better analogy is with new checking accounts. Many places won't accept checks numbered below 1000, since they indicate that the account has not established a track record. Other places will accept the checks after verification, other places will accept them with thumbprint or some other identifier. In all these cases, the organization is able to determine its risk limits and act accordingly. Which is really pretty silly, right? Since anybody will print you checks that start with any number you like, completely legally. In fact, you can print your own checks with any number(s) you like, completely legally, as long as the bank information at the bottom is there and is correct and you actually own the account in question and don't commit fraud or pass bad checks. This kind of silly response is no obstacle to a criminal or spammer; it is merely an inconvenience (a pain in the ass) to the innocent. It also leaves one with all sorts of catch-22 problems -- one cannot get a track record until one is let onto the track, and one cannot get onto the track without a track record. Besides, this is all talking about IP numbers, right, since we all AGREED that user identies were transient artifacts and impossible to regulate. In the checking account metaphor above, on the internet I can print a new check with whatever numbers you like for each and every transaction, and back it up with a shiny new driver's license and any other identification tokens you require unless and until you create a huge government bureaucracy to regulate it and harsh laws to punish abuse. Sort of like the ones we have for real driver's licenses and checking accounts and human identities. Banking (and other human metaphors) are not correct for addressing IP number trust. It's more like can you trust the current residents of this neighborhood or that house down the street...when you never get to see them, only their masks. And IF we're talking about IP addresses, we can pretty much stop talking. As Vernon has repeatedly pointed out, trust-like facilities at the IP level are either ALREADY THERE and proving to be moderately ineffective against spam or run square against the economics and realities of the SP business. We cannot do anything silly like not trust a new IP number assigned by an SP to a new customer until they have a track record. Trusted has to be the default or the Internet and a variety of business become impossible and incredibly burdensome on the innocent (far more so than spam). But I don't care if you agree -- as you note, you can not trust any parts of IP space you choose according to any criterion you select, within your own hosts or networks. Just don't blame anybody else when things stop working because you've punched a hole through a path to a critical service or human. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Verification is different from trust. My position is that you need to be able to validate and verify before you can successfully apply any kind of trust (otherwise the trust is meaningless). Paul's message that I replied to was specifically describing a minimum threshold of trust (it was akin to the no checks below #1000 position). You have to be able to quantify trust as well, in order to be able to use it as a filtering criterion. I fear that your metaphor is exact -- it is NO more difficult for a spammer to achieve whatever level of trust is required for acceptance for long enough to spew than it is for me to ask the bank to start the checks for my brand new checking account at #2000 since of course some merchants won't take them otherwise. Or going home and printing some new ones. Somebody (Dean?) pointed out that if you can really solve the problem of trust at the electronic level, scalably and more or less for zero marginal cost, you're missing the real point. These are the SAME problems that are incredibly difficult to solve in the financial industry where the penalties are large and expensive, laws that severely punish identity theft artists and check forgers are vigorously enforced, and where instruments for reasonably reliably affirming identity (photo drivers' licenses, passports, birth certificates all abound and are tightly constrained by law and expensive government agencies and services. It's hard to trust even paper money, let alone that some stranger is who they assert themselves to be. In that sense it is an excellent milieu to look for metaphors to the network/spam/identity problems, just as paper spam and phone spam are also good places. If you can solve one, you can solve the other IF you are willing to pay similar costs. So next time anyone wants to advance a human-scale metaphor for a trust model, please a) ensure that it actually is
Re: Principles of Spam-abatement
From: Paul Vixie [EMAIL PROTECTED] If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. so, it's possible that there is some overlap between my universal privacy goals, and my support for the long-awaited dnssec extensions, and my support for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast deployment effort. DNSSEC would be a Good Thing(tm) on its own merits, but I don't see any direct connection between it and a replacement for DNS blacklists. Of course a replacement would start without reasonable authentication. If you insist on using DNS screwdrivers as SMTP authorization hammers, then DNSSEC blacklists would be a minor improvement. DNS has the wrong sorts of caching as well as the wrong sort of data for a reputation database. You want answers better than 32 bit number (PTR RR) or an ASCII string (TXT RRT). I don't see what multicast has much to do with my SMTP server asking my chosen (and hired) clearinghouse about the reputation of the owner the IP address of an SMTP client. Some sort of anycast might be a good optimization. I guess anycasting can be seen as a form of multicasting. Is that what you mean? ] From: Yakov Shafranovich [EMAIL PROTECTED] ] I had some preliminary conversations with blacklist operators about ] this. There wasn't any interest in making a better protocol, but some ] people did expressed a need to document the existing one. People with working code and large customers bases rarely choose to replace a servicable solution like the current DNS blacklist kludge with a proper solution, no matter how much more elegant. Replacing the DNS blacklist kludge with something better today would be little more than arranging the deck chairs. What's needed is to patch the hole in the hull, or for more ISPs to do as Earthlink has done in recent years and get serious about dealing with spam. Earthlink is far from perfect, but they are far better than they were and far, far better than other outfits. For example, as far as I can tell, today an SMTP connection from Comcast is likely to be carrying spam, while a connection from Earthlink probably isn't. If you don't have your own traps, see the numbers at http://www.senderbase.org/ or the better but less immediate numbers at http://spamhaus.org/ } From: Robert G. Brown [EMAIL PROTECTED] } ... } The one other place that I think there COULD be room for improvement is } to make the process of identifying sites that are originating spam or } viruses more rapid and automatic, and to create a better/more formal set } of rules responding to a site (or an entire SP subnetwork) postmaster. } Such work might actually spell out all the steps between reporting and } being blacklisted. I strongly disagree. There is and can be nothing better than the IP address of the SMTP client for identifying the orgin of a mail message. Some will object that's not the origin, but they're generally repeating the nonsense and lies of ISPs trying to duck blaim for supporting spammers. The practical origin of a paper letter is wherever the postals service, FedEx, etc. accepts it, no matter whether you wrote it while standing in the post office, at home, at work, or in an airplaine 35,000 feet above practically unknowable real estate. Yes, I've heard about UUCP, SMTP relays, smarthosts, and so forth and so on. As far as your SMTP server is concerned, a good, sufficient, and necessary definition of the origin of a mail message is the IP address of the sending SMTP client. It doesn't matter whether the sending IP address is an open proxy on a Comcast network, a system in China, or Dell Computers' newsletter senders. The IP address as good as anything else could be, and already available. It's only defect is that it makes ISPs responsible for taking Ralsky's money. } If every ten pieces of spam sent out of an SPs network -- even every 100 } pieces -- generated a complaint message to postmaster with headers laid } out that clearly identified the offending host/client, I think that it } would provide SPs with a real incentive, AND the tools, to address the } problem. I used to say that, but then I saw that even (or especially) the worst ISPs can figure out how to connect postmaster@ to /dev/null or to an autoresponding ignorebot that lies about the responsibility of the ISP. | From: John Leslie [EMAIL PROTECTED] | - If you say that you can't trust ISPs to check that a new customer |is not Al Ralsky in disguise or one of his proxies, then you must |say the same about any other organization. | |ISPs operate in a _very_ different business environment than, say, | UNICEF. Possibly true but certainly irrelevant. | - If you say that ISPs cannot check the reputation of new customers |
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Robert G. Brown wrote: a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. This is true now. Many people don't know how to parse the headers, but it obeys a specific syntax and is machine parseable. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Proxies are another story. I don't know of any genuine reasons to run open proxies, though closed proxies (web caches) are clearly useful. I don't know of anyone claiming they are useful. But neither does that mean they have no use. However, as a service provider, I would say this much: If a customer found a useful reason to have an open proxy, then I would only insist that they keep logs of its use. This is easy to place in a contract or AUP. d) Take steps to ensure that SPs run a postmaster address, and maybe There is already a BCP for this. Rarely is this a problem. come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. How would you define responsiveness? Does it mean getting an auto-responder message? Does it mean getting a message saying something had been done? You cannot give out certain information about customers. Basically, all you can do is send an auto-responder message and a notice that the ticket was closed. That doesn't indicate what happened, nor does it indicate who the spammer was, or if the ISP agreed they were a spammer. Sometimes the action is obvious if, say, a website disappears. But how do you know they took action against a dialup customer? You can't. Continuous measurement is the same as a DOS attack. A ping flood is a continous measurement of the bandwidth available and its responsiveness. That's why there is a -f option to ping. Unauthorized measurements are illegal. Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. ??? I'm not sure what you mean. By the time you -read- a spam, it is delivered, and the SMTP protocol has long since finished. Spam isn't the only kind of abuse that an ISP responds to. The abuse@isp works pretty well, since you can forward the complained-of message. There are some things I'd like MUA's to do, such as include the whole headers(some MUA's do, some MUA's don't), but that isn't an RFC issue, either. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. --Dean
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Let me make sure. You think then that a spam filter can be 100% efficient? If you do, please log off and go sell it. If you don't then I agree with you. Cheers, Ed Gerck
Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. I don't see what multicast has much to do with my SMTP server asking my chosen (and hired) clearinghouse about the reputation of the owner the IP address of an SMTP client. Some sort of anycast might be a good optimization. I guess anycasting can be seen as a form of multicasting. Is that what you mean? no. for one thing, this is not (at heart) an smtp problem. more later. -- Paul Vixie
Re: Principles of Spam-abatement
Dean Anderson wrote (in part): c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Sounds like his first point - fix it so they are checkable. If I am going to relay for X number of domains, it seems reasonable that we share some kind of shared key or password so they the headers they pass me can be verified. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. There is (1.0) legal spam and (2.0) illegal spam. Illegal spam can be (2.1) advertisements or (2.2) viruses. (1.0) Is most often traceable using the headers and content. This is getting easier to stop and there can be things done to make it easier - a computer parseable unsubscribe link and a standard protocol to unsubscribe. (2.1) Often is traceable by the content, and almost never by the headers. Content filters and blacklists of some kind can catch these and throw them in the trash or hang-up when the content matches a URL that somehow blacklisted. (2.2) Is for a virus scanner to catch and is almost never traceable. There are things the IETF can do to help with the spam problem (1.0). -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 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: Principles of Spam-abatement
On Wed, 17 Mar 2004, Vernon Schryver wrote: } From: Robert G. Brown [EMAIL PROTECTED] } ... } The one other place that I think there COULD be room for improvement is } to make the process of identifying sites that are originating spam or } viruses more rapid and automatic, and to create a better/more formal set } of rules responding to a site (or an entire SP subnetwork) postmaster. } Such work might actually spell out all the steps between reporting and } being blacklisted. I strongly disagree. There is and can be nothing better than the IP address of the SMTP client for identifying the orgin of a mail message. Some will object that's not the origin, but they're generally repeating the nonsense and lies of ISPs trying to duck blaim for supporting spammers. The practical origin of a paper letter is wherever the postals service, FedEx, etc. accepts it, no matter whether you wrote it while standing in the post office, at home, at work, or in an airplaine 35,000 feet above practically unknowable real estate. Yes, I've heard about UUCP, SMTP relays, smarthosts, and so forth and so on. As far as your SMTP server is concerned, a good, sufficient, and necessary definition of the origin of a mail message is the IP address of the sending SMTP client. It doesn't matter whether the sending IP address is an open proxy on a Comcast network, a system in China, or Dell Computers' newsletter senders. The IP address as good as anything else could be, and already available. It's only defect is that it makes ISPs responsible for taking Ralsky's money. I AGREE with this. There is a bit of difficulty associated with just which IP address in a chain of delivery hops is the actual point of origin, but at least at this point I generally trust that forwarding hosts really are just forwarding hosts when I look at a header to see. To be concrete (pulling a note at random out of the garbage for the week): From [EMAIL PROTECTED] Sun Mar 14 15:28:51 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64]) by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7 for [EMAIL PROTECTED]; Sun, 14 Mar 2004 15:28:51 -0500 (EST) Received: from 152.3.233.64 ([200.215.92.74]) by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id i2EK4b0 3030509; Sun, 14 Mar 2004 15:04:57 -0500 Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00 +0600 Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is telling the truth about where it received the message from and isn't forging the previous hop because its administrator(s) are local and accountable and their address resolves. This particular example is interesting in that as far as I can tell from registry information, 7.197.76.17 doesn't exist and there is no route to it. The 200.215.92.74 address is a relay in brazil. Neither of them seems promising in terms of being able to report the spam. Note also that I have to WORK with whois, traceroute, host, dig, a variety of tools trying just to figure out where the spam is coming from (although admittedly spamassassin does the same work automatically and better which is why the message is in the trash). However, I'm still left unable to complain to the enabling ISP. They speak portuguese and I don't. They may have postmaster set up or may not. They may give a rat's ass or may not (likely not). To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address and are not responsive to spam. The communication mechanism that reports spam has to both include the key information about times, addresses, and so forth AND has to function independent of knowledge and degree of expertise of the user. I know what I'm doing (at least, to a point:-) and I'm daunted by the prospect. Most users wouldn't even know what all those words I just used mean... So I have to say again -- there may be IETF work that could be done here. It shouldn't be this difficult, and there needs to be a whole structure erected to make mail administrators accountable at some level. And ultimately, we may all have to be willing to pull the plug on [EMAIL PROTECTED]|B:747host 200.215.76.17 17.76.215.200.in-addr.arpa domain name pointer BrT-S4-1-2-22-bnuce300.brasiltelecom.net.br. and effectively cut them off from the Internet if they don't police their relays and e.g. refuse to accept mail from unregistered hosts. Only thus can we forge a chain of responsibility back to the SPs that they cannot easily evade. } If every ten pieces of spam sent out of an SPs network -- even every 100 } pieces -- generated a complaint message to postmaster with headers laid } out that clearly identified the offending host/client,
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Dean Anderson wrote: On Wed, 17 Mar 2004, Robert G. Brown wrote: a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. This is true now. Many people don't know how to parse the headers, but it obeys a specific syntax and is machine parseable. Of course. To both -- many people don't know how to parse the headers. I'd estimate some 499,950,000 of the half a billion users of mail. So the CAPABILITY of parsing the headers exists, but not even AV vendors (who should know how and know better) do it. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. So what you are saying is, that this CAN be done and even is being done, but it isn't done correctly and consistently and isn't widely available. I agree. In fact, I think that this is potential work for the IETF -- define a way for it to be done correctly and consistently (which wouldn't be too difficult, I imagine) via a protocol. Then SpamCop could fix their tool, SpamAssassin could add a compliant interface, Joe's Spam Seal (not yet written) could be written to comply with the protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a response process based on consistent completely reported problems. This lowers their cost and makes it easier and more likely that they'll take effective action. As you say, if you get insufficient information, there is little that you can do even with the best of will as the manager of an ISP with too little time and too many things to fill it. You probably don't have time or energy to engage in the please resend your complaint with the full header and message attached game (known to administrators everywhere, and not just in regard to mail:-). c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Proxies are another story. I don't know of any genuine reasons to run open proxies, though closed proxies (web caches) are clearly useful. I don't know of anyone claiming they are useful. But neither does that mean they have no use. However, as a service provider, I would say this much: If a customer found a useful reason to have an open proxy, then I would only insist that they keep logs of its use. This is easy to place in a contract or AUP. Again, precisely. So what this means is that if I set up a mail server and send a lot of spam from it all with a header that is forged UPstream from my host, I obscure my host as its true point of origin. I can pick on a hapless host somewhere far away and make it look like the spam originates from THEIR network, and one would have to compare traffic logs on the two hosts and/or intermediary hops to determine which of us is lying. This makes for an interesting attack -- send egregious spam purporting to come from somebody you hate or some network you are in competition with, in a messages with multiple relays. Somebody with a big view of the hand might finally figure out what was happening, but proving it would be, well, difficult doesn't begin to describe it, given that all the log data on both sides could be easily forged. Again, there might be work for the IETF here that could help IF this becomes a problem or as a preemptive measure now. There are ways to do this -- signing a key with a local secret and adding it to the message, for example -- that even if you didn't have a universal PKI for all participating hosts would make forging headers for openly fraudulent reasons easy to catch. You can forge the upstream route, but you cannot forge the upstream keys, and the last common host whose key can unlock their MTA-added tag is left holding the responsibilty bag. d) Take steps to ensure that SPs run a postmaster
Re: Principles of Spam-abatement
From: Robert G. Brown [EMAIL PROTECTED] From [EMAIL PROTECTED] Sun Mar 14 15:28:51 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64]) by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7 for [EMAIL PROTECTED]; Sun, 14 Mar 2004 15:28:51 -0500 (EST) Received: from 152.3.233.64 ([200.215.92.74]) by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id i2EK4b0 3030509; Sun, 14 Mar 2004 15:04:57 -0500 Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00 +0600 Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is telling the truth about where it received the message from and isn't forging the previous hop because its administrator(s) are local and accountable and their address resolves. This particular example is interesting in that as far as I can tell from registry information, 7.197.76.17 doesn't exist and there is no route to it. The 200.215.92.74 address is a relay in brazil. Neither of them seems promising in terms of being able to report the spam. I disagree: 1. pohl.acpub.duke.edu is not an external relay for you. It is your system, even if you don't have a root password or any account on it. 2. 200.215.92.74 is not just a misconfigured relay, because it used the spam trick of using the IP address of its target for its HELO value. It might be an owned box with a trojan or it might be worse. 3. the Received line pointing to 7.197.76.17 is obviously silly nosnense for more than one reason. Let's not educate the listening spammers on the details. 4. you don't need to know why I claim #2 or #3 to properly report that spam. All you need is a tool that will pick out the only IP address that matters from the only Received header you can trust, the top one, and send a report. There are several common tools that do exactly that. Some involve commands lines, but most are point-and-click. Their defects are mostly that they try to do more, such as detecting hosts of spamvertised URLs. 5. #2-#4 are irrelevant. Whether Comite Gestor da Internet no Brasil hears about the spam fountain at 200.215.92.74 is none of your concern unless you have an unhealthy obsession with spam. All you should care is that by hosting that spam fountain, all hosts in 200.128/9 are less likely to be able to send mail to pohl.acpub.duke.edu and mailqueue1.duke.edu 6. Yes, I am a certifiable expert on at least some unhealthy obsessions with spam. To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address and are not responsive to spam. The communication mechanism that reports spam has to both include the key information about times, addresses, and so forth AND has to function independent of knowledge and degree of expertise of the user. I know what I'm doing (at least, to a point:-) and I'm daunted by the prospect. Most users wouldn't even know what all those words I just used mean... NO! Nothing significant has changed since Steve Wolfe stopped being the bogyman we used to frighten lusers into not being naughty. - all that is needed to fix this problem is for the operators of mailqueue1.duke.edu and pohl.acpub.duke.edu to have reasonable counts of the spam from 200.128/9 and take action, or to delegate those actions to the SMTP trust vendor of their choice (currently DNS blacklists). - If Comite Gestor da Internet no Brasil is a reputable outfit, then it will do as bazillions of other repubutable outfits, including Duke University, have long done, and detect and deal with its spam problem, without your let, leave, hindrance, assistence, notice, help, or nagging. - Purely for extra credit, someone might try to forward an unmodifed copy of that spam with complete headers to [EMAIL PROTECTED], [EMAIL PROTECTED], and/or [EMAIL PROTECTED] If the recipient can't figure out purely from the copy of spam what to do, then that's not our problem. At most 200.128/9 we should disconnnected from the Internet that we use by adding to our blacklists. If someone at Duke finds a need to receive mail from 200.128/9, you might review that blacklist entry or punch a hole in the blacklist. Apologists for spam friendly ISPs including those who claim to believe that $360/year is a fair price for a fundamental human right will say that ISPs can't stop spam unless everyone reports it. That claim is nonsense. When it comes from ISPs, it is a bald faced lie; it is possible even for a raw IP bandwidth ISP to detect spam. So I have to say again --
Re: Apology Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 12:26:13 -0500 (EST), Dean Anderson wrote: However, I think there are things that show some promise that might be harder to adapt to, such as automated text summarization, bayesian filters, mail agents that filter on the user's interest in the message subject, and such. How about You are a polluter, your connectivity has terminated, you are on a customer blacklist, and you will never get connectivity from us again? Spammers would have a little trouble adapting to that. I think these are worth pursuing, but these are not subjects for the IETF. IETF's documenting that this is the behavior expected of any firm offering connectivity is certainly within the IETF's purview. And it would have a dramatic effect. (Partly because of norms; partly, at least in the U.S., because it would expose pollution-enabling ISPs to heavy-duty legal liabilities. Stockholders would get after their boards.) Jeffrey Race
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 14:04:58 -0500, John Leslie wrote: - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. The first part is actually true: I think we'd actually see that if such third-party services come into common use. :^) The second part (terminating) is not true, IMHO. There's a real danger of getting sued for that, Depends entirely on what the contract of carriage says. Obviously one of the norms we have to universalize in standards and practice documents is that carriage is denied to polluters as part of the contract, and this provision must bind everyone else who shares connectivity under the contract. not to mention the loss of revenue. There you have it! Polluting pays! See http://www.camblab.com/nugget/spam_03.pdf Jeffrey Race
Re: Principles of Spam-abatement REALITY CHECK TIME
On Wed, 17 Mar 2004 15:48:05 -0500 (EST), Dean Anderson wrote: How would you define responsiveness? That's an easy one! 'Does the pollution cease?' is the answer. Let's pause this very interesting thread for a momentary reality check. See ROKSO. The world's top spammers, accounting for the great bulk of the packets, are known by name, address and telephone number. Their upload paths are known. Their software is known. The stigmata of their transmissions are known. (In many cases their criminal records are known.) It is trivially easy to verify _at any moment_ whether a pollution-enabler has responded. Does everyone agree? Dean, you too? :) Jeffrey Race
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 17:21:42 -0500 (EST), Robert G. Brown wrote: To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address Work has already started on this: http://www.rfc-ignorant.com/
IETF 59 Plenary Meeting Minutes
The draft minutes are now available at http://www.ietf.org/proceedings/04mar/minutes/plenary.htm. Please look over them if you spoke at either plenary - I would like to quote people correctly, and attribute quotes correctly. I'm almost sure that Eric identified in the Jabber logs is usually Erik Nordmark... I'll make this change in the revised version, due around the end of March. Others? Please send updates to me privately (no reason to disturb the discussions on what can, and can't, be done with SMTP, right?)... Spencer
GRE and L2TP
Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. My whole point is that i want to know as to what is the burning need to have L2TP! Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: Principles of Spam-abatement
Robert G. Brown wrote: Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. So even though one could argue that adding a real protocol layer for a preformatted, standardized, spam/virus bounce is not strictly necessary because all the information is already IN the header, doing it anyway might codify and standardize a complaint so that the complaint always contains the essential information and so that a complaint to the right target is easy to generate (can even be generated automatically). It could then guide the development of compliant tools that can deal with this for ignorant humans using stupid MUAs and maybe even (presumably) smarter AV programmer humans as well. We have a closed subgroup in the ASRG for discussions of exactly this kind of stuff (http://asrg.sp.am/subgroups/abuse_reports.shtml). But we haven't gathered that much interest which makes us think that not everyone considers this a great idea. Yakov
Re: Principles of Spam-abatement
Robert G. Brown wrote: On Wed, 17 Mar 2004, Dean Anderson wrote: On Wed, 17 Mar 2004, Robert G. Brown wrote: ... b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. So what you are saying is, that this CAN be done and even is being done, but it isn't done correctly and consistently and isn't widely available. I agree. In fact, I think that this is potential work for the IETF -- define a way for it to be done correctly and consistently (which wouldn't be too difficult, I imagine) via a protocol. Then SpamCop could fix their tool, SpamAssassin could add a compliant interface, Joe's Spam Seal (not yet written) could be written to comply with the protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a response process based on consistent completely reported problems. This lowers their cost and makes it easier and more likely that they'll take effective action. We are actually soliciting volunteers in the ASRG specifically for this kind of work - protocols and formats for abuse reporting to be discussed in a closed subgroup separate from the main ASRG list (http://asrg.sp.am/subgroups/abuse_reports.html). So far, we haven't gotten much interest :( As you say, if you get insufficient information, there is little that you can do even with the best of will as the manager of an ISP with too little time and too many things to fill it. You probably don't have time or energy to engage in the please resend your complaint with the full header and message attached game (known to administrators everywhere, and not just in regard to mail:-). If part of the protocol and format states that specific information is required, you can discard non-compliant reports solely on the basis of being non-standard. Or you can just discard them :) d) Take steps to ensure that SPs run a postmaster address, and maybe There is already a BCP for this. Rarely is this a problem. In the US. Try hitting the postmaster of 7.197.76.17, and good luck communicating with the postmaster of the brazilian relay in my previous reply. (This is picking nits -- actually I agree that what can be done largely has been done, but it would be lovely to be able to extend overseas with a little more ease, to get a bit poetic...;-) There has been a proposal in the ASRG from someone about storing contact data for abuse departments in the rDNS tree the same way there is a responsble RR type for forward DNS. So far hasn't seen much interest... come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. How would you define responsiveness? Does it mean getting an auto-responder message? Does it mean getting a message saying something had been done? You cannot give out certain information about customers. Basically, all you can do is send an auto-responder message and a notice that the ticket was closed. That doesn't indicate what happened, nor does it indicate who the spammer was, or if the ISP agreed they were a spammer. Sometimes the action is obvious if, say, a website disappears. But how do you know they took action against a dialup customer? You can't. No, I think that responsiveness has to be measured by the level of spam reported as originating within the site -- results. I don't think this is that difficult, actually. Vernon pointed out that once earthlink got serious about controlling spam, the reduction in traffic was very apparent. If the IETF has any role here (and it may not) it might be to codify the process of blacklisting ISPs that aren't serious as they are revealed. You've pointed out several times that abuse of blacklists is pretty easy as things stand. It shouldn't be. And people like you who have bad experiences with the previous non-process should be the ones who end up agreeing that whatever schema that might be proposed is fair and equitable and not likely to punish ISPs who are doing their best. A general BCP on blacklists and how to properly apply them would be higly useful. Another BCP on how to properly manage a blacklist would be useful as well. Both have been floated in the ASRG, no one volunteered :( Right now enabling SPs are insulated
Re: Principles of Spam-abatement
... you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? more of a new trust system than what you said. one thing to chew on is, there are many orders of magnitude more potential bad actors than potential good ones. What about the inherent resistance of existing people to change? there's no way to get existing people to change... against their will.
Re: Principles of Spam-abatement
On Thu, 18 Mar 2004, Yakov Shafranovich wrote: Paul Vixie wrote: [EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? What about the inherent resistance of existing people to change? This excuse is used as stop sign for number of new idea or protocol change in case of IETF. Don't listen to it - propose the ideas and work on them, if its truly good - it should be at least attempted. As far as trust protocol or whatever, this is very far from mainstream and current mechanisms are either within group of geeks using PGP or large corporations that use S/MIME and need it for their internal policies. It has not entered society at large so we still have time to come up with something good that will make it worth it for that to happen. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Principles of Spam-abatement
william(at)elan.net wrote: On Thu, 18 Mar 2004, Yakov Shafranovich wrote: Paul Vixie wrote: [EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? What about the inherent resistance of existing people to change? This excuse is used as stop sign for number of new idea or protocol change in case of IETF. Don't listen to it - propose the ideas and work on them, if its truly good - it should be at least attempted. Thanks :) As far as trust protocol or whatever, this is very far from mainstream and current mechanisms are either within group of geeks using PGP or large corporations that use S/MIME and need it for their internal policies. It has not entered society at large so we still have time to come up with something good that will make it worth it for that to happen. The discussions here, on the main ASRG list, in ietf-mxcomp and smtp-verify subgroup of the ASRG are currently dancing around this issue of trust and trust protocols. I would like to converge all of these discussions into one single forum, possible the ASRG. Yakov
