AOL Will Not Support Sender-ID
DominoTree writes "America Online said Thursday that it will not support the Microsoft-backed antispam technology called Sender-ID. The online giant cited 'lackluster' industry support and compatibility issues with the anti-spam technology SPF that AOL supports."
I'm confused.
It seems this is (almost) universally being voted down, it's time to give up and not implement this. There must be a better way to solve this, and I'm not surprised MS came up with this one!
CB--->
free ipod and free gmail!
I find it quite amusing on how AOL is sometimes caught sleeping with Microsoft (like IE in AOL) yet other times it pretty much pretends like they want nothing to do with them. You'd think that AOL is big enough to where they can honestly tell Microsoft to "Shove It" without any big consequences.
With this single decision AOL will disenfranchise a whole underclass of society.
Sender ID Framework
I thought AOL loved blackholing everyone's email from the outside. It already happens over half the time that I reply to an email tech support request from an AOL member. They say I'm not in their address book, so I can't respond despite them having contacted me first.
As a sys admin for a large hosting provider aols anti spam policy has been great at reducing the amount of crap email being sent through thier servers. Over the years its dropped a massive amount so anything that AOL does to fight spam is a bonus to the world as they are such a large part of the "internet".
;)
Unfortunatly there are thousands of ISPs that dont take SPAM as seriously as what AOL does. Realistically this is something that doesnt come as a suprise to many people that have been following the anti-spam developments closly. You cant blame AOL for having a service that is computer illiterate friendly despite your own experiences.
Everyone has the freedom to choose thier provider. Personally Im never going to use them.. but hey the option is there if you ever do want it. and if you do sign up you can live with less spam
From reasons of lack of support and lack of backward compatibility. Wow, AOL was (is?) paying attention:
"The online giant cited "lackluster" industry support and compatibility issues with the antispam technology SPF, or Sender Policy Framework, that AOL supports.
AOL's moves come days after the Internet Engineering Task Force standards body voted down the Sender ID proposal. The IETF said Microsoft's decision to keep secret a patent proposal for the technology was unacceptable. Open-source groups also pulled their support of Sender ID, claiming its licensing restrictions were too strict. AOL agreed with the IETF fallout and added its own reasoning.
"AOL has serious technical concerns that Sender ID appears not to be fully, backwardly-compatible with the original SPF specification--a result of recent changes to the protocol and a wholesale change from what was first envisioned in the original Sender ID plan," AOL spokesman Nicholas Graham wrote in an e-mail."
CB_===__-8a90fuds76
free ipod and free gmail!
SPF is just as effective as Sender-ID for the general internet and is MUCH easier to implement. I am a consultant for quite a few small non-profits and so far I haven't charged any of them for setting up SPF records since it's generally a 2 minute process to create the record (at the most), and an email or a 2 minute phone call to their DNS provider. Sender-ID would force me to do some actual work which would in turn cost my customers money.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Okay, so setting up SPF records aside, have you actually modified their mail servers to do anything with incoming SPF data? As someone who hosts a few domains on a box, I'm very very hesitant to modify Mimedefang to drop messages that fail SPF, because a few people have .forward files on other boxes that point at me.
Has anyone solved the .forward problem with SPF yet?
Well, I'm glad that people like it the second time around. Would be good if I got credit up front!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
It'd been known early on from Microsoft legal that they would "rather see Sender ID die than back down on their patent claims". Sender ID is going nowhere.
Publishing SPF records does exactly what AOL needs. Specifically it reduces the number of joe-jobs directed at its clients. As more mail servers are set up to check these records, the better it gets for them.
What does implementing Microsoft's Caller-ID have to offer in addition to AOL's subscribers?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
IT was MY POST that was STOLEN!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I think ISP's should take more responsability for their users.
Obviously the spammers, and DoSers have an ISP, and if their ISP were punished by upstream providers for allowing their network to emit this kind of crap, by blocking them until the problems are solved, maybe they'd use some initiative to solve these problems.
I do understand that most DoSers are not the fault of the user, but surely the ISP could notify the user, and force them to do something about it.
All these differing approaches to the same problem. It seems to me like trying to shove oatmeal into a sprung leak.
Maybe it's time to simplify.
dump email all together in the corporate environment and opt instead for a more secure solution based on PKI or kerberos or any other host of security structure.
If some contact absolutely needs to receive something via email, no problem. "We will gladly send you an email, but you just can't send us one. Unless, of course, you wish to send it to an employee's private email adress; we don't accept email internally anymore."
"Sorry mr. corporate contact, you must log in to our site www.dmail.company.com and submit messages that way. We have had too many problems with spam and viruses.
there is a nice, lightweight client you can install if you don't wish to log in every time."
It seems to me it wouldn't be that difficult to use a non-email solution for your corporate mailing needs (like the aforementined dmail which i've been hearing so much about), and if another company's IT department can't handle that light technical strain, then it would seem that IT department needs a wake up call.
where are the flaws in this reasoning?
Graham added that while AOL will not check Sender ID for inbound messages, it will still publish records for outbound e-mail.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I may hate AOL, but I have to admit that if they aren't going to support it, then Sender-ID is dead.
Technoli
When will Microsoft just say, "Oh look, honest interoperability is easier than wrestling for control all the time"? Could that happen? It just makes sooo much sense.
SPF marks email so that when you get an email that claims it is FROM an AOL member you can tell if it really does or not. It will not prevent AOL from getting Spam but it will prevent you from getting it from AOL or disguised as coming from AOL.
And this doesn't prevent Spam. It prevents job jobs. If a spammer is willing to ID the domain his mail comes from and not spoof he can Spam you all he wants. Course with a legitimate domain name/IP# you can blacklist him too.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
His first major premise is pure BS.
Ironically: SPF is also a good counter to one objection to IM2000 Internet mail, namely that it involves changing the structure of the mail system. If people sending mail and mail hosting companies are clearly willing to accept the massive structural changes that SPF will entail, they will be willing to accept the smaller structural changes that IM2000 Internet mail will entail.
For the VAST majority of sites there is NO structural change to the way they do email. For small companies (those most likely to have problems implmenting a new system) SPF is as simple as entering "v=spf1 mx -all" in a TXT record for their domain, that's IT! Even for a mid sized companie with multiple divisions with a couple mail servers and a couple domains implementing SPF was a 10 minute endevor, hell getting proper reverse DNS setup usually takes me several times that long due to the necessity of beating it into yet another ISP's head that yes the customer should get a valid reverse DNS entry and reverse DNS is MUCH less usefull for fighting spam and viruses.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
In the end no single solution will work unless the vast majority of servers implement and maintain the solution. There is no use if only AOL or MSN implement a solution for spam. they "may" be 40million users or so but i know personally I dont email anyone @aol.com or @hotmail.com because im a geek and I have geek friends with thier own servers. There needs to be a mass adoption of a good standard to make any difference to the spam problem.
It's not that it is from MicroSoft, not that it's patented, but that it's patented with a special license and it has unclear specification. The current license does not allow the transfer of the rights to a third party - therefore making it unimplementable on GNU Public Licensed programs. GPL requires that any modifications must be passed on for free (if ever want to pass it on), and MS license doesn't allow copying the source code and the license. Therefore, you can't implement Sender-ID for anyone else but for yourself.
Also that wiggle room around the specification is an alarming thing. MS - with many other companies - have shown that any gaps in the specification can and will be used by companies in competition. Given a chance, suppliers will make their product incompatible with other suppliers' products if they have the market share - thus increasing their market share further.
If we give them the power to choose what programs can deliver mail in the Internet, who are we going to blame but ourselves if they want to (ab)use that power? Instead, if they break an existing standard we can point our finger at them and say that their product does not meet the standard and therefore it's their fault that interoperability fails.
?SYNTAX ERROR
Part of the issue is that Sender-ID doesn't offer a whole lot that we don't already have with SPF.
However, the license is incompatible with the licenses used on virtually every mail server out there, and the implementation is significantly more complex.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Lots of those 'morons' are customers so people need to send mail to AOL.
Reading between the lines it's only a matter of time before AOL stops accepting mail from domains that don't publish SPF records. They already reject mail if your reverse DNS doesn't resolve. They're publishing their own too:Good for them.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The problem is that MS's terms for licensing their patents to specification implementors specifically forbids any use by GPL or similarly free licenses. See the GPL is MS's biggest enemy and they are trying to kill it on every front. For example, it is against the licensing conditions of Visual Studio 7 to produce GPL'd software with it. How did they manage this? By introducing a new standard C runtime library, MSVCR71.dll, which can only be distributed under MS' terms. Oh. And it won't be distributed with the OS anymore, so anyone using VC7 is forced to comply with the licensing terms of the runtime itself.
So the problem with patents is that MS *is* starting to mobilize them as offensive weapons against open source in general, and the GPL specifically.
Iv never understood the general anti-aol viewpoint of the slashdot community. Think about it, aol allows computer dumb people to use computers. When computer dumb people use the computers two things happen. They break the computers (which gives you a way to get some extra cash) and they eventualy get better at computers, which makes new slashdoters. Im not ashamed to admit that I at one point I used aol, thankfully those times are over...
Well for better or for worse, if AOL rejects it, that's pretty-much it in my opinion. AOL is probably the most well-known email service on the planet. I wouldn't know who is the biggest or best, but AOL has GOT to be the most famous. Microsoft would have done well to court AOL first... oh well. :)
I've never been a Mac fan, and I'll probably never buy one, but since it's a completely different non-windows OS, and runs different core software like browsers - it's good for the whole.
The more people that use Macs, the more people that will be browsing web sites without IE, and the more websites that won't rely on IE-only functionality.
Truthfully though, it hasn't been a problem running Mozilla for 98% of the sites I visit. And I don't only visit sites like Slashdot - I go to a lot of sites that the masses visit as well. No browser string faking, no activeX plug-ins. Just straight Mozilla, and it works great.
All we need to do is chisel down those last 2% and we'll be living large.
With all the visible security problems in Windows and IE these days - more and more people are getting sick and tired of it. Some people are seeking alternative Browsers, more every day. It's not the obscure security bugs that people care about or even know about it's the ones that allow spyware to be installed causing them to have to call friends, family, support people and generally have a terrible time using their computers.
So.. GO MACS! And.. GO IE BUGS!
- It's not the Macs I hate. It's Digg users. -
All I can say is thank God myself as a small webhost is being backed by such an Internet access giant as AOL is.
:)
I suddenly dont feel so bad for installing AIM to talk to strange women
I feel that what microsoft is looking to punish the witness for what the criminal has done with, although I may be wrong, the intention of profiting off the witness while making the victim feel they, being MS, are trying to helping them out.
IETF really screwed themselves with this post. The patents were posted today by the patent office. http://www.imc.org/ietf-mxcomp/mail-archive/msg048 44.html
and http://appft1.uspto.gov/netahtml/PTO/search-bool.h tml
and type 684020 for Application Serial Number in field1.
Now the IETF engineers have to pretend they are patent lawyers. Of course they couldn't have said that they were rejecting it because people didn't like the license -- the license does all the things that the IETF requires.
Why not use AMTP instead of all these kludgy SMTP extensions/workarounds?
Sender ID and SPF can positively prove that a message came from a domain, but can't prove it didn't come from a domain -- they don't stop forgery. The technologies ignored the fundamental architecture of email (store and forward instead of point to point), and in the process left a glaring hole for spammmers to use. How do you forge an email in the Sender ID/SPF world? You pretend that you forwarded it legitimately. In Sender ID with PRA, the spammer simply adds a Resent-From header. In SPF, the spammer makes the Envelope-From something different than the body From:. Both SPF and Sender ID leave these cases for the spam filters to figure out. If the spam filters can't figure it out today, there is no reason to believe they will figure it out tomorrow. We need a crypto solution to solve this correctly. How is domainkeys doing?
"America Online Inc. on Thursday shunned a Microsoft Corp. proposal to help weed out unwanted "spam" e-mail because Internet engineers are reluctant to adopt technology owned by the dominant software company."
What? Since when did AOL reject it just because it's owned by Microsoft?
Link to the article...
For once AOL does something the media should be praising it for, yet they're practically insulting AOL publically...
"...would not adopt Microsoft's SenderID protocol because it has failed to win over experts leery of Microsoft's business practices."
I wonder if I'm the only one getting painfully tired of the way the news media paraphrases and misrepresents peoples'/groups' positions...
I have seen this comment pop up many times, but no one has yet to submit an operable recommendation on how SMTP could be updated to remain a user-to-server and server-to-server protocol without tossing the entire system and saying "nuts" to any semblence of remaining compatible. Therefore, this arguments seems completely flat.
The only partially useful modification is some form of authentication which would certify the origin of the SMTP connection. Just as I can telnet to a POP3 server and make it think I am a real POP3 client, an end user can make an SMTP server believe it is another server.
SPF offers a sleek way of authorizing what machines may deliver mail on behalf of a domain. I could trivialize it by comparing it to a domain owner-controlled authentication system for emails without requiring a central authentication repository or authority.
What is wrong with this implementation? Can you suggest a modification to SMTP that will acheive similar or better results? If not, then drop your argument, that stick, and step back from the dead horse.
I'm afraid it's someone else who must get real. MS, as any other company, is required to extract as much profit as possible from any and all assets it owns, or else shareholders will file a lawsuit. This happens.
Besides, why MS would not do that? They can do it in a smart way - provide Windows users with a free license, and everyone else has to pay $1000 per license. Where will Linux or BSD be there? Who will be using these OSes for mail transfer? Hardly anyone, that's who.
You must look beyond your nose to see the danger, and it must be said "no" while it is still possible.
ideal; model tiny; codeseg; org 100h; start: cli; hlt; ret; ENDS; END start
It's hardly surprising that some people aren't sure how to feel about AOL sometimes. On one hand, they adopt IE or kill some promising project and get hisses and boos. On the other, they occasionally support or initiate a nifty open source project, or take a position we're prone to like.
Seems to me... and I'm hugely guessing here... that there's two factions in AOL to consider. The tech people, and then marketing/legal/etc. The tech people can sometimes (not always) do some stuff that benefits people, and probably mean well in general in any case. As long as something remains under the radar of the rest of AOL's bunch, and/or results in lots of positive P.R., it lives. But if the legal department or someone panics, well... we all saw what happened to Nullsoft's gnutella implementation, initially. And AOL is kinda flip-flopping where Netscape is concerned, I think.
In this case, the tech guys over there probably pretty much had a lot of sway over the Sender-ID thing. The lawyers, marketing people, et al. have far more important things to worry about, I presume.
I'm not exactly a proponent, but I can respond to most of his points;
* SPF breaks pre-delivery forwarding.
SPF doesn't break pre-delivery forwarding at all, you just need to include the machine forwarded to in your SPF record.
post-delivery forwarding is a problem, but at least in theory, it can be solved by only checking SPF records at the first receipt point,
or by having a smart checker that knows about your forwarding.
I.e. if Alice is sending to Bob, then there's a point at which the message leaves Alice's control, and enters Bobs.
Before that point, Alice can adjust her SPF record to include all possible point of egress.
After that point, Bob needs to check based only on the IP that entered his realm of control.
This may be hard for Bob to do, or beyond his understanding, but that doesn't mean it's impossible.
* SPF hijacks existing DNS mechanisms.
Bullshit. SPF uses TXT records.
It's even RFC 1464 compliant, so it won't interfere with other TXT records (unless someone's already created the "v" tag)
It could have been made less likely to collide by using "spf1=" instead, but it doesn't hijack anything.
* SPF gives ISPs a "lock-in" weapon against their customers.
This one baffles me.
If you're using the address bob@example.com, then example.com already has you by the balls.
If you're using bob@vanitiydomain.tld then you are in control of your own SPF record, and can switch it to anything you like.
* SPF is useless for several entire classes of people.
That would be anyone who sends direct-to-mx email from random IPs.
Those people will have to change.
Sorry, sucks to be you.
The percentage of people in this class is very near zero.
* SPF relies upon DNS for security, but DNS isn't a security service.
Yeah, so?
No one said SPF was perfect, they said it was better than what we currently have (nothing.)
Spoofing DNS, while possible, is considerably harder than forging a from address.
If this were really a concern, we'd already have adopted one of the many "secure" dns alternatives.
* SPF is vulnerable to race conditions during database changes.
Yeah, so?
So is email in general.
* SPF creates new categories of third class citizenship.
Sheese - time to break out the tin foil hat.
The purpose is to discriminate against people who forge addresses.
I suppose some people will try and push all kinds of crap into, around, and on to SPF - but it's really innocuous as these things go.
* SPF doesn't actually address unsolicited bulk mail at all.
That is correct.
SPF is a tool against forgeries only.
It doesn't directly prevent email delivery at all.
* SPF hands Verisign its next unwelcome "innovation" on a platter.
If that's the worst thing you can think of for Verisign to do when they have complete control of the DNS system, then I have no respect for your imagination.
Verisign could create SPF records for existing domains.
Verisign could make resolving TXT records a "premium" service which costs money.
Hell, Verisign could just raise the fees for owning a domain name in
Yes, Verisign is an evil monopoly with near total control over the domain name system, and they can fuck you over at any time.
Get over it.
SPF didn't make them that way, nor will it contribute to their general evilness.
-- should you question authority?
Someone here on Slashdot mentioned DomainKeys as an antispam solution.
It won't work!
Cryptography costs time and money to use! Just look how long it takes to bring up a secured webpage (HTTPS)....
Now imagine if the entire World Wide Web was that way....
Not everybody on the internet have the fastest systems available for use. Even then, such systems would be overwhelmed by all the crypto they have to do in order to process email using the DomainKeys system.
Instead of time consuming crypto, why not use fast, simple, effective spam filtering like my approach.
Having finally persuaded my ISP that = (equals) is a valid character in a TXT record I was able to publish my own SPF records.
Based on a sample size of 1 I'd like to suggest that spammers don't joe-job domains with restrictive SPF records. That makes sense. We already know spammers know about (and use) SPF records. It make sense for them not to use a domain that will be blocked by any SPF aware mail recipient.
The fantastic news for me is that instead of 8,000+ bounces from joe-jobs flooding my mail server each day (imagine how many more emails are delivered or blocked by spam filters), since publishing my SPF records that has completely stopped.
Why am I such a target? I notice that the more often I report to SpamCop the more often I am targetted, but the heavy waves seem to have coincided with increased awareness of an anti-spam SMTP filter I wrote. I guess my work got noticed. Just a guess though.
Recycle PCs and build a wireless community network www.hillsborough.org.nz
I've just been using the SPF setup wizard to generate the SPF TXT addition, and it occured to me that this isn't necessarily going to stop Joe Jobs on small companies.
My domain and mail is handled by my host, with one mail server sending mail for multiple domains (mine and other people who have an account with the host). The reverse DNS lookup for the mail server give the server's name (myhost.com) and not my domain's (mydomain.com) as it's shared, so mail from mydomain.com only has to come from myhost.com to be vailidated. It would therefore be trivial for someone to set up an account with my web host, and they would then be able to Joe Job me.
I know it's only cheapo hosting, but the small one man bands who are vulnerable to Joe Jobbing may be using this exact setup. And yes, it would cost you money to set up the account, but if you were setting out to deliberately harm a competitor it's negligible. Or have I misunderstood something somewhere?
I instantly visualized two ugly, fat girls, fighting over the last piece of cake.
-- www.globaltics.net
Political discussion for a new world
SPF isn't an AOL technology - it's an open project. The core of the protocol seems to be adding some extended information in your DNS records.
SPF website
Regards,
Denny
Police State UK - news and
Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg04
BZZZT. Incorrect. While it was once locked in to the AOL service, the AOL mail system is now accessible using any standard IMAP client.
...and that's all there is to it.
SPF is not meant to combat spam directly.
It is meant to make it easier to track down spammers if they happen to break an anti-spam law, as SPF prevents forgeries.
Yes, all a spammer has to do to spam you is to get a domain and set up an SPF record.
But at this point, you can track his ass down, complain to his upstream provider, and get him shut down.
It's a LOT harder to do that when the email is blatantly forged.
retrorocket.o not found, launch anyway?