There is a new anti-forgery proposal which holds a good deal of promise. It is featured in Slashdot here:
Slashdot The Anti-Spam Research Group’s Plan for Spam.
Below is my response to the author of the proposal (not the slashdot writer :)
Hello,
I really like the proposal and I think you have done a great job in presenting it.
I have seen other previous proposals that didn’t seem to take off, such as “MS records” by Andrew Church or something like that. The first version was similar to your proposal here, but the second one involved a challenge-response type of system based on cryptography and I think that something complex and heavy like that is just an excuse for delay.
I feel strongly that the forgery problem has to be solved NOW, or at least we should start to try to solve it now. This is why I agree strongly with your proposal and why I like it so much.
We have a domain that was used for free email before (altavista.com) and even though we stopped the service, we still get hundreds of complaints of “Your user sent me this spam!” – all of them are forged. So I think it would be excellent to get RMX records in place, even if acceptance is not widespread, all it takes is a couple large receivers to adopt it and spammers will learn to avoid domains with RMX records. We really need something lightweight that senders can implement immediately and receivers can implement maybe not as quickly, but CAN do so if they want to.
Here are some comments about the proposal document.
6. Comments about recording information in headers and about From: header line
There should be a recommendation (not binding, but informative) that suggests to SMTP receivers how they should add useful information to their Received: lines. For example, if the Mail From domain is checked against RMX, this could be logged along with the IP received from, such as Received: from name (ip) (trusted sender for hotmail.com) or Received: from name (ip) (sender domain not checked, no rmx).
Also, if the Mail From: is different from the actual From: address, the Mail From needs to appear in the headers somewhere. Users will still continue to think that this mail is Really From the person in the From: address header. Give them something to go on, such as a warning in the headers if the From: header and Mail From: envelope info are different. Perhaps X-Authentication-Warning: Return address verified (jj@hotmail.com) but does not match From: address (jj@myhomedomain.com). (In reality I don’t see why the From: address and Mail From: address would be different, but for some servers they might be. The RMX proposal doesn’t mention the difference between From: and Mail From:. It would be a good idea to mention it, if only to say that it is beyond our scope but some other RFC should really specify when the two should be the same or when they are allowed to be different.
7. Enforcement policy
It might be interesting to include something like this (see following). It could be labelled “Possible stages in the reduction of forgery problems” or something like that. If you agree that this progression might be possible and would be desirable, feel free to take the text and use it, modify it or whatever.
1. RMX use is optional and infrequent. Domain owners of the often-forged domains will happily use it to decrease the misdirected spam complaints by a small, slowly increasing amount. Very few mail receivers will check records.
2. RMX checking by a few large receivers. Not all receivers will adopt RMX checking right away, but it doesn’t have to be adopted everywhere to start showing effectiveness. After a few larger mail recievers start to implement checking, spammers will start to avoid forging RMX domains and will shift their behavior to forge more non-RMX domains.
3. Spammers move toward forging new/different names. Spam complaints will start to refer to lack of RMX records. More ISP’s will start to get the message that RMX is important.
4. RMX setup information starts to become more available and integrated. Manuals, FAQs, etc. will have RMX information mentioned in the how-to for setting up your server, similar to how MX information is available today. As DNS info is updated and MX records are updated, and as servers are reinstalled and admins get more exposure to the info, more sites will have it. Most initial DNS setups and many that are getting an overhaul/update will get it.
5. Some receivers opt to refuse mail from non-RMX domains, especially universities and corporations that are not ISPs and that value security highly and don’t mind dealing with some bounced mail. Again, this does not need to be 100% adopted to start being effective — it will be similar to sites that use RBS-type checking now. If your domain is blocked to certain senders, there will be a handful of bounces and your own users will complain.
6. Blocking non-RMX domains becomes more popular as more sites roll it out. Users who no longer get forged mail at work or school will start to request blocking by their ISP, or vice versa.
8. Security Considerations
This entire chapter 8. and most of chapter 10. should probably be labelled as “Identification of problems that are outside the scope of this proposal” or at least should contain an introduction that says “This proposal does not solve all the problems that exist, but the presence of other problems should not stop us from presenting a solution to a subset of the known problems.” Most of the entries in 8.* could be shortened, if you feel that the weight of the problems and possible answers in 8. is distracting people from the key points of the proposal.
8.1.7. Reliability of Whois Entries
WHOIS and the reliability of the information (even availability of information or of the whois server) is a HUGE problem, but it should be stated pretty clearly that this is beyond the scope of this document. You might consider shortening this section so that it is enough to explain the problem and acknowledge that this proposal doesn’t solve it, but that it remains to be solved by another RFC.
(My personal feeling is that the current state of WHOIS is a joke, especially for country-code domains. I think that the information should be in DNS itself in the form of a TXT record or something similar, in both the named domains and in the in-addr.arpa domains. This should be required by an RFC the same way we require “postmaster@” to be deliverable in all domains. Eventually such a proposal might trigger the registrar to publish the info proactively like they publish the first layer of A and NS records now. But we certainly don’t want to hold up the RMX proposal to wait for the WHOIS/registry/lookup situation to get better — both problems must be solved so the presence of the second doesn’t mean we should delay fixing the first.)
Additionally, the WHOIS record might lead you to the ISP who is responsible, but it may also lead you to the spammer himself (who will just toss the complaint and possibly add you to his list.) So it is important to establish a chain of responsibility, from backbone to isp to customer, so that any domain that doesn’t obey the rules can be quickly reported to someone else who can either force them to behave or take away their access. This is also well beyond the scope of this proposal but is an important problem.
10.1. The economical problem
I am extremely happy to see a discussion of economy as it relates to spam. Extremely happy. This is so important, and yet “economy” gets lost as an issue because people are focused on Technology, Legislation, etc.
I feel that it is *vitally* important to turn the “Economy Of Spam” around on its head. There are a number of problems with the current email infrastructure and that those flaws are being exploited by spammers. All the factors add up to “it’s harder to catch spammers than to send spam”. More importantly, sending spam is profitable and cheap; catching spammers and filtering out spam is expensive and unrewarding. Reporting spam is difficult; reporting spam correctly is doubly difficult. (Compare this with advertising by postal mail – it happens, but it is a lot less frequent because most of the cost is borne by the sender. Spam is by its nature unethical because the cost burden is mainly on the recievers – and forged spam is doubly unethical because it incurs more expense for third parties not even involved in sending or receiving, just in order to delay being found out by some minutes or hours so they can send even more spam.)
It is important to stress that this proposal is *cheap* to implement, and is an excellent value considering the cost savings to ISPs and domain owners who choose to use it, *and* *especially* because it makes spamming more expensive and less profitable. This is so important that I would suggest putting it near the top of the document, in addition to having a more in-depth discussion in chapter 10.
Since spam is such a difficult problem, I don’t believe that any single solution will solve it. But, there may be several small solutions that are easier to implement than one difficult one. Methods that are cheap and simple to implement, and which make it more expensive and infeasible for spammers to do business as usual, are of great value and importance. Even if the solution is not the 100% technically superior, state-of-the-art science, shiny new model, who cares. This is important to mention, since this is something that many RFCs do not address and many IETF working groups may not be accustomed to thinking about.
About the huge anti-spam business, my personal feeling is that the Anti-Spam companies may profit from the problem existing and needing expensive solutions and frequent updates… BUT this is equally outweighed by the expense and trouble caused to businesses and individuals who have to deal with it (and pay for the solutions). The only thing slightly tipping the scales in favor of the end user is open-source free solutions such as Spam Assassin. Those companies selling Anti-Spam technology also have other products and will probably survive. Given that the RMX proposal doesn’t attempt to solve the entire spam problem, only to partially solve the forgery problem, I don’t expect much resistance from anti-spam companies.
10.2. POP “problem”
I would suggest to change the wording of this slightly. I don’t really feel that POP is the problem – I think the problem is that people want to send out directly to the internet wherever they are in seemingly “random” fashion. But at the same time they don’t want other folks to abuse their domain by sending out from random addresses, so the solution is to get the message back to an authorized sender in some trusted fashion. One possible solution to this is to expand POP to allow sending as well as receiving, but it could also be solved by telling the SMTP server that I normally use when I am home to recognize me when I am away.
If you have to get mail back to your normal SMTP server while you are roaming, there might be other ways to do this. One would be to VPN or somehow port-forward back to your home network, so that the SMTP server thinks you are coming from the local address, which would be based on some other password you use for the VPN or SSH port forward external to SMTP. Another idea is to open a POP session, keep it open while you are sending SMTP from that IP, then close the POP session… in this case it would require some way for SMTP to check what the POP server is doing. Next, there is the option of teaching the SMTP server to check your password somehow. And finally there is the suggestion I think you are proposing in 10.2, that the pop or imap procotols should be expanded to allow sending as well as receiving.
Most ISPs provide an SMTP server which will accept any outgoing mail from IP addresses considered “local” to their users. So, when visiting another network, if you don’t have the option of getting your mail back to your home network somehow, you can instead just use a more local SMTP server. This temporary sender would authenticate you some other way (like whose password you used for dialup, or who owns the static IP for the DSL you are sitting on) so when you change to another outgoing SMTP server, this would change your Mail-From address (or at least the sending mail server would record this info, even if it does let you spoof another address – perhaps the Mail From (envelope) and From: (header) address would be different in this case but it should be clear from looking at the headers who the owners of the sending machine’s netblock are.
10.3. The network structure problem
I have to say that I agree totally with the thoughts expressed here, but I disagree with the presentation and style. You used some words in this section that imply to the reader a sense of unprofessional, negligent, bad, irresponsible, possibly even malicious.
The problem is a real one, but I suggest a more neutral presentation. I would suggest to avoid using words like “failed” or “unable” and avoid saying that the structure is not “proper” or “good”.
The root of the problem is that there are multiple senders which may be (a) spread out among multiple networks and (b) have diverse management. Problem (a) is mostly the same problem as the POP problem — people want to send mail out from any IP, static or dynamic, wherever they are, but they want to prevent spammers from doing so. Fortunately most universities have static IP blocks, so they can pretty easily identify the whole range… they are responsible for the whole campus, so the whole campus can be on the RMX.
Problem (b) might mean that some machines on campus are controlled by different organizations, and there may not be one central manager for all of them. If the postmaster at the highest-level domain doesn’t want to accept responsibility for all the subdomains, then the subdomains probably should have their own RMX. That way postmaster@stanford.edu can be responsible for the main mail server and postmaster@cs.stanford.edu can be responsible for the CS department or some such.
It is worth noting that this is probably an issue with companies as well as universities–for example our company has a central relay in and several points where email can come out.
10.4. The mentality problem
I think this is pretty much a non-issue. Many users feel it is their “right” to do whatever they want with their bandwidth, but those users really need to read their contract again. No ISP wants to be seen as soft on spam.
Those who claim that sending email is their “right” and that this is a kind of “freedom of speech” are wrong, pretty clearly. Freedom of speech refers to your right to speak your mind, either in your home or in a public place, or using a public resource like radio waves. Freedom of speech does not obligate others to reproduce or relay your words. Reprinting or relaying something on a medium is called “Freedom of the Press” (referring to the printing press) and that freedom belongs to those who own the presses. So if a newspaper doesn’t print your letter to the editor, or if an ISP refuses to relay your email containing what is essentially a lie, they have the right to do so.
Also, freedom of speech does not absolve responsibility for harm or damage caused by your words. You can’t call in phony bomb threats or yell “FIRE” in a crowded auditorium, and if you do you will be held responsible. If you tell lies about someone you can be assigned to pay damages for slander or libel.
That’s a long way of saying I agree with you here. You may want to call it “Not a freedom of speech issue” rather than “The mentality problem” – this sidesteps the issue rather than challenges those who disagree with you. If someone believes it is their right to send mail using a forged address, that may be true, but it is also the right of the receiver to send back “570 Unauthorized sender” and it is the right of the ISP to terminate or refuse service to people who take “liberties” with their resources and their good name.
10.5. The identity problem
Again it is advisable to point out to readers that there is a problem here, but that solving it is beyond the scope of the proposal. The proposal is certainly not deficient because it doesn’t solve ALL problems… but a reader might get the feeling from reading all the problems NOT solved that a more drastic solution is in order. Make sure to stress that we are limiting our scope by choice, and that solving one problem at a time is better than waiting for a single solution that covers all problems.
“Identity” can refer to an individual or a company, usually. Most governments recognize “legal entities” as any entity eligible to own property.
What seems to be missing is the idea of “trust relationships” – for example, a domain name might belong to a person who abuses it or is negligent with it, but that person is allowed to use that resource by license (of domain registry) and by rent (of bandwidth and resources) so if they choose to hide their identity, then the ISP or perhaps the dns registrar must be held accountable by association (or be convinced to terminate the relationship). This is similar to hiding the identity of a minor – if you grant someone anonymity or if there is no obvious legal entity, then someone has to take the role of being the responsible adult and take responsibility for those actions.