Slashdot Mirror
Spoofed From: Prevention
An anonymous reader writes "It looks like the next promising advance in the war on spam is here! Introducing SPF: Sender Permitted From. A draft RFC is still being written, but the idea is simple: we can prevent forged emails by having domain owners publish a list of IP addresses authorized to send mail from their domain. It's no silver bullet, but how much spam can we eliminate by preventing forged mail from spoofed domains? Maybe we really don't need anti-spam legislation after all? The SPF site is chock-full of juicy info for our reading enjoyment. Bon appetit!" Interestingly, the to-do list mentions the possibility of seeking a defensive patent on this scheme, too.
Good idea, but the problem is the same as saying spam would go away if all the open relays were taken offline. In theory, it works great, in practice, there are admins who WANT spam moving...
As far as I understood, unless everyone with a domain uses this, the spammers can just adjust their scripts/programs to just generate fake emails from domains without SPF. (or did I miss something?)
I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock. Thus we all need to pay just to run our mail domains, which is too expensive.
This is a BAD idea. What happens when I have 3 different email accounts that I use for different things, and I want to send mail from each of them from my home ISP? Sure, each email provider can provide a secure SMTP for me to log into, but this sounds like a lot of work.
This is going to make a LOT of people's lives worse, and spammers will get around it anyway. After all...they can still send from another username@theirisp.com. The accounts they're sent from are garbage anyway, because many people notify the proper abuse@ based on the headers (as they should) and not the From address. Forging the from doesn't provide any cover for spammers anyway.
if you wanted this to succeed -- otherwise, you'd end up blocking mail from those domains that hadn't upgraded yet to the new techology... What are the chances of everyone upgrading at the same time? And how much mail would be lost during the transition?
It's my understanding that when something is a hot-button issue with a lot of people, the lack of legislation against it leads a gigantic door open for legislation propogating it.
After I have received the wisdom of good teaching, I will untiringly teach all people. - The Teachings of Buddha
register with this. Will become a pain in the neck.
That seems like a really good idea. If the major MTA's adopted this and made it a part of the configuration files, then new installations would be easily configurable.
If the big email services such as Hotmail and Yahoo adopted it, spammers would suddenly find that they have to spend more effort to send out spam by finding domains that didn't opt to use these rules. Even so, it would be a lot easier to filter a specific domain in China or Nigeria than worrying about every piece of mail from Hotmail.
I moderate "-1, Fool"
http://www.tmda.net/
Working wonders here.
No more Micro$oft bashing from me. Its like bashing at the special olympics.
I have SPF 45. Your UV rays stand no chance against me.
Sincerely,
Letter
Perhaps this could stop spammers from spoofing the addresses of other internet users. However, I don't know if this will stop spammers from using whatever return address they want to regardless of what domain they send their spam from. Would it?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
How can this help with so many pink contracts?
Look at Bellsouth and OptIn.com for heaven's sake!
Any preoccupation with ideas of what is right or wrong in conduct shows an arrested intellectual development. (Wilde)
...should have their lower horn removed.
am considering taking out a defensive patent on this architecture for exactly one reason: I don't want to get sued for infringing someone else's patent, bogus or not. Patent it, then declare it public domain, and we sidestep a a quagmire of Intellectual Property issues. A patent will cost approx USD$10,000. If we can get ten major ISPs to contribute $1,000 each, we can jointly own the patent and guarantee there will be no legal liability. Contact me if you can help with this.
Only in America do you have to patent something to put it into the public domain. Shouldn't that be free?
SAILING MISHAP
All one needs to do to defeat these schemes is set up a relay host that spoofs the originating exchange.
STMP is inherently untrusted. You could simply claim that you don't accept relayed mail but wth, why even bother using STMP anymore if you do that..
int func(int a);
func((b += 3, b));
the problem with this is the following, most users are told to use their isp as the relay for outgoing mail. this would mean that if the users travels somewhere else where their relaying server is not in the list of ips, their email would be marked as spam and be trashed.
a solution like this would be all or none, either everyone uses it and follows those rules, or no one will use it.
besides you now have to get all the people who own domains to get a list of ips together, not the most trivial thing for non technical people.
So, that thing isn't gonna work for me.
In the Information Age that is.
The major concern of the legislators is that spamming will somehow contribute to the downfall of our f*&*ing civilization - that insists on polluting and clawing our way to the top no matter what the cost - and the loss of their control on power (you know, THE MAN.)
For some reason the technologists out there seem to think of these things a little too late.. this is an absolute natural.
My website blocks all but a certain few blocks of IPs - those of my friends, family and collegues that I know will be hitting the site on a regular basis. I just completed a system whereby it e-mails me the information of an IP address that attempts to access the site that is not on the list (auto whois (multi-layered), portscan, etc) so that i have two emails: one from my buddy vacationing in taiwan, and one from my system telling me i blocked his access from a computer owned by a taiwanese internet cafe.
I hate spam. This solution is much better than 'only allowing email from people on your contact list' such as my Microsoft Hotmail account allows.. a discussion for another day.
Where do I get the source?
|-|
That's being kind of short-sighted. Obviously not everyone would upgrade at the same time. If a domain didn't have a published list, then you simply would not be able to verify the sending IP, and could not filter based on this. As domains upgraded their mail software over time, this would become more useful.
And if Hotmail did it... well, just think how much spam uses spoofed hotmail addresses. It's not a permanent solution, but it's a useful stop-gap. It would be easy to implement for mail administrators, and make life for spammers a little harder.
I moderate "-1, Fool"
Like all the other final ultimate spam solutions, this one is broken. The designers assume that spammers will not have domains of their own - as we've observed, spammers have many domains, and $6.95 will hardly break them. They can register thousands of domains, set up perfectly legitimate SPF records on them, and forge mail from those domains. This scheme would slow spam down for about a week, after which spammers would all be using throwaway domains.
The answer is getting rid of the evil smtp protocol altogether and rethinking email.
Hey man, I love abusing my cable connection too, but since I'm not willing to pay $100 instead of the $40 I'm paying now, I don't expect being able to do everything I want to.
I hate spoofed from-fields just as vicerally. At least it fixes that.
Comment removed based on user account deletion
This seems WAY to complicated as an answer to a problem that's solved much better by PGP/GPG... Wouldn't it be smarter to get encryption and signing, a proven and implemented technology, merged into more email clients instead?
-3Suns
~~~~
The Revolution will be Slashdotted
It's no silver bullet, but how much spam can we eliminate by preventing forged mail from spoofed domains?
Probably not much; spammers would likely just find/use throwaway accounts with providers who don't mind the spam. Then again, that may make filtering out spammers easier, but as has been mentioned, everyone will have to implement it.
I'm waiting for that pending RFC.
However, I have two concerns, I can't obviously solve. First, how widely distributed is this, and how much load can it afford to take? Clearly somebody who has an interest in anti-spam utilities not working has taken to DDos'ing them off the net. I'd be concerned about this.
Second, how much "identity theft" will happen? It's relatively easy to steal a block of IP's or a domain name by faking headers/company stationary/company letter head. Actually authenticating the user is authorized to send from.
Ahhh, okay, I see, it's a DNS hack essentially. You set some txt into a DNS records.
I can see some issues with this. I send mail from all over the place, with my from address not from any given SMTP. I have from time to time been stuck on a college campus that won't allow me to send mail thru my SMTP host on the internet. However, it will let me send mail as them. However, I don't see how I can my foobar.com domain, so that it will allow mail to be sent from goofy_college.edu. It seems odd to me either way. Not sure if I like it or not. I wish it was "built from the ground up", not a hack onto a DNS server. It also means I have to VPN back to my home network to send mail, rather then use the handy SMTP, or run my own on my machine.
Kirby
Better patent it quickly, before a spammer sees this and sends the paperwork in. The braindead US patent office will grant it, and then how will anyone be able to disprove the patent wasn't the spammers idea?
If not, what are the key differences?
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
The only thing we're not doing now is forcing that mx is the "only" server, just that it's the incoming server.
Do you really need reason for beer? Wingman Brewers
This will only make e-mail in general worse. First, I'm pretty sure spammers will find a way around it, so it'll probably end up useless before it's even widely implemented. The worst however, is that it prevents important legitimate use of e-mail: always sending e-mail with the same "From:" field regardless of where you are. A couple more "great ideas" like that and e-mail will end up being useless because everything will be restricted for spam reasons.
Opus: the Swiss army knife of audio codec
but only a loosely working knowledge of the systems they're hoping to use to implement things...
"_" isn't a valid character to use in DNS.. sure many nameservers support it, but it's an RFC violation.
Wildcard DNS records aren't supported by all nameservers either....
Nice idea... when it first popped up with the DUL lists.. this is barely an expansion on that RBL-style list. Guess it's time for to patent this now!
How will making it easier to detect and to reject spoofed e-mail force more spoofing?
how to invest, a novice's guide
Simply, a federal law should be passed to disallow businesses from purchasing unsolicited email advertisement, which is the big chunk. You would still be allowed to send mail to previous customers, a la what Amazon does to make you aware of new products or services, but not to unknown parties. Those who break the law would be fined. Plain, simple.
A blog like any other.
get over bush's propaganda, you morons!
I remember reading about this system "back in the day" when it was just a gleam in some nerd's eye. It is a good idea, from the perspective of protecting YOUR OWN domain from being abused. Doesn't mean you still won't get spam that abuses other domains that don't use this technology.
As someone who hosts my sites from a dynamic IP address, I certainly hope this system can be dynamic-IP friendly... I would like to protect my own little domain as much as I can.
This is incorrect. RTFA. The SPF, and other designated sender systems, are all about preventing joe-jobs and forging of the mail-from addresses. (and no, not all forged mail-froms are joe-jobs, theyare not the same thing.)
SPF support for most open source mail servers can be found at libspf2.
So that note to re-enter my credit card number WASN'T from ebay?
Oh, shi...
Hate to see what Hotmails DNS will look like with a few million: 1.7.168.192.in-addr._smtp_client.hotmail.com. TXT "spf=allow"
entries in it . . .
Your hair look like poop, Bob! - Wanker.
One problem I see is one that I would run into. I have a domain somethingblah.com I use my ISP's mail server to send mail out, but I send it out from myself@somethingblah.com. This would result in all this e-mail being rejected... yes?
This type of approach doesn't sound totally rubbish - but I'd be happier if ISP's would ALL impliment anti-spoofing filters on their routers as in RFC2827.
It'll just force all spam to be joe jobs.
You have it exactly backwards.. this will *prevent* all joe jobs. You have SPF records for your domain, then anyone who sends mail as your domain will be rejected, because it's not coming from your SPF-listed servers. It doesn't prevent non-spoofed-domain spam, true. But it's a step in the right direction.
The SPF RFC includes an extension to RFC2822 reserving the Received-SPF header.
I Propose an extension to RFC2822 which reserves the Evil-Bit-Set header . . . . it'll solve the problem in an alot easier way.
For anything that I can't trust I simply use my @activatormail.com . The free version allows 50 messanges or 1 Meg, whatever comes first.
ActivatorMail
Retraction: I did not RTFA...
:(
I was completely wrong
I am disrespectful to dirt! Can you see that I am serious?!
One of the ways they do this is by providing inbound and outbound email services, through legitimate servers published through DNS. As a customer of the ISP, you're given rights to use those services, and they're responsible for ensuring your access to same -- that is, they're the responsible party for any given email address at their domain name(s).
You wish to configure your home mail server to appear as a legitimate server for outbound mail coming from another party's domain name(s); as a customer and not an administrator, I don't understand your presumption that you have a right to do so.
This is one of the key points of SPF that is going to start a lot of debate: if you purchase an email address from a provider other than yourself, you are not responsible for the outgoing mail servers for that address. Setting up and running your own mail server does not change this situation; there is no software you can run that will make your personal server the responsible party for someone else's domain name.
Since you're already running mail services, it's just a short step away to activate DNS services, available at no cost to you on virtually any platform that your own mail server will run on.
I currently host my domain with Domain Discover, at $35 a year; there's registration servers out there for as cheap as $7 a year. My $35/year domain is cheaper than a $5/month ($60/year) email account with a local Internet provider.
The primary purpose of SPF is to provide a positive authentication check for messages, to confirm that they have been sent through the outgoing mail server listed as a responsible party for the email address in question. It is inconceivable to me that any provider would bestow upon end-users the power to be a responsible party; partners, perhaps, but not individuals. While exceptions may occur, I don't feel that your situation should be one of them.
There is no central registry. Each domain's own DNS servers detail which servers are allowed to send mail on the domain's behalf.
Fully distributed, fully *free*.
Well, if I understood right, before the mail gets accepted, a query is run from the DNS server. I would assume that if they did DDoS a DNS server, no mail would go through. Kinda sure that would qualify as a felony. And then websites would start disappearing off the net.
> Second, how much "identity theft" will happen? It's relatively easy to steal a block of IP's or a domain name by faking headers/company stationary/company letter head. Actually authenticating the user is authorized to send from.
Stealing a block of IP's by forging documents should definately count as a felony. Computer crime, forgery, theft. I really don't think that even spammers are that stupid. If they are, they won't be for long.
Stop the Slashdot effect! Don't read the articles!
implement DNSSEC extentions and this new method, and I think we got a good deal going on.
Get the patent, then start licensing it. Get a lawyer to write up a contract that says if you use this system, you agree not to send more than x amount of emails, not spam, etc. Require everyone who uses the scheme to sign it (PGP/GPG) and then when spammers sign the contract and spam anyway:
PROFIT!!!
Yes, having information on which SMTP servers are the expected and typical mail "emitters" for a given domain would help reduce (not eliminate) spam.
But the number of cases where users "forge" their from lines for perfectly innocent reasons is huge. Everyone here can probably think of a few cases. Here's one to get you started: "I'm working from home today about I don't want replies to my business email sent to my home account."
Of course, they've covered that in their FAQ. Their answer boils down to: "Tough noogies. You have to suffer the inconvenience and change your behavior because I don't want to suffer the inconvenience of spam."
This, alas, it typical of the disdainful, anti-user mentality that one finds in too many anti-spam efforts.
Here's a clue: want an anti-spam solution to work? Then start from the idea that it needs to make the life of the end user easier, not harder.
Of course, I'm biased. See my sig.
This still has the problem with mail relays and hosts not visable on the internet, just listing the IP address of good hosts isn't really good enough, IPs can be spoofed too. Servers need there own public/private key, every message they send on behalf of a domain is then signed with that key, relays don't touch the signing, but can still transfer the message, at the other end the signature is checked against the valid keys for that domain (which could be stored in the DNS or some other method). If the message is tampered with the signature will not match the body of the message. If your server gets its key stolen, you can just generate another one. The main problem is, lots of people produces mail server software, getting them all on board is a problem, which is why people suggest lame ideas like using just the IP, spam will only be defeated when we "replace" SMTP, I say replace, because an Improved SMTP could use many of the features, but if it supports a legacy SMTP server that one could be used to abuse the whole system.
James
If your provider is responsible for an email address, then they must provide you with a reasonable means of using their service to send mail, either by POP-validated SMTP or by authenticated SMTP.
If you're responsible for an email address, then you have no excuse whatsoever not to be using authenticated SMTP. Repair your outgoing mail server immediately.
From www.nuclearelephant.com/projects/dspam
Of course, it requires a tiny amount of effort on the user's part, so maybe it's not a universal solution in our world of the congenitally, terminally lazy and complacent. But for those who can be bothered to use it, DSPAM more or less permanently ends the spam problem.
Yes, this measure, by itself, will not remove all spam from the face of the Earth.
Yes, this measure will operate to make e-mail somewhat less convenient and require authenticated SMTP servers and the like.
But YES, Spam is awful and a serious problem, and if we wait for the silver bullet, we will accomplishn nothing ever at all.
We need to take steps, a few at a time, that will help, a bit. Steps, a few a t a time, that will help a bit, even if it means some inconvenience.
Eventually, the problem will be better.
Eventually,m the problem will be much better.
And maybe, the dollars will start moving to other ways to annoy us.
I would be happier if he GPL'ed it.
Actually, that brings something important to mind: Here in Australia a very large proportion of mail servers are Debian boxes. If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.
Read the website. Everyone will *not* have to do it. Only those domain owners that want to restrict who is allowed to send email using their domains will have to add SPF DNS entries. Only those people who want to obey the requests of domain owners will have to check the SPF DNS entries.
SPF support for most open source mail servers can be found at libspf2.
What about all the web hosting companies that suggest you use your isp's outgoing mail server for all your sending mail needs, even for accounts they provide? And what of the people who do their mail off of a dynamically allocated IP, such as from a DSL or Cable line.
This assumes that all mail from a domain comes and goes from a central point of authority, but because of smtp's untrusted nature by design, people don't need to operate along those principles.
The one way for this to work is for all of those dsl and cable modem mail servers to go away, and all pop3 accounts also have to provide their users with the ability to send mail from the same, or a server with the same authority ion command. But if that were the case, it would probably be because smtp was designed with trust in mind. Since it wasn't this cannot work without fubar'ing a whole hell of a lot.
Not worth it. Just replace smtp, it neeed to be doen years ago, so about a decade from now.... maybe.
--Nuintari
slashdot : where an opinion can be wrong.
So you assume that businesses will rat out their customers? Or, there will be snitching somewhere within? That doesn't make a damn bit of sense.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
From the SPF Page
"I have someone coming from a certain IP address. They claim to be a certain sender. Are they for real?"
This at the top of the explanation page, and as far as I can tell, is already broken. This is because it assumes that you can tell where a message is coming from. This is true if the sender wants you to know where it's coming from. However, IP address spoofing is quite easy. Simply put an IP address other than your own in the source field of an IP packet header. In this case, you'd use an IP address that was on the "permitted" list.
The views expressed are mine own and do not express the views of my employer.
I've seriously considered beginning to strictly use webmail. Or, failing that, one could always ssh into a trusted server and send mail from there.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
probably a check for helping spam.
If spam goes away, it'll be as devastating as an asteroid hitting Earth. Jobs will be lost, and America will become a third world nation. Didn't we cover this earlier today?
You can't judge a book by the way it wears its hair.
And assuming one were to piggy back it on DNS or some existing service, how would something like Verisign sitefinder fuck it up?
It is piggybacked on DNS, and it's done through TXT records that specify either "spf=allow" or "spf=deny". A confusion of A vs. NXDOMAIN, such as if VeriSign goes meddling again, seems not to affect the system.
Will I retire or break 10K?
If mail can be decrypted with the public key, it was encrypted with the private key, hence not spoofed. If mail was not encrypted at all bounce it, explaining why.
Every mail server admin defines a list of people whom he trusts (those might also be institutions), and they delegate their trust further, with different levels.
If spam appears, you kick the trusted person who is the first in the chain to the spammer from your side. He does the same, until the chain breaks ... the last one in the chain revokes his key, and that's it.
Needless to say: You don't accept mail from people which you have no trust chain back to.
I suggest that everyone read You Might Be An Anti-Spam Kook If... and count the number of relevant items. I stopped counting after a few.
Bah!
.sig
Bah! I say.
This is a piss poor substitute for digitally signing your email,
with the added disadvantage that there isn't even a finished draft of a spec.
Maybe it will be the cat's meow, but right now it's just so much hype.
At least DMP has a draft (four drafts actually).
I fully expect PGP signed emails to catch on before this does.
-- this is not a
Wouldn't it be better to implement something in DNS that sets the ips to be used....Maybe call it an RX record put it in for the @ record of your domain. @ RX 127.0.0.1-254 RX .....
CRX smtp.someotherdomain.com.
That way you can just poll bob.com and ask bob is whatever-dsl-address.goofyisp.com can really send mail as amazon.com or not. This is more extensible to people who have home-grown servers, as well as big companies. I mean, who doesn't know the outbound servers for their own domain?
You could even couple this with some other check that looks up originating IPs and does a query back to the domain to see if they can send (as suggested in the above article).
Get your own domain and have catch-all e-mail.
Generate e-mail adresses to send to, in a way it's hard to guess a valid address.
Put it and all information about it in a database.
Use that for smart filtering.
This way you can even pinpoint who spammed you, if so and let authorities handle it.
Don't put a address on the web that a machine can pick off, make it only human readable. Don't show e-mail adressen on newsgroups.
Just put the URL of your site in, so people can find you there and POST a message to you via a form and even ask for a new generated e-mail address.
But what about spoofing? I haven't figured that out yet. But if everybody makes it as hard on spammers as written above, it's a more difficult life for the spammer, so there will be less spoofing to
Am I the only person that remembers an idea generated by some anti-spam commissioned think tank, which came up with the idea of putting reverse MX records into zone files?
Basically, this approach would allow one to specify a list of domains that were allowed to relay mail. For example, Mail Service A would add an RMX record that specified mailA.com Then, whenever email was delivered to Mail Service B that claimed to be from @mailA.com, B would check the RMX record to confirm that the delivering server resolved to a domain that did in fact have permission to deliver email for mailA.com.
Elegant, efficient, and perfectly reverse-compatible (no RMX listing would allow anyone to relay email for that domain). And this would pretty much wipe out forged domains on email. Why has this not become a standard?
As just a test of the possible efficiency of such an approach, I worked at Shadango.com for awhile and we tested out the option of rejecting mail if it wasn't coming from the domain that the email claimed on the "from" line. You'd be COMPLETELY blown away at the effectiveness of this. I believe Shadango is currently testing it again on their production servers, and I have only seen a handful of outlying cases when email ends up getting rejected. Seriously.. so anyone that doesn't believe how effective this can be, go sign up for a Shadango account (it's free) and see for yourself how much spam just disappears.
I really think this is the solution to spam.. force all of the spammers into the light by making them honest in their email headers.
-Alan Steele
Spammers can use this SPF vulnerability. The way SPF works when the sender address is empty, that is, <>, which normally is used for bounce messages, the receiving client that is using SPF checking will use the HELO/EHLO name instead of the SENDER domain name. If the spammer is making the connection, including through an open proxy, he controls the HELO/EHLO name. The problem is that the HELO/EHLO name lookup involves the name of the mail server, and uses a different hierarchy of the domain owner's name space. The spammer can forge any name the owner has not configured. For example he can make the HELO name be "fantastic-offers-just-for-you.aol.com" and the SPF-aware server receiving the mail will look up "xxx.xxx.xxx.xxx.in-addr._smtp_client.fantastic-of fers-just-for-you.aol.com" [warning: slashdot will insert a space in that long string to avoid messed up formatting] for the TXT record. The wildcard deny at "*._smtp_client.aol.com" won't match the query because that's a different branch in the hierarchy. And any wildcards for real existing mail servers at aol.com won't have this spammer name, and they, too, won't match. There being no TXT record answered, your server then has to take the default action, which will usually be to go ahead and accept the mail since it might have been coming from a domain that doesn't implement SPF (yet).
If you choose to block sender <> in your mail server to avoid this kind of spam tactic, you also break the ability to receive bounce messages.
There needs to be some way to indicate at the principle domain level, e.g. at "aol.com" in the examples shown, without the "_smtp_client" subdomain, that SPF is indeed implemented. But adding a wildcard record there messes up lots of stuff. One way around this would be for SPF-aware mail servers receiving mail to perform the SPF lookup on every parent level of the domain involved (especially the HELO/EHLO one) to see if there is a TXT record with an SPF setting present. That would mean lots of extra DNS queries.
now we need to go OSS in diesel cars
Here's another idea, what if ISP's charged by the piece for commercial email solicitations to be sent? I mean as a home user I am not allowed to run a web server. mail server, or ftp server. If I wish to do such things for commercial purposes I would need to pay for a commercial hookup. So, if the isp's were to charge even a few pennies per piece for solicitations to be sent via email (requiring a whole different class of metered account for the purpose) how long do you suppose it would take for spammers to realize that allowing people a legitimate opt out, remove me from your list option would be very financially benificial!
Spam is so predominant because it is completely free!!!
The Matrix is real... but I'm only visiting!
Look, if we could convince every sysadmin on the planet to upgrade their MTA's, we could just implement HashCash and be done with it. And this guy wants us to concurrently update all our DNS maps?
Oh no! Some botox, typically used for cosmetic paralysis of facial wrinkle zones... I guess the US is an even bigger terrorist nation. Particularly California.
Your trolls suck ass as always, FTM. You can't even hold a candle to Vlad, and he likewise fails it.
All of those are great mail servers for my needs, I don't need more than 1 IP with a good nat, I used to have a class C but I gave it up when I realised I didn't need it I stopped having it routed.
We don't need the bandwidth you have, nor do we pay for it - but where do you get off trying to tell us what we can put in our packet headers just because how much money we have?
Can't fix all the problems in the world.
Anyway, its just a matter of spreading the "good neighbor policy" to fix spoofing.
In an ideal world, each router would be configured with ingress filters that would drop packets arriving from "internal" networks whose source address was not a member of the set of network addresses that this router serves. The majority of routers could be so configured. Backbone routers and edge routers for complex topologies probably could not be configured with such filters. These ingress filters should be required as part of a "good neighbor policy." Ingress filters would not totally eliminate denial of service attacks but could greatly reduce such attacks. An attacker could still spoof an address within a local subnet, but that would permit backtracking the packets to the source subnet. Cisco's unicast reverse path forwarding also can be used to block spoofed packets at edge routers.
http://www.csm.ornl.gov/~dunigan/oci/bktrk.html
A few hundred bytes would be sent from the originating mail server identifying who they were and the properties of the message, the server on the other end would take that and perform some mathematical operation on it (pseudo-random number generator or something) and send it to the specified return address, then the outgoing mail server would attach that code to the body of the message and send it back. When the message was finally received, it could be verified and the authentication code removed from the system -- no using old codes or a bunch of messages with the same code.
The originating code could include the CRC, originating IP address, title/subject, date/time, and message size, in addition to the return address -- probably a few hundred bytes out of thousands or tens of thousands of bytes in most emails. This would increase the load on the mail server on the front end but since the server could then filter out some messages before they are even sent -- if they are too large, if the date is incorrect or out of bounds, if the return address or title brings up a warning flag for spam, viruses, or blocked senders -- it might actually decrease overall net traffic.
Or you might go still farther, and not even send the identification code until the recipient gave the go-ahead -- you would receive a list of messages plus the message properties (date/time/return address/title/etc), and the authentication code would be sent when the message was opened. If someone were attempting to spam, they would have to have a valid return address open for at least several hours -- if they spoofed a return address, they couldn't find the response code, and if they shut down their mailbox their spam couldn't be delivered. This would increase the time it takes to open some messages, and others might not be deliverable, but on the plus side spam would probably not fill up your inbox and bounce wanted emails.
Possibly, the system could require authentication all the way back to the message originator, but that implies some central repository of mail originator credentials (again, to allow for transient connections), which would have to be is-a-person credentials to be of any use in tracking and punishing spammers. Since TANSTAAFL, that means to send mail, you have to buy an admission pass for the network. That implies an infrastructure to issue and validate these credentials, as well as no provisions for unlinked mail nyms. Big Brother USPS, anyone?
Mail? Put "slashdot" in the subject to pass the spam filters.
toynbee idea
in movie '2001
resurrect dead
on planet jupiter
This could do wonders... One of the ways that the latest email viruses/worms have been so effective, is that they tend now to randomly spoof the from lines after mining valid emails so that its harder to figure out *who* it is that is sending you the infected email.... If this system were globally in place, email worms like sobig and blaster would have never gotten as big as they did, so easily...
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms,
This discriminates against new companies seeking to get the word out about their hot new products. Old companies with established business relationships would be given a permanent edge over new upstart competitors.
FreeSpeech.org
.. doesn't work. What needs to happen is ISP need to start using better spam filters. Personlly I want to be able to create my own custom server filters to filter out mail before I check it. Earthlink is using something like this now, but it only has a 'authorized sender list' not any kind of filter. I really don't want potential employeers to have to deal with earthlinks spam combobulator sending them a message saying that they need to reply to this new email to contact me. I do however want to filter software on the server. My current filters catch about 60% of my spam and then the second one catches about 35% more so I only have to deal with about 5% of my spam.
Only 'flamers' flame!
Does slashdot hate my posts?
Web sites on vanity domains are just the sort of thing people like to deface. But how to go about it? Usually there's so little chance that the owner of such a domain is going to be suckered by a mail bomb. Hmm.. what's this SPF record? Seems to point to the network where the owner of this domain connects up to.. that's useful.
How we know is more important than what we know.
A little slow today? I believe "From:" in the article title should be in quotes.
You replied, didn't you?
-ringbarer
That the system will tell you when a message is from a non-verified domain is not the interesting part - the interesting part is that you know when an email has come from an IP associated with its purported domain.
So you can reduce your tolerance for things that look like spam while not affecting email that's source-verified.
And it's easier than making everyone use PGP.
paintball
It turns out that their admins can't (figure out how to) whitelist a single IP address.
Personally, I'd go with assymetric crypto rather than an allow list to prevent users from spamming from unpriviledged shell accounts. An allow list is a start, and ISPs such as (those bastards at) AOL should be allowing mail from any system that has an MX entry on its domain, provided that domain hasn't been blacklisted (for legitimate reasons).
You can't judge a book by the way it wears its hair.
from what i see into this, it is the notion of a white-list, which is advertised to the world. I duno, but I kinda like ot keep my white-list private if that is ok with you? Anyhoo... what about huge address spaces? I could be using ip6 one day, and how well would this scale up to something huge like that in years to come? Especially the large scale sites like hotmail, aol, yahoo, etc.. where users send email to all over the world.
It isn't a lie if you belive it.
The FAQ says...
To which I can only add:
Or is there something I'm missing here?File under 'M' for 'Manic ranting'
I know lots of people who have domains hosted, because they use cable and DSL. I doubht hosting services are going to allow people to send email through them, and MY ISP wont add my domain to his approved email list. I could use reply-to addresses, but people still seem to get reply-to messed up, so I tend to avoid that.
So, I have a local linux box, that runs postfix, that sends out email for me. Nobody uses it but me. This means I will get cut off from sending email (if I used a Cable, they would block me also)...
Its not like we dont know who is sending spam. Its all traceable, and the large ISP's could just get together and report the spammers to an RBL and block 90% of the spam. Which is also what every RBL says, "Soon as 1 large ISP starts using us..."
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
1- Enforce the validity of the From: field. I don't have a clear idea of how to achive this but it is clear that the main default of the mail protocols is that the From: field can be so easily spoofed.
2- Make everyone build a list of trusted domain.
3- Add a bayesian filter to clients.
He mentions the Travelling Mailman problem, that of being able to use your home e-mail address while not on your home network. His solution, having your home mailserver use authentication so that you always send via it, has it's own problem. The problem is Windows malware that e-mails itself out. Several large ISPs have responded to this by prohibiting the use of any mailserver but their own from inside their network. This puts me in a quandry: I wouldn't be able to use my domain while on my ISP's (Cox Cable) network because SPF would reject it, and I can't use my domain's mailserver because my ISP won't let me connect to it. This is, IMHO, a fatal flaw in the scheme.
I can't wait to see this published by the GTLD servers:
*.com. IN TXT "spf=deny"
*.net. IN TXT "spf=deny"
-ez
Doesn't the problem go away if we authenticate reply-to on all email from the server, and, isn't there already an unimplemented proposal to do this already?
Like, this is a problem that is already solved at least on paper, we just need major mail makers to do it...
Finally, doesn't IPV6 also solve this problem because you have MAC address buried in the IP?
This is my sig.
This is exactly the unhelpful attitude I was talking about. Thank you for that perfect demonstration.
Of course someone can change their reply-to address. But the question is not what users should do. It's what they actually do that matters.
At Messagefire, we've built an anti-spam system that works by detecting lies (forged information) in message headers.
Forging the From: address is a common practice, even among innocent users. Looking for this kind of forgery alone is not a very good spam detection method.
... so why wouldn't it be as dynamic IP friendly as whatever DNS updating system you use now?
Just need to hack in support to publish correct records.
won't work anyway... not like anti-telemarketer legislation... the telemarketers actually have to call you one on one.. they're only slightly less cowardly than a spammer.
part of that is because you can't yell "bite me!" back at the spammers through the phone.
I feel for ya, I suck at telling jokes too.
I think this actually makes things better for you. Right now many DSL addresses are blacklisted, because they are major sources of spam. With this system, you can set up the name server from your domain to say that your DSL IP address is a valid relay for your domain, and then it should just work.
Cubs? Braves? NLCS?
Yes. Really. It *IS* authorized.
They specifically ALLOW servers with my ISP.
If my server is to cause a problem - e.g. open relay - THEN they will stop me, but until then, it's fine. I repeat, they allow me to run servers. It is not a break of their ToS.
They don't provide any tech support for those that choose to run their own servers, but they do specifically allow those that wish to, to do so.
This is one of the reasons I chose my ISP.
Please stop making assumptions about everyone.
Simple solution:
:)
fallback_relay=your.isp.mailserver
That's about it for Postfix, and I'd guess that it is no more difficult for any other MTA.
If you don't have an ISP that can handle that, pony up a few more bucks and keep your freedom. There just ain't no free rides any more
I use bway.net in NYC, and they are a dream for such things.
gotcha - I didn't look at the research groups (never have actually - looks like good stuff there) The anti-spam research group should have more promanence on pobox's site
...something that can already be done with Postfix and other mailers. It's very simple. Postfix can check to see if the hostname you claim to be from matches your IP. It can also check to see if the IP reverses to the hostname you claimed(this one is not as wise, as there are perfectly valid reasons for not having a reverse entry, although you -should- have one). Further, Postfix can return not-authorized if you try and give a MAIL FROM address which doesn't match your domain; ie, if you're coming from a01.nastyspammer.com, you're not going to be able to say "MAIL FROM: niceguy@yahoo.com". It is -incredibly- effective against blocking spam, but the problem is that many ISPs and company just don't have properly configured mail servers, or hostnames set up for their mail servers(an even more common mistake is for the hostname to not match the name reported by the connecting server in the HELO command- most often Exchange servers). This would change quickly if more people configured their mail servers to block such shenanigans.
Right now that RFC seems a)unnecessary and b)like a very thinly veiled attempt by ISPs to prevent their customers from running mailing lists and the like. I help run a VERY low budget mailing list that has about 3,000 subscribers in total, and we may end up using DSL again for connectivity. Said DSL provider could easily screw us over with this.
Please help metamoderate.
It doesn't have to match. The only thing required is that the domain of your Sender: field list your ISP's SMTP server as an authorized sender. At least that's how I read things.
That's a very good point, and something that many administrators have been discovering in association with open wireless networks: direct outbound port 25 results in spammers having a field day with the bandwidth.
The usual cure I've seen these days is to use the authenticated (and, sometimes, SSL-encrypted) SMTP services on port 465. This works around the firewall problems and makes things a lot saner to deal with -- as well as keeping spammers from using public SMTP servers.
Now, if someone sets up a rogue SMTP server doing open relay on port 465, there's problems once more; however, requiring the authentication before a message can be sent (regardless of relay whitelists) makes this remarkably less feasible -- as well as adding a layer of identification to the Received: line of each email that is sent.
As long as this is NOT queriable, we may have something.
In short, spammers should NOTbe able to query what vlaig entries should be.
Spammers find wayhs around protection, we should be paranoid and put up barriers to prevent what might be possible.
- Zav - Imagine a Beowulf cluster of insensitive clods...
The outgoing mail servers for your email address are not your responsibility; they are the responsibility of your upstream. You are not the responsible party for those mail servers, and thus your personal mail server, authorized or not, may not speak authoritatively for someone else's domain name -- even if you're using an email address on that domain.
Shut up man. No one likes you. You are worthless. Go kill yourself.
And watch ISPs charge prohibitively for SMTP AUTH access from outside the network.
Will I retire or break 10K?
Here's a clue: want an anti-spam solution to work? Then start from the idea that it needs to make the life of the end user easier, not harder.
How could their life be easier? There is no accountability, and hence no burden in the current system. Anything we could possibly do would add complexity. Even the system your firm offers is a level of complexity... its not seen by the end user because they (a) pay you (b) permit somebody else to rifle through all their mail.
I was attracted to SPF less so for its spam prevention abilities than for its ability to communicate what servers I trust to send mail in my domain's name. And I think this will be the driving force behind its adoption. ISPs are already very interested in a system like this, as anyone that receives the blowback of forged spam would be. Its a matter of protecting one's identity.
It would probably cost well over $100,000 to move to a part of the United States served by a major residential high-speed Internet access provider with such a liberal use policy.
Where do you live?
Will I retire or break 10K?
It's trivial to forge the source address of packets. You can even talk to remote computers this way if you can predict their ISN's and you don't care that replies won't get routed back to you. SMTP is a simple enough protocol that spammers could assume what the replies are and thus send mail from a faked address, something like... Connect to port 25 (Assume response was a ready message) helo somename (Assume some response) mail from fake@domain.com (Assume response is "Sender ok") rcpt to: somebody@somewhere.com (Assume response is "Recipient ok") ...
So it seems the problem would just be changed to "are your sequence numbers predictable enough for a spammer to fake a TCP handshake on port 25"?
But why would my email provider's domain authorize my ISP's SMTP server? They are two entirely different entities, each on entire separate domains.
File under 'M' for 'Manic ranting'
this could also help spammers. say a company publishes a list under this new recommendation. suppose their mail server is unsecured agains third party relaying. now the spammer has a list of valid domains they can use to bounce through the mail server. lets hope anyone smart enough to use this is also smart enough to secure their mail server.
Oh shit! I forgot to click "Post Anonymously"...
as I can see it.
The *DSL user that has bought a domain foo.bar that is hosted on a server, somewhere in the world (that doesn't allow mail relaying). And this user want to send mail that originates from the foo.bar domain.
Ehhh.. that user is screwed by this.
And patent? Well, that will be very good for making it a technique that every MTA will use.... releasing it as Public Domain? Remember Rambus?
Evolution of Language Through The Ages: 6000 BC : ungh, grrf, booga 2000 AD : grep, awk, sed
As open relays become increasingly rare spammers are looking to infect your computer with a virus or trojan and have YOU send their spam. You are authorized to send e-mail to whoever you want through your ISP's mail server, right? The success of spammers in taking out anti-spam sites lately by DoS attacks shows how sucessful they already are at getting other people's computers to do their bidding.
My attempt at a translation: If a spammer registers a throwaway domain and begins to spam with it, then automated anti-spam systems will discover an unusually large amount of spam coming from the domain and quickly add the domain to lists of known spammer domains.
Will I retire or break 10K?
$ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 207.8.214.4 umbrella.listbox.com
...
fail
client umbrella.listbox.com[207.8.214.4] is not a designated mailer for domain of sender umbrella.listbox.com
So apparently these guys don't have their own mailing list system set up to use their protocol properly? Or am I using their tool wrong? (I'm pretty much just typing in what the README gives).
that would qualify as a felony
It's not illegal if you don't get caught, and it's not illegal if you do it offshore.
Will I retire or break 10K?
So now I (Joe Spammer) connect to your SMTP server and deliver you some SPAM dressed up as a helpful undeliverable notification (i.e. a bounce).
From the site:
Will I retire or break 10K?
This is just a weak try. What it actually does is to move the weak spot of SMTP to another level, kinda out of SMTP down to IP.
This whole principle will not help to reduce spam, it will even increase it: the "noise" in the DNS system, the exchange of valid IP addresses, etc.
Plus: IP spoofing is not that hard. With this protocol at hand, just ask some mail servers for some valid IPs, and then build your own mail server with that IP.
Thank you very much, now I do not even have the means of spoofed headers to proof it wasn't me.
and years and years and years.. welcome to 1994.
How we know is more important than what we know.
RTFC
Perhaps it could say DATA/If you receive this, your email server has been misconfigured./Please ask your system administrator or ISP to configure the server to discard incomplete email messages.// -pause- disconnect.
That won't get them all, and there will be the odd false positive (550 unable to validate sender address), but it should get most, no worries. It'll certainly get the zillion or so messages spoofed as being from "@hotmail.com" "@yahoo.com" and so on. If you wanted to be a pedand, you'd check the embedded "From:" address as well as the enveloped one.
I'd also appreciate some name-finding AI, so that when a message which programs like SpamAssassin become absolutely dead-set convinced is spam (ie, the filter doesn't say "maybe spam", the filter says "if this isn't spam, upload me to a microwave") arrives - but passes the above test - any email addresses mentioned in it get a score or so of vary different but realistic-looking "replies" based on the original message ("Re: P*E+N~I:S E|N-L=A/R'G\E!R/Dear Sexy Sal//Please send me four boxes of penis perpetration patches. My credit card number is 3141-5926-5358-9793 and expires on 04-04. My address is Australian Federal Police/Hay Street/East Perth 6001.//Please use plain brown wrapper on the parcel.//Fred Q Nurk esq") but from a variety of bit-bucket addresses and spread out over the next few hours. A bit sad if the spammer is spoofing from your address, but you can easily filter everything related to such spoofing - and otherwise forces the scumbags to work for their addresses. Even better if he wants to talk to a bot about invalid credit card numbers or mismatched expiry dates. Better still if you can arrange to get them done for credit card fraud, maybe by using numbers from your local supermarket's stolen-cards list. Working for their addresses is exactly what spammers don't want to do.
You see, I've become convinced that a war of attrition - making it harder for spam to get through - isn't enough.
The thing that makes spam work is that it's cheap to get addresses and cheap to send out mail. Since there will always be bad-apple ISPs (and dumbo-sucker ISPs) who let the canned-ham merchants send the stuff, the obvious step is to make collecting the addresses harder.
Collecting addresses is a two-phase process. Phase one harvests addresses wholesale using spambots and/or people stupid enough to fill in random on-line forms accurately, phase two qualifies those addresses by sending stuff to them. Unfortunately, the same people stupid enough to fill in forms willy-nilly are the same people stupid enough to respond to spam. I guess it's just not a good survival characteristic.
If it were possible to establish a contract by sending someone email, we could make the initial harvest very expensive, very quickly by simply embedding the email address in an offer of contract. Unfortunately, the courts have so far decreed that such an event doesn't necessarily entail a "meeting of minds" necessary to establish a contract - even if the email address says "email-to-this-address-costs-USD-1000-in-advance@m ydomain.dom". To me, this makes no sense, kind of analogous to releasing an automated tank and being able to claim that any damage done by it was not deliberate.
Nevertheless, if we can make
Got time? Spend some of it coding or testing
I have a Cox cable modem at home (along with an SBC DSL line as a backup) and run a hosting business with servers in Philadelphia, Costa Mesa, CA, and Los Angeles.
We are constantly looking for the right mix of rules to deal with spam. We don't want to interfere with our customers businesses, but we don't want to be the source of spam as well.
We have implemented a number of items to try to "play well" and give our customers the service they need.
Shared hosting customers get send after read SMTP privilidges. This is pretty standard with POP3/IMAP servers. We further limit the outbound rate to about 2 seconds a destination address just to keep people from getting cute. For those that are behind funny firewalls (like Cox), we run an outbound SMTP server on 8025. All in all, this seems to work pretty well.
I am not 100% sure how the SPF stuff would impact us. For the domains we manage, we could easily automate the DNS updates. The issue is for users that want to run our server but that we don't actually run the DNS servers for. I would love to see a "delegate" record in the spec to send the query somewhere else (maybe a CNAME would actually work, but it is late and my brain does not do that type of DNS right now).
For our "server" customers, our approach is a bit different. If you are buying a dedicated server in a co-lo, you have an expectation of being able to talk to the "net" without interference. We also believe that we dont have a lot of justification in "spying" on what our customers are doing. On the other hard, we don't want to be surprised when a customer sends out 50G of spam. About the only "solution" we could come up with is transfer logging the packets that are going to port 25 outbound (fortunately, IPTABLES does this very well). This way we will hopefully see an abuser before they get us in trouble with the BH lists.
All in all, the SPF stuff looks like it needs a bit more discussion before diving in. Also, if the outcome is just a new set of tricks that the spammers play then I am not sure if it is worth it.
SPF? I don't need any SPF. What kind of idiot put sun block on a server?!
He who laughs last is stuck in a time dilation bubble.
I'm a customer of pobox.com (for my personal correspondence) and the poor schmuck who runs part of the anti-spam solution for about 15,000 people, but that's part of a company 30 times that size.
Professionally, I already run SpamAssassin. It does pretty well without SPF. Users are actually sending thank you emails. I guess we'll see if it has much effect after v2.70. It sure will be a while before it has a large score.
The problem is that even with the company being 30 times this size, all of our email comes from the same 2nd level domain name rather than subdomains. We have 2 choices: send all of our outgoing email through the same place (they charge by the byte for internal corporate backbone usage, it's cheaper for us over the Internet), or keep the SPF records up to date for all the internet access points. Both options suck.
Personally, since pobox.com is primarily a mail-forwarding service, this might seriously affect their bottom line. This proposal makes their service more annoying to use, perhaps enough that it isn't worth my $15/year. It might be worth it to finally just get a DynDNS setup instead.
Their "objections rebutted" page mentions this as one of the biggest problems with the system. No shit. They are under the mistaken impression that many MUAs make it easy to separate the configuration of your envelope from and your header From:. Of course, they "offer" that I can use their SASL SMTP servers. Unless their customer base is a lot smarter than the average bear they will not understand what to do with this. Years of experience as postmaster@ suggests most email users are frighteningly stupid. How many crystal clear bounce messages have you "interpreted" for your users? Just what part of "user unknown" is confusing? "Thanks, you just decreased spam worldwide by a few percent. Too bad your company went out of business because of it."
All true wisdom can be found in sigs.
Some more proposals are on http://www.irtf.org/asrg/asrg_documents.htm/.
The decision to accept or refuse the mail is made BEFORE the bounce message is transmitted. Try again.
now we need to go OSS in diesel cars
Taking apart the bounce message and extracting the original message? That requires going ahead and accepting the DATA transmission. This is not an acceptable solution. While SPF might cut spam in half, I have to double my costs to do it? That puts things back to as bad as they are already. I'll wait until this thing gets re-designed. The idea in principle is interesting. But it needs some work.
now we need to go OSS in diesel cars
Publish SPF records for your domain.
OK, why can't spammers do this?
I had an idea not too long ago...
What if you write a little app that looks like a SMTP daemon and would accept incomming mail just like a open relay but simply route it to a bit bucket.
1. spammers look for open relay
2. find one of these
3. send the spam
4. spam never gets to target
5. you are a hero for a day
If this gets implemented in a wide scale it would make life harder for spammers. Much better than simply blocking spam, they will just look for another open relay, this would trick 'em and that batch of spam never reaches target...
After a while I am sure they will get wise and find a way to sniff these fake open relays/black holes so it might be clever to make it reconfigurable (emulating the next version of popular SMTP daemons or changing its "look" every week) or allowing say 1 email to go through so if they email themselves it will look valid and then send another 5k only to be black holed.
Any thoughts... anyone with the coding skills want to write a demonstrator app for win32 (yeah I know but think of all those xDSL and cable modem boxes out there that this could sit on) I'll pay a little something for it...
Well, there goes sending mails from "stray" IPs. (domainless ones).
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
The decision to accept or refuse the mail is made BEFORE the bounce message is transmitted. Try again.
Says who?
Personally, no mail is ever refused, just analyzed by SpamAssassin and sorted out into a separate mailbox.
1. To: In a direction toward so as to reach: went to the city.
2. Two: Something having two parts, units, or members, especially a playing card, the face of a die, or a domino with two pips.
3. Too: More than enough; excessively: Example: She worries too much.
The only way to stop spammers is to stop the people who are paying them money to send it. And the only way to do that is to make it an ineffective advertising medium.
If everyone (and I mean everyone) stopped buying products from spammers and their clients, we could wipe it off the planet by the end of the year. How many people here have explained to their parents, neighbors, and non-technical friends why spam is bad? Or how, even if it's about a product they really want, they should buy it from somebody else on principle? We've been trying to solve this problem for a long time, but I've only seen proposals for technical solutions.
There are no technical solutions to social problems. Support the Great Spam Boycott.
you don't solve the spam problem by punishing those who are behaving correctly.
spam exists purely because the cost per _response_ to the spammer is extremely low. You fight spam by making it uneconomical not by making life difficult for all by means of schemes that will certainly be worked around by the professional spammers.
Taking apart the bounce message and extracting the original message? That requires going ahead and accepting the DATA transmission. This is not an acceptable solution. While SPF might cut spam in half, I have to double my costs to do it?
Erm. So, SPF gives you the opportunity to turn down even more connections by detecting spoofing, but you spit in its face because it has no effect on the null sender case?
Its not like the suggestion to unpack a bounce is SPF specific. Its just a helpful suggestion.
3) Add your ISP's SMTP server to the "allowed to send email for this domain" list at work
Given a responsible ISP, this probably wouldn't be a spam problem, but I'd be careful with throwing even this mild form of trust around.
this idea is great bullshit.
how about you on a trip, traveling around and stuff, using some cheap dialup/trial/aol networks just to access the inet.
then you can add a bazillion different ips, so that u can send email from foreign places using foreign smtp servers and shit.
how r u gonna know what ips you will ever be using to send emails from and so forth. thats crap.
i could rather tunnel home to my network and use the smtp servers to send my mail, or use smtp authentication and all the other means.
but if you now think we can disregard all those fucking spammers out there you are plain wrong. we need to hunt them down and hang 'em. they are the evil ones here, and we dont need more technical crap to stop spam, but we need to stop the spamming guys and real spam sources.
technology is not the solution to all the problems in this world.
shut down the spammers, jail em, hang em, kill em, then we are safe from them.
fuck them spammers for good!
adding obligatory header "x-spoofed-from" to email headers? Just like the new "evil bit" in TCP...
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
If you have even a remote understanding of what SPF is, you wouldn't be sprouting this crap.
SPF doesn't publish any sort of list. SPF simply uses DNS to respond to whether any particular host is authorized to send mail on the behalf of a domain. SPF doesn't add anything to DNS that would make it more vulnerable to DDOSing than it is now.
Here is the draft RFC:
c h- dns-rr-smtp-02.txt
- ds protocol-04.txt
http://www.ietf.org/internet-drafts/draft-danis
It works similar to the SPF method, except it doesn't abuse the TXT-RRs. Instead it introduces a new DNS-RR, the RMX-Record.
The RMX specifies an IP, an IP-Range or a NOT-IP / NOT-IP-Range.
This approach is (imo):
a. cleaner
b. more efficient (uses less diskspace)
c. more intuitive for the DNS-Users
Downside:
- DNS-Servers need to be upgraded to deliver RMX
- Mailservers need to be upgraded to honor RMX
For completeness heres another approach:
http://www.ietf.org/internet-drafts/draft-fecyk
This seems to be the inspiration for SPF, and I dont like Fecyk's approache either. It does also abuse the TXT-RRs, which sucks (imo).
Meme of the day: I browse "Disable Sigs: Checked". So should you.
Well, the email is actually from v2.listbox.com, although I get the same results either way.
0 7.8.214.4,'sender','v2.listbox.com') called at -e line 1
1 6.65.124.73,'sender','v2.listbox.com') called at -e line 1
$ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 207.8.214.4 v2.listbox.com
Mail::SPF::Query: ->new() requires a "helo" argument.
Mail::SPF::Query::new('Mail::SPF::Query','ipv4',2
softfail
client umbrella.listbox.com[207.8.214.4] is not a designated mailer for transitioning domain of sender v2.listbox.com
Not sure why you got fail.
The actual messages from the list arrive from rune.listbox.com.
$ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 216.65.124.73 v2.listbox.com
Mail::SPF::Query: ->new() requires a "helo" argument.
Mail::SPF::Query::new('Mail::SPF::Query','ipv4',2
pass
client rune.listbox.com[216.65.124.73] is designated mailer for domain of sender v2.listbox.com
Their setup isn't broken, given the softfail, but I'd probably add umbrella.
RTFC
Already Discussed
PostFix doesn't check the email domain that you claim the mail is from, it just checks that the HELO is accurate, by resolving it; there are lesser checks like "the HELO name is not an illegal host name" and "the HELO name also has a dot in it". PostFix can also check that the calling IP (distinct from the HELO) reverse-resolves - at the lowest level, into anything at all; at the next level into something that can be forward-resolved to include the same IP address.
.au, .uk, .de (and other EU) and the US.
Unfortunately, this is not a check on spammers, it is a check on incompetent administrators, which are much more prolific than spammers. Even in suprisingly large, well-heeled and technically-literate firms from "first world" countries like
I'm tempted to implement it for that very reason for myself, but there are two factors speaking against that. One of those is that I often rescue poorly-adminstered IT setups, and if I switched the filtering on, their email wouldn't get to me. The other is that I object on principle to inconveniencing many people more or less at random just to take a swipe at a few spammers.
Got time? Spend some of it coding or testing
Isn't this exactly the same as RMX (reverse MX), but with a much less cool name?
"Sender Permitted From" makes no sense without context, while "Reverse MX" tells you exactly what it is. RMX is a much cooler sounding acronim then SFP, IMO.
ReadThe ReflectionEngine, a cyberpunk style n
Lots of blacklists include any dynamic IP blocks thy find, including my ISP's DSL range.
Got time? Spend some of it coding or testing
This will prevent all mail spoofing. It wouldn't stop anyone from having a mailing list though, although you would A) need your own domain, or B) get your mailing list server authenticated by your ISP.
ReadThe ReflectionEngine, a cyberpunk style n
All you'd need to do is bless your ISP's servers or any other mail server you'd use with your domain's RMX records (or *gag* 'SPF').
ReadThe ReflectionEngine, a cyberpunk style n
This is a silly though: but the ability to refer
... j.b.hello.com.
from one domain to another could well be abused. (I suspect that there should simply be a limit on the amount of recursion required, or at least a minimum.)
Suppose I send from a domain a.b.hello.com, where I control the DNS on b.hello.com. I modify my DNS server so that there are, say, 10 referrals to:
b.b.hello.com, c.b.hello.com,
Then, b.b.hello.com refers to something else, etc. etc. With all the SPF referral entries being generated on the fly.
Now, this isn't so much of a problem, because tying up a mail server would entail tying up the DNS server doing the referring. But a large number of small DNS servers distributed around the place could start causing problems.
I'm not sure where thinking this through leads to... any thoughts?
John_Chalisque
How many mail server admins will actually implement it?
I mean, with the gazillions of open relays and open proxys out there, especially in asia and the lots of misconfigured broadband 24/7 connected home pcs, what good would it do?
If the admins in question are too lazy / to stupid to set up proper anti relaying, how on earth would you get them to implement this additional check?
bye,
[L]
Doesn't this just mean that legitimate email addresses get published publicly for any spammer to collect?
As someone who spends an hour a day maintaining spam filters I
would love to be able to filter based on such an "allowed"-list.
However, I also see a problem. I have my own domain, maintained
on my own computer. My father is connected to the world through
a free dialup account, where he gets one of these random name/letter
combination email address. And that address will obviously change if
he changes to another provider. Therefore his system is configured
to send out his emails through the free provider's mail server, but
his From: address is an email address of the domain belonging to me.
This is the email address he gives out to his friends and associates,
and it never changes. My computer simply forwards his mail to
whatever is his current free account email address. Works great.
But obviously, with the suggested scheme, my domain name server
must include the IP address(es) of his free account ISP's mailserver(s),
which can change at any time. In other words, will be tricky!
It may not even be possible. I would hate to have to tell the old
man that from now on his email address will just have to be
ju3n4n@freeasinbeer.net and change every five months.
Spam is only a problem because its not costing the spammers' clients nothing. Make them pay for using spam and the entire industry'll dissapear.
Since they are the ones who are visible, they can and should be sued.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
draft-danisch- dns-rr-smtp-02
And this TXT record for the *.smtp-client. subdomain is the ugliest DNS hack I have ever seen.
The above draft makes sense and introduces a reverse MX DNS record type....
This very idea has appeared before (on Slashdot) as "reverse mx". It involved use of another kind of DNS record, but the principle was the same. Alas, _is_ it the same people, with a different name and implementation? Anyone knows?
(8-DCS)
I believe Exim can do your fancy callback thing. However I would not turn it on because of the posibility of losing mail.
I want more laws. I'm moving to Cali just so I can supplement my IT income with spam lawsuits!
If businesses *cough*SCO,RIAA*COUGH* can include lawsuits as part of thier business plan I can too!
I can see two problems with this. After reading the draft RFC and the site docs, I don't see answers, am I missing something?
The first problem is fixable - use TXT records for now, push through a draft for a new resource type, and have a migration period so that you can encourage adoption without gating it on changes to the DNS hierarchy.
The second problem is more of a PITA.
but you spit in its face because it has no effect on the null sender case?
I think Skapare wass trying to imply that the null sender case would quickly become the most common case should SPF become commonplace.
Will I retire or break 10K?
...from their SMTP server, which is more than they would get if it just bounced.
Got time? Spend some of it coding or testing
A few options: 1) use an ISP that will allow you to relay mail, and find your way to a telnet somehow. Not likely, but it's possible. 2) use an ISP that allows shell access (good luck finding one). Problem solved. 3) If you really need to mail someone on a trip to Europe, tell them about the problem and have them whitelist you.
But certainly don't expect people to accept non-matching mail sight-unseen.
-Looking for a job as a materials chemist or multivariat
You know, this is *exactly* why the concept of a "reply-to" address in a mail header exists.
-Looking for a job as a materials chemist or multivariat
(That was sarcasm. I wouldn't ordinarily point that out, but this is slashdot.)
Impose a $0.01 fee for every email. The money goes from the owner of the originating system to the owner of the receiving system.
For example, I write an email to you, and place it on my ISP's system. I owe them a penny. They pass it upstream and owe SBC a penny. SBC hands it off to Sprint, then to a your university, and finally, to your computer. The penny flows through SBC, and your university to you.
Then you reply. You place you email on your university's mail system, they hand it to Sprint, then to SBC, etc. The penny flows back through the chain to me. And everyone is even.
As long as you receive about the same number of emails you transmit, your balance stays near zero. Systems that send inordinately more than they receive end up paying more money.
For the big guys like Sprint, its all a wash (except for the general reduction of traffic on the backbone). But for average email users who are starting to see 50-100 spam a day... it might not be so annoying if it was paying for one dinner a week.
A spammer sending 1 million emails an hour just raised their operating expenses by $10,000/hr.
To authenticate, you must connect to your home server first. Often, the "traveling mailman" can't do that due to network partitions, slow links, etc. I've often found it difficult to connect to my home server while traveling in India, Europe, etc.
It is often possible to guess an author's age by the proposals generated. My guess is that the author of this proposal is under 35 or at least got into the business sometime after 1993... People who have never known anything other than the amazing connectivity and bandwidth that we've had in the last decade in the US tend to forget some of the more basic realities of working with networks...
bob wyman
I don't think there is a way to implement and/or support SPF for large email hosting services such as msn, yahoo, etc. Majority of their client base is roaming users; supporting SPF will require tracking what IP address particular account has been accessed from in past N days/months .. which would clearly constitute as a huuuge privacy breach for paranoids among us :)
3.243F6A8885A308D313
1) Servers can maintain lists of "temporary allows" -- Say you're out roving around the country and want to send an email like you're at home, but you're in a hotel using their LAN - when you login to your mail server it records a "temporary allow" record and any email transmitted from your computer during that "temporary allow" period has it's ID recorded and then for say a month the server holds onto that record and can be asked "Was email ID from HOST valid?" - "Yes, Temporarily Allowed" 2) Users can login and add "permanant allowed systems" - say you use have a permanant account with your university like I do with my cs.iastate.edu - say SPF, or what ever was implace and I moved off campus to my appartment (Which is happening) - I then want to be able to have my own SMTP - i can with my CS login and add my record to their allow list. i'm sure i have left out some use-cases, give me more and I'll try and think up solutions!
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
I get emails all the time from strangers. Emails I want - I run FAQs and websites for a newsgroup, as well as a memorial website for a musician, etc. So I *expect* email from strangers. But I hate spam, commercial or otherwise.
Authenticating the From address would be much better. If the transport software would check that the From address somehow mated with the connecting host, or failing that of the received-by lines matched up, 80%+ of the spam I get would never even make it to the filetsr.
The RFCs have an established mechanism for telling people to reply to a different address. Every MUA I've ever seen respects Reply-To. Anyone who can't be bothered to change Reply-To deserves to have their mail bounced as having a forged From header.
You wanna be helpful? Teach users what Reply-To is all about.
That would work, but it'll never be implementable as it would require a protocol change, or at least you would have to convince whoever does your hosting to provide that service, ie, to vouch for your "forged" header. If they were that friendly, you probably could have convinced them to let you use the SMTP relay in the first place.
I think an easier, client-based approach would be to build in a feature that it automatically whitelists your address if it ever receives a non-spam message from you. That way, you can continue to email anyone you've EVER emailed successfully from wherever you are, if they use such a client. It would be a good feature to build in to either clients or even spamassassin-type programs.
The only way you get in trouble is if someone joe-jobs you.
-Looking for a job as a materials chemist or multivariat
Instead of putting control over which ip's are allowed to send mail in the hands of the administrator of a domain, how about putting it in the hands of the person who controls the ip's themselves. That is, the person who makes the reverse entries for the netblock in question. This could be in addition to SPF or any other check. The mail server could query something like smtp.1.2.3.4.in-addr.arpa and if it returned some preassigned value, it was a server that was expected to send mail. I don't know if this would work, but it would seem to generally put autorization of mail servers in the hands of the people responsibe for the network, which is possibly one step up from the domain user.
How about sending emails for a generated hash arguement. For each email, your server can call the sender back and ask.
HASH:ERLWEKJFILKJ:jdoe@yourserver.com
Sending server replies: true/false as to whether they actually sent the email. Hashes shouldn't be too much overheard to calculate (basically it could be based on a numerical index), and we'll quickly find out whom the spammers are. There's a bit of extra network overhead in calling-back, but not much and it would be a relatively small amount of data to be sent.
So, if you buy something from a spam, who tells the cops?
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
If they sold you an internet connection, it seems like it should connect to the internet.
It's not like they're advertising a webtv-like browsing service, or the old-aol-before-connecting-to-the-internet.
But it abuses the TXT record type. Adding a new record type is not as big a problem as people seem to think.
This solution seems analogous to the use of ingress/egress filtering to prevent spoofed source addresses on IP packets, and also completely dependent upon such filtering to work correctly.
In the Internet today, since such filters are seldom used, anyone can say that they are from any IP address. By publishing a set of IP addresses that can be used to send Spam from within a domain, this "solution" simply hands spammers the tools they need to make their spam appear more authentic.
I am *not* an Atomic Playboy, but I *am* a cheese-eating surrender-monkey!
The bounce formatting is not standardized. Parsing it will be next to impossible. In fact, many bounces are broken and do not include all the headers from the original message.
If they want to stadardize bounce messages that would be good. But don't pretend this is a tiny problem which can be fixed with the wave of a hand.
Though I have never administered an MTA, I'm guessing that handling bounce messages generated by popular MTA programs (postfix, sendmail, exim, qmail) should be enough for now.
Will I retire or break 10K?
A nice idea in theory. But right off the bat it requires the remote system to be willing to give up email addresses to some unknown connecting host. No thanks. I specifically don't support EXPN for a reason, it's a good way to help spammers validate their addresses.
Next, lets consider the proccess.
Obviously, there are some possible methods to avoid the looping, but they get pretty complex if you want to avoid spoofing. None of them are particularly efficient, and all will raise the workload of all mailservers and network traffic significantly.
And what happens when the mailserver is down? What happens when spammers discover they can just cycle through lists of possible email addresses at all the various mailservers looking for valid ones and start pounding your mailserver? Ooops, well, lets turn off this verify thing....uhoh, now none of our going mail is being accepted.
Further, some mailservers don't have any idea what users are valid. An example, a lot of companies setup internal exchange server networks and have external SMTP gateways that simply accept and relay mail to the appropriate internal exchange servers. Now these servers *have* to be configured to do some type of user checking.
What happens when the MX is down? The SMTP might've come from a valid user, but you can't connect because of some network/power/server outage. Now you're wrongly refusing mail and it's getting lost.
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
This is a problem I personally would run into with what you suggest, I have a feeling I'm not alone here.
I have a laptop, I may not be in the same place for extended periods of time, I may be consulting for someone, I may be on vacation, I could be anyplace. The only location I can send mail through reliably is my own mail server.
So does this mean I need to setup my own dyndns type system to add my current IP to the approved list so that I can still send mail no matter where I am?
I've already dealt with loops, and this does not require any new server technology, it works with most servers right now today. In using this, you will not be exposing anything new, spammers could do what you're suggesting already, but it's probably simpler for them to just vomit stuff across the 'net than to waste time checking it.
Got time? Spend some of it coding or testing
milter-sender is a sendmail milter plugin that does similar things differently.
When you are receiving a SMTP mail, the sender claims to be somebody using a MAIL FROM statement within the SMTP dialogue. milter-sender will take the senders domain, look up the primary MX of that domain, connect to the senders mail server, and tries to deliver an error message to the sender ("MAIL FROM: ", "RCPT TO: ").
If the senders mailer says it cannot receive error messages ("550 user unknown" after the RCPT TO"), milter-sender will not accept the incoming mail for you.
milter-sender also detects dictionary scanning for mail addresses on your machine and disconnects dictionary spammers after a number of attempts.
Kristian
The odds? Pretty good... due to peer pressure by the larger domains saying - we will bounce any e-mails from domains without reverse MX policies.
Once you get 10-20% market penetration, I predict we'll see a quick uptake in the number of domains with reverse MX settings.
The beauty of the reverse MX idea (which is so simple that it's hard to believe it wasn't in there from the start) is that it's merely additional information that the destination can use. What they choose to do with that information is up to the destination. Initially, most domains with just use it as an additional score value for their spam filters.
Wolde you bothe eate your cake, and have your cake?
Your e-mail provider will either make it possible for you to send mail or lose your business to someone who will...
Or, if you own the domain, set your reverse MX records to allow you to send e-mail from any IP address. (However, loosely defined IP ranges have a high chance that the destination mail server will score you more towards a spam domain then a ham domain.)
Wolde you bothe eate your cake, and have your cake?
I use multiple ISPs to send mail (1 at home, 2 on the road). All three use dynamic IPs. One ISP(AT&T) uses lots of dynamic IPs. I don't host my domain, so it's going to be next to impossible for me to have control over configuring the mailserver. I bought my domain so I would never have to change email addresses again and as a front for my business so potential employers can contact me. If my initial messages to them are tagged as spam, I'll lose to do business. Furthermore, this isn't going to stop an unscrupulous ISPs from setting up zillions of domain names and throwaway accounts to send spam through.
This isn't the fault of my email provider, per se... they offer ADSL, which I would happily take, but ADSL service is simply not available where I happen to live. It pisses me off to the extreme, but I'm just not currently in a position to be able to afford to move (currently, my family and I are eligible for government rent subsidization that is keeping the amount we pay at less than half of what we'd have to pay if we were to move).
File under 'M' for 'Manic ranting'
The IP solution has serious flaws, because essentially, your IP address is your key to your e-mail, but your IP address is not something you necessarily have control over, especially if you're using a mobile device that might connect to the net from different locations at different times of the day (through different wireless access points). IMO, key authentication schemes are a much better area to research. This IP address based solution just won't fly.
MakePassword.com Mp3 Blog
Unlimited growth == Cancer.
*.54.65.in-addr._smtp_client.hotmail.com. TXT "spf=allow"
Just one record per netblock, not one record per IP number.
Unlimited growth == Cancer.
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
I fail to see the point of all this. Just seems like a stop-gap solution to me. Accept it.
web hosting
From the original post:
Leading you through by the hand:
An alternate scenario, where someone@over.here is forged:
This isn't a panacea, it will just force the spammers to use entirely real addresses (although maybe not their own) in their email, but not interfere much with genuine email. Genuine addresses also improve the traceability of the spammer. The more techniques we can find which don't trip over everyday users, but do require extra work from a spammer, the less attractive spam will be.
Got time? Spend some of it coding or testing
...will be to train suckers that replying to spam can be instantly wishing-for-a-hole-in-the-floor embarrassing - it will drive up the social risk in responding to spam, which again reduces the payback for the spammer, making his life that little bit harder. The idea is to discourage more and more casual spammers until the diehards are left standing - alone and obvious. Vulnerable. <WHAM!>
Got time? Spend some of it coding or testing
It's so much hard work getting points across to you that I'm going to stop now - but I will add an exercise-for-the-student questiun: Why do you assume so much and then argue as if you've made the correct assumption, instead of testig it yourself or actually asking? For example, why do you assume that a secondary MX is always unable to fully validate an email address?
Got time? Spend some of it coding or testing