LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

Sendmail's Sender ID implementation

Sendmail Inc. has announced the availability of a test implementation of the "Sender ID" email specification. Sender ID is the result of a combination of SPF and Microsoft's Sender ID system. The mechanism uses information stored in domain name service records to verify whether a message can really have come from its claimed source address.

This technology is being promoted as an anti-spam measure, but it is unlikely to do much to reduce spam. What it can do is to cut back on spoofed email. It will thus be effective against phishing attacks and forged return addresses in general. It will do nothing about email sent from domains without SPF records, spammer domains, or messages sent from worm-infected systems.

There is one thing potential users should know about this technology, however: it is patented by Microsoft. There is nothing in the Sendmail press release, the sender authentication FAQ, or anywhere else on sendmail.net about this patent. But the fact is that Microsoft is claiming that a patent license is required to use or distribute code which implements the Sender ID specification.

Microsoft has published a royalty-free license agreement (PDF format). The license allows the implementation, use, and distribution of code using the patented techniques, but "solely for the purpose of conforming with the Sender ID Specification." This agreement is clearly a contract - it must be signed and returned to Microsoft to be effective. In theory, anybody who uses the Sender ID code without having signed the agreement is infringing the patent. One would think that Sendmail, Inc. would have wanted to mention this little fact.

There is nothing in the license which would allow Microsoft to terminate it - unless the user sues Microsoft for patent infringement. Microsoft could, however, change the license in the future, and anybody using the software without a signed license would be affected by the change. Running security-related software which has possible future licensing problems is a security risk in itself. Sender authentication would be a worthwhile improvement to the email system, but, perhaps, we need to look for another way to implement that capability.


(Log in to post comments)

What?!

Posted Sep 2, 2004 1:24 UTC (Thu) by Ross (subscriber, #4065) [Link]

Are you saying that to legally use Sendmail in the future I will have to
sign a contract with Microsoft? I think I'll look for another product
implementing the original SPF spec -- without Microsoft's changes.

Where

Posted Sep 2, 2004 2:26 UTC (Thu) by ronaldcole (guest, #1462) [Link]

Go to http://www.libspf.org/files.html and grab the latest tarball. Inside are patches for your favorite MTA.

Sendmail's Sender ID implementation

Posted Sep 2, 2004 8:52 UTC (Thu) by rjw (guest, #10415) [Link]

Has anybody asked MS why they have not dedicated the patent?

If they don't plan to use it as a weapon, they have no reason not to. Ergo, they do plan to use it as weapon....

Sendmail's Sender ID implementation

Posted Sep 2, 2004 16:36 UTC (Thu) by ncm (subscriber, #165) [Link]

I don't see any reason to use SPF. It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses. Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.

The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.

Sendmail's Sender ID implementation

Posted Sep 2, 2004 17:57 UTC (Thu) by bronson (subscriber, #4806) [Link]

It protects ME, by preventing spammers from spoofing mail from my domain name. And it protects you in the same way. Even if you only have a Hotmail account, when SPF is adopted, your hotmail account can't be Joe Jobbed.

What's your problem with it? Reasoned discussion, of course. No rants please.

SPF considered useless

Posted Sep 2, 2004 18:38 UTC (Thu) by ncm (subscriber, #165) [Link]

That's fine if you have your own domain. I do; most people don't. All the spammers have to do is hack into some other box on the same domain as you, and then they can forge your return address, too, if they like. In the meantime, it puts a big (and, as I've argued, pointless) extra load on the DNS system.

Here's a prediction: the big ISPs will install SPF support. The spammers will counter by (1) forging return addresses using domains that haven't set up SPF and (2) using their zombie armies to forge addresses using the (big-ISP) domain of the zombie. Those of us who have bothered to implement SPF will see an increased variety of forged return addresses. Those of us who have not bothered will also see an increased variety of forged return addresses.

Is that worth the effort? Is it worth the extra load on DNS? Forged return addresses are not a source of entertainment for most of us, so forcing spammers to add more variety to them doesn't benefit us.

SPF considered useless

Posted Sep 2, 2004 22:37 UTC (Thu) by bronson (subscriber, #4806) [Link]

The DNS system is hardly sweating*. Adding a little bit more load doesn't scare anybody, not even the large ISPs. No big deal.

Spammers forging non-SPF-protected domains will be a very good sign that SPF is actually working! Like vermin leaving a resilient host, they'll congregate on the easy targets. I do hope you're right about this.

You realize, of course, if a spammer hacks into zqfmgb.isp.com, he WON'T be able to get forged mail past SPF. He needs to hack into smtp.isp.com (or whatever host is authorized in the SPF records). If he hacks into your STMP server, you're sunk no matter what. If he zombies a random workstation, you're still protected with SPF, but you're lost without it. Your example seems to be an argument FOR SPF. :)

So, is it worth the (relatively small) effort? Absolutely.

* - root name server DOS attacks and cache poisoning don't count, of course, since these have nothing to do with SPF. They'll happen with or without it.

SPF considered useless

Posted Sep 3, 2004 17:11 UTC (Fri) by chohman (guest, #5519) [Link]

Uumm - that doesn't seem quite right to me. If zqfmgb.isp.com is authorized to relay through smtp.isp.com, how does SPF help? I recall this being a common setup for workstations using the corporate server to send mail (it allows, among other things, the firewall to block "unauthorized" outbound SMTP).

Realize that I have not looked into SPF, so my observation could be random hot air. Appologies in advance if it is.

SPF considered useless

Posted Sep 5, 2004 20:28 UTC (Sun) by zmi (subscriber, #4829) [Link]

The corporate mail server should be inside the firewall, and therefore
protectet. If a workstation is hitchhiked and used for spamming, at least
you find out quickly that there's a bad guy.

Anyway, somebody taking over a workstation could also send signed e-mail,
if the signing key is stored on that machine. I would say nothing can
protect you from that. You still have to secure your network, of course.

SPF (http://spf.pobox.com/) helps me, with my small "zmi.at" domain a lot,
as nobody can send SPAM as .*@zmi.at, as long as the receiving mail server
checks for SPF. Luckily, a lot do, as this week there was again a nice guy
who sent tons of SPAM from random @zmi.at addresses. Thanks to SPF, the
number of return messages a la "user doesn't exist" to me were _a lot_
less than before SPF.

Apache Software Foundation position on Sender ID

Posted Sep 3, 2004 11:52 UTC (Fri) by bjn (guest, #2179) [Link]

The Apache Software Foundation yesterday issued their position on Sender ID: "We believe the current license is generally incompatible with open source, contrary to the practice of open Internet standards, and specifically incompatible with the Apache License 2.0. Therefore, we will not implement or deploy Sender ID under the current license terms." This affects Apache JAMES and also SpamAssassin. slashdot story and eWeek story

This stands in contrast to Sendmail.inc/Eric Allman's position: "although not ideal, the RFSIPL and associated IP disclosures satisfy the IPR requirements of the IETF and are compatible with most major open source licenses" though the GPL is not one of them. NewsForge article

Sendmail's Sender ID implementation

Posted Sep 3, 2004 21:59 UTC (Fri) by Lorenzo (guest, #260) [Link]

Oh yeah, Sendmail. That's the formerly well regarded open source MTA maker, now headed by "Neutron" Dave Anderson. That Sendmail is now in bed with MS is no surprise with ol' Neutron Dave at the helm.

Would you like to know how Mr. Anderson picked up the handle of "Neutron"? ... Good, I knew your were curious.

While at Amdahl, ol' Dave was in the habbit of buying companies, running them into the ground, then firing all the employees, then closing the doors on those companies ... at great loss to the Amdahl. Some company up in Fremont CA comes to mind, but I don't recall its name. Some suggest that Dave contributed significantly to Amdahl's demise. ... I personally have my doubts.

Anyway, Dave picked up the derisive handle because his actions appeared to some like a neutron bomb: the buildings were still standing, but all the people were killed off.

I wish ol' Neutron Dave good luck.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds