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.