On Wed, 12 Jan 2005, Steven Champeon wrote:
In a sense, I am suggesting a similar reallocation of resources. Rather than put those resources into filtering spam, I'd suggest that we will get a better result by shifting the resources into mail relaying and managing mail peering agreements. The spam will continue but users will move to using the secure mail architecture and won't see most of it. When the spammers also shift, there will be more tools to track them down or shut them down or simply to rate limit them.
OK, sounds great. Let's start by making a few SHOULDs and MAYs into MUSTs.
Its nearly impossible to make MAY into MUST. You can do slow update from MAY to SHOULD and from SHOULD to MUST over period of several years but in that case you also need to provide exact date when old SHOULD would be depreciated and until then you can't assume its a MUST.
Some of the following could be accomplished in a few hours, Ha. You're kidding, right?
some are probably not fixable unless we can reallocate some of the trillions of hours we waste fighting spam to the problem AND get some political support for accomplishing them (such as fixing whois once and for all). Its being worked on and CRISP just released new whois standard (see below) The migration is however a very slow process.
Bear in mind that "fixing email" largely means "fixing all the other brokenness that allows people to take advantage of email's trust model". I'd actually advocate for slow change in email infrastructure model. But I'll not elaborate at this time, see you in 2 months about it.
So, then, it means fixing DNS conventions, abuse reporting support infrastructure (starting with whois), and broken mail server/client configurations.
0) for the love of God, Montresor, just block port 25 outbound already.
There are legitimate uses of port 25, the question is that you need to have it blocked for anauthenticated use. There are the following ways to accomodate situations when some users need to have unblocked por25 when majority do not: 1. Blocking port25 by default and allowing authenticated users who have requested it to have it unblocked. That should be done by means of radius profile and I believe can be done with existing tools (I have not been involved in dialup for 4 years now but from what I remember I could easily have specific user profiles with different redirection data for port25). 2. Not blocking port25 by default but measuring all traffic that passes through (by that I mean just number of SMTP packets from each ip, not actually looking inside the packets). If any ip shows highier then normal usage then its temporarily blocked and ISP immediatly tries to contact the user to verify what they are not spamming. A complimentary to this is verification that source IPs are the ones assigned by ISP and not spoofed or IPs routed through vpn from some other place (see recent threads about, last one by Ejay when his dialup was abused). Both of the above are ways are practical and can be implemented by ISPs given enough interest.
1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Corollary: any NONlegitimate mail source SHOULD be labeled as such (e.g., "1.2.3.4.dynamic.example.net" or "4.3.2.1.dhcp.resnet.foo.edu")
For UnifiedSPF I proposed before that special SPF record be published for the DNS hostname indicated by reverse dnsand that be checked to verify if it should or should not be source of email for that ip.
2) any legitimate mail source MUST HELO/EHLO with its own valid Internet hostname, not "foo.local" or "SHIZNITSONY26354" or "exchng1". Or, with their own bracketed IP. (Most do, many do not. There are very few valid reasons why not. Broken software should be fixed.)
RFC2821 says that HELO should be valid hostname, so a few things that do happen right now are already against it. A new SPF draft also includes checking HELO which will essentially accomplish this in practice. CSV group is also advocating the same with different record syntax. Again it would be slow process of migration from when we start using and have to discard badly configured named to when majority (and 99% of those sending email) have these records and we can begin to advocate for MUST.
3) any legitimate mail source MUST be in a domain with functioning abuse and postmaster mailboxes, which MUST also be listed in the whois db entry for both that domain and IP space corresponding to the mail source. (Not difficult to do at all.)
I beleive this is already in RFCs. Checking for this in real-time is somewhat impractical due to current whois system but we do have rfc-ignorant blacklist specifically for the reported bad whois domains.
4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. (NOTE: this will require fixing .org, among others whose public whois output is stale and not easily fixable via certain registrars). (Would probably take the most effort, but given a properly broad window of notification should be possible.)
This essentially require registrars to be able to immediatly tell if domain has valid address or not, what is valid in one country may not be valid in another. And phone## may be temporarily deactivated sometimes even at the request of the phone user. There are some ways to find certain cases of invalid whois automaticly and if registrars had any interest in spending any resources on this, they could have it done automaticly so that "-" is not a valid address in the first place, but majority of cases do require long process of verification and spammers only new domain active for couple days, so in practice this is not a solution.
5) whois data MUST be normalized and available in machine-readable form (such as a standard XML schema)
The protocol to provide whois data in standard XML format has been published couple days ago as IETF standard (proposed standard?). See http://www.ietf.org/rfc/rfc3981.txt http://www.ietf.org/rfc/rfc3982.txt http://www.ietf.org/rfc/rfc3983.txt
- the "I hate spam so I use a bogus contact addy" excuse will be obsolete, as email infrastructure will be secured, right? (Honestly, how hard would this be? Gather up all the now-extremely varied formats, compromise on a superset, and map. Then put it all on a Web site or a reliable, distributed infrastructure. I'm REALLY TIRED of getting "whois.$foo:111 connection refused" when I'm trying to track down a spammer's support network).
This is something for ICANN and I do believe that we should be compiling data on the registrars that do not provide whois in real-time when they should (per ICANN agreement) and have ways to report it to them so that some action could be taken by ICANN (an official warning with multiple ones leading to suspension of accreditation would do the trick with bad registrars). [compile data and provide it in public and to icann on non-answering whois servers added to my already very long to-do list]
6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.) All mail servers MUST support SMTP AUTH and the MSA port. (Some do.)
This is something that you can consider as being in process of migration. As usually its a slow process to have mail servers and mail clients updated.
7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) (Halve unemployment today. Retrain textile and manufacturing workers. Outsource the entire job. I don't care. Go read "broken windows theory".)
If ISPs hire (and retrain) all unemployed textile workers it will triple connection cost for legitimate users... That is not to say that I believe ISPs should not act on the spam reports or that its being done well right now - there are too many large ISPs that trim costs so much that their abuse departments are almost non-existant and there are of course those few ISPs who deliberately not act and provide connection to spammers (i.e. remember recently disclosed documents from SAVVIS that forced them to terminate more then 100 large spammers).
8) all mail server, antivirus, and antispam software MUST NOT accept and then bounce (to the usually forged sender) bogus "warnings" or DSNs. (A chicken/egg problem, really, but some systems have NO excuse - such as A/V systems that helpfully inform me that some virus that ALWAYS forges the sender did so in a message sent from a system I have no control over.)
No. The solution for this is to stop the forgery so that you do not receive the bounces for email you did not send in the first place. This is being worked on and there are several solutions and I commented on this quite recently, see http://www.mail-archive.com/nanog@merit.edu/msg28472.html
9) all mail servers and webmail systems, etc. MUST properly include tracking information in their Received: headers. (You might be surprised how many webmail systems and large ISPs fail this one. It's largely how 419/AFF scams are propogated.)
Yes, its a problem. BTW do you care if I include GMAIL in the list of those "large ISPs" that are not doing it right?
10) all HTML display engines MUST fix the bugs that allow for a link to say, 'phish.randomisp.net.br' appear as 'wamu.com' (Social engineering, but important in this day of hostile JPG images.)
How do you propose to fix this? Its perfectly valid HTML because link are specifically designed so that you can name them whatever you like for ease of user view. So lets say we begin to disallow URL name to be different URL, would it fix it? Not really, they will do minor conversion and provide name that looks like URL when its not or have the name constructed by javascript, etc. etc. Spammers do know how to get around all these simple fixes...
That should do it. I'd also ask that HTML email simply vanish, since I'm clearly already rubbing this lamp down to its bitter metal core... ;)
Your wish is not going to happen. You may not be reading email in html and I may not be doing it, but when I come to my brother's house or my parents they all do. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/