AOL Will Not Support Sender-ID 269
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."
Sender ID Framework info (Score:5, Informative)
Good (Score:5, Informative)
Swiped my post! "Patents have to be clear and pub. (Score:5, Informative)
Well, I'm glad that people like it the second time around. Would be good if I got credit up front!
Re:Swiped my post! "Patents have to be clear and p (Score:5, Informative)
IT was MY POST that was STOLEN! [slashdot.org]
Re:SPF issues (Score:3, Informative)
From the article... (Score:3, Informative)
Graham added that while AOL will not check Sender ID for inbound messages, it will still publish records for outbound e-mail.
Re:Responsible ISP (Score:3, Informative)
So adding additional work to ISPs will / could often be the straw that broke the camels back. But at the same time I believe the best way to get ISPs working FOR everyone else. Is if they are being the source of an abnormally high percentage of spam then thier IPS or something need to be threatened. In a world where the most part of IPv4 space is taken this would be more than catastrophic. and having IP space isnt a right its a priviliedge.
But having said that its very very difficult for ISPs to fully lock down thier services. We implemented a system where outbound port 25 was blocked to all clients. And our internal SMTP servers where rate limited on a per IP basis for clients. this killed spam for the most part. Then customers would find open proxies etc so the problem then went up again. Its hard to really combat and its a full time job in itself fighting spam from users of your own ISP. Thats even with disconnecting customers etc for spamming. (they often just sign up with a different false name and pay cash or similar).
Its good in theory difficult and costly in practise.
Re:A little OT... (Score:5, Informative)
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.
Re:Hmm, not too fond of Redmond? (Score:5, Informative)
IE on OSX is pretty much dead.
Re:The Problem? (Score:5, Informative)
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.
Re:The Problem? (Score:5, Informative)
However, the license is incompatible with the licenses used on virtually every mail server out there, and the implementation is significantly more complex.
Re:as a sys admin (Score:4, Informative)
Admitedly, I am normally not a big fan of such systems... why should I have to take the time to inform an ISP of my existence, intent to send email, etc., right? Well, in this case it makes sense since they are 1) giving me the benefit of the doubt at first, and 2) giving me a way to make sure that doubt never enters into our relationship. Quite useful, I think.
As an admin myself, I believe this is a useful tool to help find problems in your userbase before they become bigger problems.
How about something BETTER!!! (Score:3, Informative)
Re:How about something BETTER!!! (Score:5, Informative)
SPF provides for a way to make sure the owner of a domain listed in the envelope from address permits the connecting server to deliver email on behalf of that domain. Unless I misread the draft, AMTP seems to rely wholy upon the conversation between the two servers, and a trivial rDNS/fDNS validation.
I would like to re-read the spec in a better frame of mind. In the meantime, if my initial analysis is incorrect, please correct me.
Re:A little OT... (Score:5, Informative)
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?
Re:The Problem? (Score:1, Informative)
If they'd made this an open standard by using a lesls restrictive license, we'd be cheering Microsoft on. They didn't, so they're the bad guys.
Microsoft aren't always the bad guys - they're often the victims of bad IP lawsuits. But in this particular instance, they are.
"Do you honestly believe thay'd start charging royalties on every email sent or something crazy like that?"
The aim of the game is to 'decommodotize standards' Microsoft was attempting to build a standard which would need to be used by everybody, slap some form of patent on it, and then lock out the people they were competing with, in this case, anyone using copyleft licenses.
The strategy was described by Microsoft in a document which was leaked to the public and appears on the OSI website here [opensource.org]
Quote:
"OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."
Re:Whatever Spam Solutions (Score:1, Informative)
Simply put, send ID would prohibit me to run a mail server on an ADSL connection where the provider changes their IP address every day where as domain keys would not.
Re:Joe-job fix (Score:2, Informative)
Your modesty shines through, you missed the chance to really plug your software, so here you go:
http://smtpfilter.sourceforge.net/introduction.ht
Wish you the best of luck.
Re:Hardly, its business related (Score:5, Informative)
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 [pobox.com]
Regards,
Denny
From the horse mouth (Score:4, Informative)
Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg04
Re:Dumbass. (Score:1, Informative)
Safari is now the default browser. The update from 10.2 to 10.2.8 actually replaces the IE icon in the dock (kind of a bar with app icons) with a Safari icon. In 10.3, I don't think IE is even shipped. IE is a dead browser development-wise.
Re:AOL gets it? (Score:4, Informative)
As stated before (Score:3, Informative)
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.