Slashdot Mirror
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."
Sender ID Framework
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.
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 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.
Well if they controll the DNS for the origional sending domain it is extremely easy to allow the forwarding server to be authenticated for the origional domain. If not then they are doing something which due to spammers is unfortunatly no longer acceptable to most users. As far as changing recieving behavior, no. But I expect that tools like I Hate Spam and Barricuda which many of my clients use will soon support SPF. The best way to use SPF is to just give messages without an SPF record a high starting score on your spam scoring. The main reason I have setup SPF for my clients is that AOL and Yahoo will probably start dropping all email without a valid SPF record soon.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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
Over time there has been a serious increase in the amount of liability an ISP can take for thier user base. This works both ways unfortunatly being an ISP is alreaddy a full time job for most companies with thier support staff over worked and thier system administrators working overtime to fullfill often unreasonable expectations of themselves.
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.
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.
AOL for OSX uses a gecko-based thing, as does (or did for awhile) the Win32 Compuserve client.
IE on OSX is pretty much dead.
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...
postmaster.aol.com offers the "feedback loop" which will inform you of any reports of spam from your system. I have never had the chance to benefit from this, so I cannot personally comment on its usefulness. However, this is supposedly a pro-active way to ensure that such problems do not affect you.
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.
Why not use AMTP instead of all these kludgy SMTP extensions/workarounds?
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?
"Can Microsoft ever win here? Are they always evil no matter what they do?"
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
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."
Send ID is just a primitive approach to the problem of authentication. Domain keys provide authentication in a more flexible way.
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.
Best get your homepage link fixed.
m l
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.
liqbase
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
It's all about defaults. If every Mac that ships sets Safari or whatever else as default, that's what Mac users will use, and everything else is an "addon" that people never really like as much as default.
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.
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?