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 info

[ScArE2100]

Sender ID Framework [microsoft.com]

Good

[afidel]

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.

Swiped my post! "Patents have to be clear and pub.

[Spoing]

Hmmm...looks familiar... [slashdot.org]

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

[Spoing]

Redundant????

IT was MY POST that was STOLEN! [slashdot.org]

Re:SPF issues

[afidel]

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.

From the article...

[Ayanami Rei]

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

[Exter-C]

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.

Re:A little OT...

[afidel]

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.

Re:Hmm, not too fond of Redmond?

[idiotnot]

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.

Re:The Problem?

[DMNT]

Every day you guys bitch and moan about how horrible and awful spam is, then Microsoft comes along with the perfect solution, and you all put it down like it's a bad infection or something.

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?

[devilspgd]

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.

Re:as a sys admin

[LoadWB]

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.

How about something BETTER!!!

[ZuperDee]

Why not use AMTP [bw.org] instead of all these kludgy SMTP extensions/workarounds?

Re:How about something BETTER!!!

[LoadWB]

At first glance, I would say because it requires expensive x509 certs signed by a trusted CA. Many people use self-signed certificates because a $29 cert IS too expensive. Even so, sometimes those $29 certs are not as recognized as the $149 Thawte cert. In any case, certificates can be obtained by spammers, so you wind up with authenticated spam.

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...

[AnotherBlackHat]

I'd actually like to hear a proponent of SPF deal with the complaints made about it here. [tesco.net]

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 [e-mail], then example.com already has you by the balls.
If you're using [e-mail] 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 .com.
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?

[Anonymous Coward]

"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 [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

[Anonymous Coward]

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.

Re:Joe-job fix

[LiquidCoooled]

Best get your homepage link fixed.

Your modesty shines through, you missed the chance to really plug your software, so here you go:
http://smtpfilter.sourceforge.net/introduction.htm l [sourceforge.net]

Wish you the best of luck.

Re:Hardly, its business related

[Denny]

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

[gfilion]

Here's a statement from Carl Hutzler, Director, AntiSpam Operations, America Online Mail Operations.

> We do welcome any statements directly from AOL or any network
> operations group regarding their plans for Sender ID or CSV. However,
> we ask that they respect the fact that this is a discussion list and be
> prepared to answer any technical questions that may arise from their
> statements.
>
> -andy, MARID co-chair

We remain committed to sender identity technologies.

We intend to begin beta testing SPF on our inbound systems very soon (weeks
from now). SPF is low hanging fruit that will benefit AOL and many other
domains although it will not work for 100% of the mail we receive. But it
will work for >80% of the mail we receive and that is good enough for a
first strike.

We also believe that the best way to secure the 822 FROM address is a
content signing approach which is out of the scope of this working group. We
hope to see a new group formed to tackle the issues in this arena.
DomainKeys, IIM and TEOS are all reasonable technologies in this arena. We
are sure their will be more which is a good thing for a working group :-)

We remain committed to other IP based approaches and see a lot of benefit to
the "newer" CSV idea. AOL already gets >85% of our spam from other ISPs main
outbound MTAs. SPF, SenderID, and Domainkeys will not change that as this
mail also uses the legit domain of that local ISP in the 821/822 headers.
CSV and certain best practice documents (BCPs) shift the responsibility to
the sending organization for the mess they create through their insecure
networks and insecure practices (like lack of SMTP AUTH of any form, lack of
any outbound controls, inability to suspend accounts, insecure web servers,
etc).

-Carl

--
Carl Hutzler
Director, AntiSpam Operations
America Online Mail Operations
[e-mail]
703.265.5521 work
703.915.6862 cell

Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg049 35.html [imc.org]

Re:Dumbass.

[Anonymous Coward]

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.

Re:AOL gets it?

[nuggetman]

BZZZT. Incorrect. While it was once locked in to the AOL service, the AOL mail system is now accessible using any standard IMAP client.

As stated before

[Andy Dodd]

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.