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
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?
What do you mean by "origin" and "fake"?
For instance, sometimes I use my local ISP's outgoing mailserver to send mail for my domain name. Thus, a message addressed as coming from my_name@my_domain.com might actually have been originated from the mail.my_cable_isp.com mailserver.
Would this be regarded as "fake" and thus rejected?
Eliz.
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?
From my understanding and reading of RFCs and such, this is not 100% possible with the current SMTP/POP protocols.
SPF is one way of determining origin of email.
What do you mean by "origin" and "fake"?
By "origin" I was referring to "sender" and by "fake" I meant the faking of a "from" field in an email address.
I note your point about using a local ISP SMTP server, but presumably that could be resolved by some form of password process, whereby you would actually login to your domains SMTP service using your local ISP only as a network connection?
That's what I do (remotely login to my main ISP mailserver).
My post concerns the fact that, for example, I can send you an email now that looks, from the "from" header, to have come from service@ eBay.com
I'm just surprised that there isn't a simple mechanism for stopping that.
TJ
I'm just surprised that there isn't a simple mechanism for stopping that.
There is, it is called SPF (Sender Policy Framework).
From my understanding and reading of RFCs and such, this is not 100% possible with the current SMTP/POP protocols.
OK, and I guess that changing the SMTP/POP protocol would be about as practical as the World changing the way that phone numbers work.
Seems strange to me, that we have all this technology, and yet you still have no way of determining whether or not I am who I say I am.
At least 90% of my spam/phishing emails come from fake "from" header addresses.
There is, it is called SPF (Sender Policy Framework).
Thanks, I'll take a look at that.
TJ
Can I implement now, or does this SPF system require that all ISP's ultimately subscribe?
Thanks,
TJ
Thanks, I'll take a look at that.
As of 2004 October, AOL and MSN check for SPF. If you don't have an SPF Record, there is a good chance that your email to @aol and @hotmail accounts is not getting through.
<added> by the way SPF isn't the answer either, that is just AOL trying to impose a half baked idea on everyone else
[edited by: jatar_k at 3:58 pm (utc) on Mar. 21, 2006]
You can implement anytime, as long as you control your mail servers.
True. If you don't control your mail servers, an email to your provider about SPF would be in order. If you are not sure if your provider has SPF installed, run a DNS Report [dnsreport.com] which will tell you whether or not it is there.
<added>
that is just AOL trying to impose a half baked idea on everyone else.
Actually it is not just AOL. It is MSN and quite a few other major ISPs.
Or something similar. Adam, why is SPF a half-baked idea in your view? Are there alternatives?
if your mail servers use multiple RBL's and some intelligent patterns with spamassassin and you could get the same (probably better) result.
Anything can be spoofed too. So you use a single SPF'ed server as your through point for large amounts of spam, would probably work. Just keep switchin servers everytime they catch on.
both AOL and hotmail still let through tons of spam and have made it harder to get legitimate emails through so I don't see it as doing anything but making life difficult because they are full of their own supposed intelligence.
Over 1.7 million domains have published SPF records (as of November 2005).
[edited by: pageoneresults at 4:13 pm (utc) on Mar. 21, 2006]
really not many is it?
Not in the overall scheme of things, but still a significant number of people.
I just can't believe that with all the technology and software "intelligence" we have that we can't get rid of this problem altogether.
I'm not talking so much about spam, I'm also thinking specifically about the ease with which I can send you an email and make it look like it came from someone else.
Some well-known names protected by SPF today include:AOL.com
Altavista.com
DynDNS.org
eOnline.com
Earthlink.net
Google.com
GNU.org
LiveJournal.com
MotleyFool.com
OReilly.com
Oxford.ac.uk
PairNIC.com
Perl.org
PhilZimmermann.com
SAP.com
Spamhaus.org
Symantec.com
Ticketmaster.com
w3.org
Antispam and MTA vendors that support SPF
Sendmail, Sophos, Symantec, GFI Software, Declude Junkmail, Brightmail, IronPort, Ciphertrust, MailArmory, MailFrontier, Roaring Penguin Software, Atlantic Sky, Communigate Pro, and others.
While it may not be a 100% solution for email forgery, it is definitely a start. I'm in support of anything that looks like it has a strong following and will help me to fight this type of email spoofing. It is just one of many things you can implement to fight back.
[edited by: pageoneresults at 4:15 pm (utc) on Mar. 21, 2006]
Not in the overall scheme of things, but still a significant number of people.
It's not the total number but, who and what makes up that total number. :)
Also, I am on the SPF mailing lists. There is definitely activity going on and SPF is being aggressively pursued.
we used spamassassin, built some custom filters, spent a few days tweaking, then spent a week or so monitoring
we had near 0 spam come through. Everything that we got filtered that was a legit email had a problem and looked like spam in some way.
so did SPF help, no, did a little agressive filtering help, 100%. Did using RBLs help, not at all because we were doing business with china and it seems that every mail server there is on an RBL somewhere.
we had near 0 spam come through.
Since we implemented SPF in 2004 October, the @example.com email spoofing came to a halt.
We sit behind a bank of Barracuda Firewalls and they do one hell of a job filtering out all the spam. That doesn't stop me from adding more to the mix such as SPF.
Adam, are you available to configure everyone's servers for them? Not all of us have the level of genius that you do so we have to work with what we've got available to us. :)
lmao, I don't think that is the case. I worked with a very adept admin, it was combined effort.
I am honestly surprised it has worked for you. I haven't heard of a single case where it was effective at anything near an acceptable percentage.
Have you evaluated the number of false recognitions? or did you previously decide it didn't matter?
I haven't heard of a single case where it was effective at anything near an acceptable percentage.
I think a lot of this comes down to how the SPF Record is configured. Also, I've seen a few SPF files that were not configured properly. There is now an SPF Testing Tool available to check for this.
In regards to your other question...
Have you evaluated the number of false recognitions? or did you previously decide it didn't matter?
I'd have to defer that to my Server Admins. I haven't really given much thought to this since we haven't been subjected to the spoofing issues anymore. You know, let me back up a bit, there may be one or two that get through every now and then but I still think we are in the 98% range of effectiveness.
absolutely
most of that is because it has been so weak for so long. Remember it isn't a standard yet. I tried some testing tools originally when we set it up, they were ok. It has been a couple years now.
I am glad TJ is the OP, I thought we were going totally OT. ;)
Yes, it is that hard
SPF isn't the answer
Yes, it requires good admins to implement good protection
are ISPs and mass webmail providers any good at it, no
if you own/operate your own mail servers you can do a lot of things to protect your users and SPF is only one of them
I am also interested in what else you use P1, I can't hardly believe that SPF alone is responsible for your success.
SPF checks will find that mywebsite.foo is not the same as somedomain.foo and reject the email, despite the fact that it was the clear wish of user_a to send the email, they just used a different server.
I can't hardly believe that SPF alone is responsible for your success.
Well, since I purchased my own servers almost a year ago and managed to get set up with an excellent group here in Tustin, email issues have been almost non-existent. I do know that the Barracuda Firewalls are mostly responsible for the prevention of spam to our email users. When I brought everything over from the old servers, all the zone files came over too which of course included SPF, etc.
I only have a basic knowledge of how this all works and am learning more every day. And remember, I'm a Windows person so things work a little differently for me. :)
I won't bug you about the win thing this time P1 ;)
I think a bit more discussion about SPF might be in order. The comments I see above may not be 100% accurate in regards to third party mail providers. I'm checking into this and I've also sent an invite to the SPF crew to see if someone can help clear some things up for us.
I am glad TJ is the OP, I thought we were going totally OT
I'm not sure how I'm meant to take that ;-)
</OT>
If SPF isn't the full answer, do we need to ditch POP/SMTP and move over to something else instead?
if you put all of your eggs in the SPF basket then you are going to get burned
>> POP/SMTP
what options are there, I guess IMAP instead of POP but aside from that, not sure
That may force spammers to change tactics (slightly) but it won't put them out of business.
Have I forgotten something or missed something significant?
Kaled.
Explain how SPF works in 1 minute.Domains use public records (DNS) to direct requests for different services (web, email, etc.) to the machines that perform those services. All domains already publish email (MX) records to tell the world what machines receive mail for the domain.
SPF works by domains publishing "reverse MX" records to tell the world what machines send mail from the domain. When receiving a message from a domain, the recipient can check those records to make sure mail is coming from where it should be coming from.
With SPF, those "reverse MX" records are easy to publish: one line in DNS is all it takes.
Keep in mind, that SPF Records are domain specific. If you are using SPF, you should also have SPF Records for sub-domains as they are treated differently.
