Weekly Edition
Return to the Press page
| |||||||||||||
SPF Not Poisonous to Phish (O'ReillyNet)
O'ReillyNet looks into the lack of adoption of SPF by banks, which, one would think, would welcome some protection against phishing attacks. "Wrong, says AOL's Hutzler. SPF only checks the hidden part of an email message known as the 'Return-Path' (or '821 header'). According to Hutzler, SPF completely ignores the From address (or '822 header,') which is used by phishers to 'social engineer' or dupe naïve recipients.
In other words, the wily phisher can forge the From line and still get past SPF checks--as long as his mail comes from an SPF-compliant domain listed in the Return-Path."
(Log in to post comments)
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 15:10 UTC (Wed) by eigenstr (subscriber, #5205) [Link] If you have a decent spam filter, you can use the SPF data to verify anything you please.
I had spfmilter running in monitor-only mode for a while. I saw a surprising amount of spam that would have been rejected by the spammer's own published SPF info!
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 15:13 UTC (Wed) by madscientist (subscriber, #16861) [Link] I guess I don't see why companies are hesitating about this. I mean it's a small change and easy to make, and doesn't require changes to their infrastructure at all. Further, it doesn't _conflict_ with any other schemes that are chosen in the future.
Yes, sure, it's not a panacea but it is helpful in some limited areas, and that's better than nothing! So, what's the big deal? Why is everyone so reticent? Am I missing something?
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 15:26 UTC (Wed) by job (guest, #670) [Link] SPF breaks mail forwarding, for example.
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 15:33 UTC (Wed) by csm1975 (guest, #15864) [Link] Forwarding? Throw that baby out with the bath water!
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 16:22 UTC (Wed) by ccchips (guest, #3222) [Link] Yeah....especially if it's going to a full mailbox because of a rule, and the shop you work for forces you to use a plain-vanilla Exchange server....
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 16:35 UTC (Wed) by hamjudo (subscriber, #363) [Link] What is the modern replacement for email forwarding? Running vi on /etc/aliases worked just fine in 1994. It doesn't work so well in 2004.I host email for some .org's. Every year new officers get elected, and the new slate of people get to cope with the well known email addresses and associated spam. I want many of the features of a mailing list manager like Mailman, but optimized for one reader per address. In particular, it should have a small administrative burden. I've got hundreds of aliases to replace. Mailman rewrites the headers, so SPF is happy. It's also easy for humans to trace back how and why they got the message. The administrator can add headers and/or footers to the messages, for even more reminders. This is particularly usefull for email addresses that are only active for two months out of the year, since some of the organizations host an annual event, and are dorment for most of the year. Other usefull features, the receipients can choose whether to get messages one at a time, or digests. It can be configured to strip attachments and/or drop messages over a certain size. The subscriber can change their address as they change ISPs. Email can be archived if desired, and the archives can be configured to be public or private.
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 18:32 UTC (Wed) by cpm (guest, #3554) [Link] Modern replacement for email forwarding.
Well, what I did;
virtual domains with postfix.
No forwarding.
How to do forwarding in a SPF world. Posted Sep 29, 2004 20:06 UTC (Wed) by stephen_pollei (guest, #23348) [Link] Use the Sender Rewriting Scheme is what you'd do. Plus it is RECOMMENDED that SMTP receivers record the result of SPF processing in the message headers. If an SMTP receiver chooses to do so, it MUST use the "Received-SPF" header defined in the draft rfc's. Then the people receiving email from your example.org's; can make a process the From, Sent-by, Recieved, Received-SPF, etc to make a more informed decision .
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 21:59 UTC (Wed) by iabervon (subscriber, #722) [Link] Not if the forwarding site changes the envelope sender. Then you find out that the email got to you from the forwarding site, which you may know to have check the SPF information on the email it got from some other site.
In order to authenticate the "From" header, you need some policy to decide what envelope senders and "Received" headers are suitable. You want to accept email from your bank forwarded by your forwarding service which checks SPF when the "From" header matches the forwarding service's report of the envelope sender it saw, but not email from your bank forwarded by some third party you don't recognize (or rather, you want to mark it as suspicious: your bank sent this email to some random email address, which was kind enough and clever enough to pass it on to you, the intended receipient?).
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 16:24 UTC (Wed) by copsewood (subscriber, #199) [Link] Earlier today I had to waste a couple of hours sorting out the collateral damage resulting from Bagel on my brother's computer a few hundred miles away sending out copies of itself through one on my hosted mailing lists and forging my email address on the From: header. So I'm now thinking about how soon I can tighten my own domains SPF record to end in -all , i.e. if mail coming from copsewood.net doesn't specifically come from one of my permitted relays my advice is to bounce it. Spamassassin is likely to be a better place to filter incompatibilities between the HELO or envelope From and the From: header seen in the mail client.
The other side of this is upgrading my SMTP relay to reject similarly unauthorised incoming messages from other domains. Until Sendmail and other MTA distributors include SPF rejection as a _simple_ configuration option in their standard release, e.g. by adding a one-liner to sendmail.mc, few mail administrators will touch SPF based rejection with a barge pole. Why ? Because few of us, especially those running large mail relays for corporate users, can afford to apply experimental software and approaches to live production mail feeds supporting very many users. When Sendmail, Exim, Postfix etc. make SPF rejection and tagging as simple as DNSBL based rejection (itself an experimental approach only a couple of years ago) very many mail admins will adopt this in short order.
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 16:25 UTC (Wed) by ccchips (guest, #3222) [Link] We don't solve this issue soon, the United States Post Office will make everyone pay to send mail into or out of any servers in the U.S. or territories.
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 19:56 UTC (Wed) by dvdeug (subscriber, #10998) [Link] What? The Post Office will never get the chance to charge for email; it's undue interference with protected speech and would be ruled unconstitutional in a second.
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 30, 2004 0:51 UTC (Thu) by rjamestaylor (guest, #339) [Link] By "US Post Office" you mean "Microsoft", right?
Anyone consider that Microsoft willfully put a stick in the spokes of SPF/Sender ID to delay an industry solution to the problem so that they can lobby to be the sole provider/policeman for a legislated solution?
SPF Not Poisonous to Phish (O'ReillyNet) Posted Sep 29, 2004 19:10 UTC (Wed) by pphaneuf (guest, #23480) [Link] I think the idea is that SPF should then make simpler checks like RBL work well again. It doesn't prevent phishers from forging the From header, but it then allows effective black listing.
So in effect, you'd have a "fast path" for SPF email that would only check it against blacklists (inexpensive) instead of doing the more complicated filtering like Bayes and SpamAssassin.
|
|||||||||||||