On Wed, 17 Mar 2004, Doug Royer wrote: > 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. The premise that relays add ficticious headers and evil content is wrong. But header checking would not be practical. It quickly becomes: "I am going to relay for some domains. The domains I am going to relay for are unknown in advance (or very much in advance) because the customer may add new domains. Further, that customer may themselves relay for some number of unknown domains." The description I gave of reasons that RMX won't work also applies. You may have to relay for other domains. The problem is very similar to, but much, much larger than the BGP route registries' configuration databases. There are about 140,000 or so advertised network number prefixes, and providers change their routing to other providers relatively infrequently compared with end users. The Route registry, in principle, allows one to automatically generate router configurations based on the what routes might be advertized by which AS numbers. In practice, it hasn't been such a success, though it does have it's proponents. It sounds much better in theory than it does in practice. Trying to do the same for millions of domains would be impractical, since the routing of those domains is even less static than the network routes between service providers. At the end of this, all you find out is that spammers will stop using forged headers. But quite a lot of spam these days doesn't have any forged headers. Indeed, it seems that spammers/abusers have lost interest in adding forged headers, as they have lost interest in open relay abuse. There is a related point that the IP addresses in the forged headers appear to be chosen randomly. So some percentage of these will not be routed, and will not be allocated. One could easily implement a check which simply tested all the IP addresses in the headers for routability. Of course, spammers would stop picking addresses at random, and would simply start selecting random addresses from the route tables. Such a test is obviously not worth implementing. > 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. CAN-SPAM prescribed the use of unsubscription methods, and 56% of spammers were fully compliant in January, and 95% were partially compliant in January. I've been using the links on some spam from genuine spammers, (eg tekmailer.com). They've been providing a mail-to url and an http url for unsubscription. These are already computer parsable. However, the hard part is to distinguish the genuine spammers from the fake spammers. I've been able to do this in most cases by examining the headers and the company--genuine spammers won't have any forgeries at all, and looking up information on them will turn up the fact that they are a real company. Fake spammers have web sites, too, and their unsubscribe links result in further mail bombing. But so far I've been able to pick them out, as they have to fake something, else they'd be real. > (2.1) Often is traceable by the content, and almost never by the headers. This isn't true. After the abuser has injected the message, the subsequent headers will be true. So abuse is traceable by the headers back to the SMTP injection point. Forged headers are always detectable, since they try to make one believe that mail was handled by a machine IP address that didn't actually handle the message. It is easy to see where the authentic recieved headers stop and the forged headers start. However, one can (and SpamCop does**) forward a complaint to the responsible party for each listed relay and domain. Those parties can then determine by looking at the message and their logs if their users were responsible for the message. If the message was injected by an open proxy, you can trace back to the open proxy. You may not be able to trace beyond that, but that isn't an SMTP protocol or relay issue. For example, if the received header in a message appears to have a dialup machine as relay, it is probably unlikely that the dialup really is a relay. The ISP responsible for the dialup IP will know this straight away, and will know that its customer is responsible. (Of course, the customer may not be a spammer, but may simply have a virus). Every genuine relay will also be in the message, and the owners of those relays know they are relays. Often it is obvious that they are genuine relays and their headers are also genuine, and they indicate from where the relay recieved the message. The only problem is that anti-spammers often have little knowledge of how or when relays insert headers, and in their ignorance, can't distinguish between fake headers and genuine headers. Protocol changes can't correct ignorance. > 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). **Again, SpamCop has merely demonstrated that certain processes are possible. They have demonstrated themselves to untrustworthy since they alter the message. Technical competence doesn't equate to honesty and integrity.