Get rid of SPAM with SMTP authentication (updated)
Posted by PSlijkhuis in Exchange, UncategorizedMany initiatives try to eliminate the SPAM problem. One of these initiatives is e-mail or domain authentication. Some examples are SPF, Sender ID, MARID and recently DKIM.
<update may 2007>
As of May 2007 a new RFC has been introduced by companies involving Yahoo, Sendmail, Cisco and PGP corporation. This new solution against spam is called DKIM (DomainKeys Indentified Mail). It involves a common approach; using a PKI infrastructure. I wonder what this is going to cost to implement? PKI is not innovative technology and encryption / decryption technology is expensive in regards to the volume of email. It is true: SPAM is usually not encrypted. So the more email you encrypt, the less SPAM you receive/send?
</update>
But why this? What are the threads? Well, it is all about abuse of e-mail adresses or domains, because of:
- Spammers want to prevent non-deliveries on their own e-mail addresses
- Fraudsters want to stay anonymous and delete tracks
- Computer worms want to cause confusion or do not really care what e-mail address it abuses
- Phishers want to fake trusted or known senders to get hold of secred information like passwords of credit card numbers
SPF stands for “Sender Policy Framework” which is an open source standard. The development is initiated to secure and check the so called “sender envelope address”, better known as the mail-from address. The underlying technique is a SPF record in DNS. In short: when senders name and ip address deliver a match according to DNS the e-mail is considered authentic. This way, an IP address builts up a reputation. The receiver of the e-mail owns a crucial step in this process. It is the receiver that has to perform the check according to the SPF specs. Implementation is always part of the MTA agent.
More background information and software suppliers via: www.openspf.org or http://new.openspf.org/Implementations
Sender ID (SID) is a Microsoft development. To make use of it you must sign a licence but without fee costs. It is therfore not a GPL/GNU type of license and that of course is the main criticism towards this standard. It is actually a proposal for SPF v2. It still uses the same SPF record in DNS. Microsoft adds a PRA (purported responsible address) definition to it. Also Microsoft defined a SIDF (F for framework) on top of the technology to deliver the intelligence needed, e.g. historical information, logging, traffic analyses. Important to know is that Sendmail has adapted this standard too. Together with Exchange I think this is a strong bases for success. It is still a draft proposal. As is PRA.
More info: http://www.microsoft.com/senderid
MARID is the acronym for “MTA authentication records in DNS”. It is actually the name for an IETF workgroup. This workgroup wishes to create an open standard for SMTP authentication. It is also this workgroup that does not accept the way Microsoft delivers her SID technology to the public. At the same time they advise not to ignore this technology.
More information found on:Â www.ietf.org or the well known IT news sites like: www.windowsitpro.com.
Meanwhile over tens of thousands SPF registrations has been taken place. Of course it is not the holy grale of anti-spam, but it is one important counter measure that any organisation should implement. You should always prevent that your organisation appears on a black list.
Please share your experiences / ideas with SPF v1 / v2. I look forward to your comments
- Paul
And this too:
I found it interesting to read that Microsoft in a press announcement has published that mr. Meng Weng Wong is the inventor of the SPF standard. The supporting SPF website openSPF strongly denies this fact!
Entries (RSS)
On microsoft download you can find an article about how creating your own SPF Record. This is a step-by-step guide to create your own SPF record, and learn valuable tips for implementing the Sender ID Framework.
Go to http://www.microsoft.com/downloads/details.aspx?familyid=b7ce1cac-d884-4216-82fe-379f875663ff&displaylang=en
Regards,
Stefan
What we really need is to change the email protocol. Now everybody comes shouting at me saying that that is impossible because that would require cooperation from everybody at once. Actually that is not true. It depends on which approach we are talking about.
For instance, EmailXT is the only proposal I know that does not require everybody moving from email as we know it to a new system. With EmailXT, two persons are enough to make it work. Let’s say you want to correspond with your mom but you want her to be shielded from spam and viruses: You install the EmailXT client on both computers, set it up, and you can then seamlessly send emails over the current email infrastructure, but immune from the current threats. Then you start recruiting your friends and co-workers. Progressively we will have people switching from the old email system to the new one, and in a near future everybody has moved, without much hassles or effort.
Then everybody comes shouting again saying : “When everybody starts using EmailXT, the old problems return”. Of course that wouldn’t be true since EmailXT is not like today’s email. It is built on relationships and encryption, and unsolicited bulk emailing is no longer possible.
Well, enough ranting. For those interested, http://www.emailxt.com . Not affiliated but I really like the concept.
AS
EmailXT looks promising. Unfortunately the client/server approach ia tanning with the web 2.0 initiatives. It is all web based now. For the moment I think we will have to rely on the spam filtering approach from our providers.
On the other hand we should not punnish the good by adding extra software (certificates, private mailn communities, email extenders, etc), but ban the bad. What ever happened with PGP for example?
This may become a success though when integration is established with existing communities like instant messaging, blogs, newsgroups, etc.
Of course SPAM is will disappear very quickly if everybody agrees to not click on any SPAM related email anymore. The companies behind will simply abandon email when there is no money to make.
- Paul
Paul,
EmailXT can easily work on a web-based setup. The only difference is that your encryption key remains in posession of your webmail provider, which is not a problem for most folks.
EmailXT features encryption much like PGP, but is much easier to use since there are a few pre-defined key exchange rules that the EmailXT client takes care of.
I agree that spam will disappear if everybody agrees to not buy from spammers. However:
- An “internet sucker” is born every day.
- Most people have difficulty separating spam from “ham”
This is a vicious cycle. Like people progressively moved to IM, EmailXT adopters will make others, including all those “spam suckers”, move towards a system that will prevent them to have access to spam and consequently prevent them from buying anything.
AS
[...] rather put my money on the mail server initiatives like DKIM, SMTP authentication, EmailXT and [...]