Slashdot Mirror
The Anti-Spam Research Group's Plan for Spam
egoff writes "Speaking of standards, the ASRG, a member of the IETF, has a plan for "consent-based communications." Among the suggestions, according to Internet Week, are authentication services for falsified addresses, trusted senders, reputation systems (karma?), opt-out tools, best practices for challenge/response, and even a proposal for micropayments on unwanted mail. Instead of defining spam, the ASRG wants to provide administrators and users the tools necessary to avoid what they consider to be unwanted. One of the tools, Reverse MX, is expected to be in place in several months. It would allow the receiving mail server to query a domain to determine if the sending server is allowed to send on its behalf."
Great write-up on RMX, brought to you by the same guy who came up with an easy way to snapshot.
The RMX record can return any IP addresses that it wants, the receiving machine just does a DNS lookup on the originating address and makes sure that IP is authorized to send mail. Read the RFC for more details.
Isn't this what the reply-to field is for?
You could also run your own SMTP server, unless you're on a modem at home or something.
We already know who some of the spammers are. Heck, some of them have admitted it!
I keep submitting this link as a slashdot story. It keeps getting rejected. FFS guys, stop hassling one spammer at a time when they happen to make the news. Let's put pressure on the whole bunch. Start now, and keep it up until they stop spamming.
455fe10422ca29c4933f95052b792ab2
The original discussion on Nanog can be found here or perhaps here. He originally had the proposal on his site (dead link) but he seems to have taken the page down, and I don't see any reference to him contributing to this draft.
A valid point, however sshing to your box back in your country of origin and sending email from there is usually a valid option; that's what I do when I travel.
Reverse MX lookup wouldn't occur on the From: address (unless an admin is particularly stupid)
It would occur on the MAIL FROM command in SMTP. There's no reason I can think of to have the domain part be different from something on the same network as the SMTP server.
Your "home ISP", or more in particular, your "e-mail ISP" should provide you secure reception and sending of e-mail. That is, they should allow POP or IMAP over SSL to download mail, and use SMTP AUTH over SSL (either STARTTLS or smtps). That way you are always sending and receiving via your "e-mail isp".
The reason most people use "local" mail servers when they dial in is because lots of dial ins block outgoing to port 25 to stop spam. A band-aid on top of a band-aid. Use a secure, authenticated channel for your e-mail and you both add security to your own e-mail, and help stop spam.
The RMX approach is certainly very interesting. Although not based on DNS I had previously asked an AOL postmaster for similar information about what servers could legitimately send mail from any aol.com domains. That simple step has allowed me to block almost 100% of all spam reporting to come from joerandomuser@aol.com. I've been looking for similar information from the other big ISPs that spammers love to forge but with little luck.
Of course there may be a few things that this breaks (not that they shouldn't be fixed to work a different way). One is email intermediaries. SMTP was originally designed to be store and forward, and it used to be quite common that mail took many sometimes unpredictable hops along its way...direct end-to-end connections were not nearly as unbiqutious as they are now. But there still are cases where an SMTP intermediate hop may exist for legitimate reasons, but which may be unknown to the sender; thus they would not be listed in the RMX access list.
Another "questionable" practice that would be affected are services like monster.com, which send mail (usually resumes) to subscribers (companies hunting employees), but forge the sender address as being the real address of the individual, not of monster.com itself. Thus monster.com forges mail from almost any domain all the time; even though that mail can hardly be described as "spam" since the individual being forged has authorized monster to do it, and the recipient is paying monster to recieve them... But that kind of practice would still be affected without some workaround.
Oh, and if you want end-to-end authentication why don't more SMTP servers use the STARTTLS (aka SSL) mechanism with REAL certificates just like web servers do? If this became standard practice then it would be much easier to do SMTP server authentication with existing technology, and in a way that is completely transparent to the users (MTAs).No mention is made of legitimate uses that are also killed.
But that isn't a problem, either!
1) You can use an IMAP mail server. (which gives you lots of features, anyway)
2) You can use authenticated SMTP.
3) then, there's SMTP after POP.
4) You can use webmail thru your ISP (or on your mailserver)
5) You can have a "from" address and a "reply-to" address - they don't have to be different!
I mean, it's an inconvenience like open relays are an inconvenience!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I do like it as a partial solution (there aren't going to be any good total solutions in this affair). The benefits would probably accrue mainly to the big email services (Yahoo, Hotmail) whose domains are most often forged onto spam. Many people arbitrarily thow away mail purporting to come from there, which must be hurting them in some fashion. Since no one's going to reject mail on the basis of a missing RMX record, spammers will start forging mail from domains having no RMX records at all (or possibly a few serving 0.0.0.0/0 records). So probably not a strong benefit, but it'd help restore the viability of the major email services somewhat.
I do rather suspect that if RMX authentication were widely deployed we'll see DNS cache poisoning attacks come into vogue again. And if there's a set-in-stone system with an even larger deployed base than SMTP, it's DNS.
There are several good scenarios which depend upon the way the SMTP system works currently that will break as a result of a change like this.
:P
What do we do for the millions and millions of users who currently send mail via older software from their home system, tell them that they are screwed out of sending email? The beauty of SMTP is that it works. Assuming that this change is implemented, it will probably cause millions of users pain, and those users won't put up with it.
Once those users switch to a different email system, say for example, Microsoft Exchange. The damage to SMTP will be complete. Then again, what am I saying... I have stock in M$... Bring it on.
Seriously, though. Filtering is the responsibility of the client, not the server. Why do we need to impose new rules, which are just as easy to fake, rather than working on making the system work better for the user.
How much do you pay for email?
:
I can tell you how much I've paid for spam delivery
My "Junk Mail" Maildir folder is 42788 kbytes - it contains 4439 messages, dating back to 22/08/2001.
Data on my permanent modem connection via Tel$tra is 15c / Megabyte.
So it's cost me a total of $6.41, over the past two years or so.
4439 emails in 22 or so months is 200 per month. Seeing as my email address is a business address, I'd like it to be available to people, so ordinary "keep your email secret" advice is not really good. And as we all know, once you get those one or two bits of spam a month, it's only a matter of time before the deluge begins and you're getting "HOT TEEN FARM ANIMAL RAPE SEX!" and the like delivered daily.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
> So I send mail with my ISP account, but with the headers of my University account. If my University implemented a RMX record, I could no longer to that.
Untrue. This is not how RMX would work. If you send mail from home using your Uni email address, you change the "From: Kjella@uni.edu". However, the envelope sender (normally not displayed in email programs but an integral part of each email) would not be changed, no matter what email address you put as your from.
So the question becomes not if your Uni supports RMX, but if your ISP does. If it does, you only need to ensure the envelope sender is valid, and you'll be able to use any "From:" that you'd like.
I have one e-mail address I use, but travel all over and send e-mail from home. Until recently, I had no access to an authenticated mail server so I HAD to send using postfix on my home machine/laptop/etc. This is very useful to me, less so since AOL started blocking this behavior. Plus, as I understand it, it isn't so useful to spammers since sending all the mail from their own machine still incurs the wrath of their ISP.
As others have pointed out, though, this doesn't seem to be what RMX is used for. But, will I have to register with my ISP to be "allowed" to send mail? Fat chance I can find anyone who knows enough to do it, let alone a policy that will register me.
I think one of the main benefits, rather than stopping spam or even making it particularly more traceable, is reducing the amount of spam sent with forged return emails. Fact is, we know most spam is forged--the problem is our mail servers don't. Being the victim of some spammer who put your email address as the return address is a bummer and this would help reduce the effects of the undeliverable bounces. Potential receivers would do the reverse lookup, your system would state from the beginning "No, not authorized" and the mail would just be rejected without generating a bounce message back to the purported sender.
Actually, RMX does reduce the utility to spammers of compromised home machines. There is a nice discussion of this property here.
Then you just block that email because the RMX record lists too many valid IPs.
From the RMX document, chapter 7 (Enforcement policy)
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
There's no need to open holes in your relays,
use authentication, either SMTP-AUTH or POP-before-SMTP(nicely transparent to most mail clients).
anyway, is there a real reason not to use the corporate servers?