Forum Moderators: phranque
Surely it's not that hard to have a system whereby the origin of an email can be accurately determined, and rejected if it's a fake?
Is it time for all the larger ISP's to get together and agree a standard to combat the growing spam and phishing problem?
TJ
In may cases it is not possible or undesirable to send your email from your main server.
What cases are those? I'm especially interested in the cases where it is not possible.
Technically-speaking I would agree that
spam prevention is not the primary goal of SPF.But, from a marketing standpoint I would disagree. Go to the Users [openspf.org] or HOW IT WORKS [openspf.org] areas of the site and you'll find dozens of references to spam specifically. But hey, target your customer, right? Can't blame the organization for that I guess.
However I don't agree that certification authorities such as Verisign are a required, or even a valuable, element of that.
It sounds to me like you disagree with an accreditation model. Is that a true statement?
you disagree with an accreditation model
From [openspf.org...]
SPF is an open standard.
As a product of the best traditions of opensource development, SPF can be implemented and deployed entirely on your own, without having to sign any licenses or pay anyone anything.
However, they are consultants offering their services if you can't/don't want to do it yourself.
What gives you your concerns?
In may cases it is not possible or undesirable to send your email from your main server.
What cases are those? I'm especially interested in the cases where it is not possible.
Many ISPs block SMTP ports to anywhere but their own SMTP server. Many social networking sites attach link tracking codes which help the site to work efficiently to emails - something which isn't desirable to have to ask your user to do ("Please copy and paste all this, exactly, into an email, and send it to your friend"). Wireless devices, such as WAP phone, have difficulty connecting to SMTP, and few email providers have WAP interfaces - the only real answer is to use a public WAP email gateway which you have pre-authenticated your email with. That's to name a few.
First, SPF entirely opt-in. If you don't want to use it, then don't. You won't be treated any different from before by those who do use it.
What you said is true for standard personal email communication. Don't forget most (if not all) of us here are webmasters, and most of the email we send is sent by mailing systems and scripts. Many of us own e-card sites, community sites, forums, etc. and will have been hit by the site becoming totally useless to someone whose ISP or email provider decided to install SPF.
However I don't agree that certification authorities such as Verisign are a required, or even a valuable, element of that.
It sounds to me like you disagree with an accreditation model. Is that a true statement?
No, I don't generally despise accreditation. However the form of accreditation that Verisign is doing isn't a commercial service I'd consider worth paying for. If anyone, I'd expect my government to accredit my identity (e.g. by issuing a passport or a digital certificate).
The form of accreditation I do find worthwhile is reputation accreditation based on a clearly defined set of behavioral guidelines, such as "You pay us 0,002€ per e-mail you sent last year (or 2000€ for the first year) as a trust bond, and we'll accredit you (to anyone who believes us) as a non-spammer as long as you don't send UBE". Or the such.
In many cases it is not possible or undesirable to send your email from your main server.
What cases are those? I'm especially interested in the cases where it is not possible.
Many ISPs block SMTP ports to anywhere but their own SMTP server. Many social networking sites attach link tracking codes which help the site to work efficiently to emails - something which isn't desirable to have to ask your user to do ("Please copy and paste all this, exactly, into an email, and send it to your friend"). Wireless devices, such as WAP phone, have difficulty connecting to SMTP, and few email providers have WAP interfaces [...]Don't forget most (if not all) of us here are webmasters, and most of the email we send is sent by mailing systems and scripts. Many of us own e-card sites, community sites, forums, etc. and will have been hit by the site becoming totally useless to someone whose ISP or email provider decided to install SPF.
About the port 25 blocking: yes, it is done by some ISPs, but you can always connect to your own MTA on port 587 (authenticated SMTP) to submit mail. ISPs don't block port 587. Port 25 is meant for MTA-to-MTA communications, port 587 is meant for client-to-MTA mail submission.
About the other cases where you want/have to send mail through a 3rd-party MTA for whatever reason: it's not true that those services (be it WAP or an e-card site) become useless under the circumstances you described. SPF just gives domain owners (be it ISPs or individual persons) a voice in who should be allowed to use their domain. If a domain owner wants, they can choose not to define SPF for their domain. But if they don't want 3rd parties to use their domain as the sender address, then those 3rd parties should respect that.
The technical solution would be to give the user of such services a registered account (often they already have one) and then use that address as the sender address. For example: Joe wants to send mail from his WAP phone using his WAP account at the phone.com cellphone provider, using his ISP address joe@isp.com as the sender address. But since isp.com has published a restrictive SPF record, this won't work anymore. However, Joe/phone.com can use the address joe@phone.com as the sender address, and add a Reply-To: joe@isp.com header so replies go to Joe's ISP address.
(Many people view e-mail addresses as tokens that identify persons, so they wonder why they can't use "their" address when sending from anywhere. But that's not technically true, it never has been. An e-mail address is "user at domain", and the domain part means a specific server or set of servers, that applies even to vanity domains.)
Or the domain owner could also publish a special SPF record for each of their users where specific 3rd parties are allowed to use the domain. Like, joe@isp.com may send through isp.com's and phone.com's MTAs, and jane@isp.com may send through isp.com's and e-card.com's MTAs. SPF allows that sort of thing, although not many domain owners make use of it.
I believe there is a solution to this problem, and it will come from the open-source community. The big companies are more concerned with building monopoly power than supporting a common solution. There is a big "anti-spam industry" that is making money from the status quo. There is a lot of confusion among email recipients, who would otherwise demand a solution. There is also a lot of apathy as people have come to accept unreliable email as just a fact of modern life.
I see a situation very similar to the early 80's when the major email providers would not exchange messages with each other, using "technical difficulties" as an excuse. I see a similar solution emerging. Small companies will get together on a shared, open-source solution, and eventually the big companies give up their attempts to monopolize, and join the community.
<Sorry, no personal URLs or promotion.
See Terms of Service [webmasterworld.com]>
[edited by: tedster at 2:45 am (utc) on Mar. 27, 2006]
What I don't agree with is that SPF can or should be introduced slowly by adoption. Such a fundamental change which introduces such a significant break in intercompatibility within the email system must be a global change with an agreed timeframe. I would fully support it if it was backed up by a high-profile multiple-media advertising campaign aimed at both email users, businesses and ISPs, with a clear 'SPF date', and proper provision of advice, training and consultancy to all levels of business and government on the process of migration and ensuring continued compatibility.
Such a fundamental change which introduces such a significant break in intercompatibility within the email system must be a global change with an agreed timeframe.
Stop and think how many mail servers there are out there, running a huge number of different mail software/server OS combinations.
With reference to the OP - no change to a secure email system will ever be possible without a high-level publicity campaign - there are just to many users of email who will need re-educating for the system to be changed slowly.
I should have introduced myself a little better. I'm an electrical engineer, currently working on an open-source Framework to support email authentication methods. I am not expert in any of these methods, but I do have a good fundamental understanding of what they do, and how they will fit into an overall solution to the problems of email abuse. I believe there is a solution to these problems, and that we are almost there. I am not selling anything, and I am doing my best to remain neutral with regard to the different authentication methods. Neutrality is important because the deadlock we have seen over the last few years is largely due to lack of cooperation between different groups.
If I have any bias, it would be in favoring open-source over commercial solutions. There are situations where commercial solutions are appropriate, but if our goal is an email system that does not exclude anyone for reasons other than abuse, then open-source is the preferred model. So, I will promote open-source methods, and accommodate proprietary methods. By accommodate, I mean do everything reasonable to ensure that they will work within the Framework.
I can see there is a lot of interest in this thread from the kind of people I think should be more involved in the solution – smart enough to know that a solution is possible, but not such strong advocates of specific methods that they become part of the deadlock. I don't know if this is the right forum. We may have to move the discussion elsewhere, but here is a start.
In setting up a Framework for email authentication, the hurdles we must avoid or overcome, in order of decreasing severity include:
1) Required simultaneous upgrades in software or setup. (A "Flag Day")
2) Required widespread adoption by Agents before any benefit is realized by Recipients.
(By June 30th, all senders will ...)
3) Required widespread adoption of one method or service.
4) Changes that cause a temporary degradation in service. (Turn off your spam filters and ... )
5) Changes in current practices.
a) A well-established and standards-compliant practice.
b) A widespread but non-standardized practice. ("Misuse" of Return Address)
c) A widespread but non-compliant practice. (bad HELO name)
d) An already unacceptable practice. (open relays)
The plan is still evolving, but I think it is good enough now to avoid all but the last two, and overcoming the last two will not be difficult. Our goal is reliable delivery of email from reputable senders. In the world I envision, I will be able to freely publish my email address, and know that an email to me from anywhere in the world will get guaranteed delivery, as long as it comes from an A-rated domain (or B-rated, if that is my threshold).
If anyone shares my vision of the future, I'll continue the discussion.
