yep, I tried to implement SPF a number of times in a few different mail systems from Postfix to Sendmail, and kinda had alot of hiccups, mostly around false positives or loss of email etc. I think we're going to have another look at it soon as the general level of SPAM etc seems to be growing by the day. -- Cheers Dan Juha Saarinen wrote:

Before advocating and implementing SPF, it'd be worth admins' while to read up on the problems of that technology.

Here's a workaround for forwarding using Exim for instance:

www.infradead.org/rpr.html

Reading through all of that, you have to wonder if SPF isn't creating more problems than it solves.

Steve Phillips wrote:

On Thu, 14 Jul 2005, Dan Clark wrote:

...

I think we're going to have another look at it soon as the general level of SPAM etc seems to be growing by the day.

NOTE: SPF is NOT an anti-spam methodology, it is designed to add a simplistic way to prevent forging of e-mail From: addresses. (the envelope sender to be even more specific)

As a result, implementing SPF will NOT stop the growth of SPAM, it may assist in reducing the number of people that get suckered in by phishing schemes.

It might - IF some local financial organisations adopted SPF: $ host -t txt asb.co.nz asb.co.nz text "ASB Bank, Auckland, NZ" $ host -t txt asbbank.co.nz asbbank.co.nz text "ASB Bank, Auckland, NZ" $ host -t txt westpac.co.nz $ host -t txt westpac.com.au $ host -t txt nbnz.co.nz nbnz.co.nz text "National Bank of New Zealand" $ host -t txt kiwibak.co.nz Host kiwibak.co.nz not found: 3(NXDOMAIN) $ host -t txt kiwibank.co.nz kiwibank.co.nz text "New Zealand Post Limited" And so forth. In fact, out of a small sample of finance organisations in NZ the only one I can find with SPF records is americanexpress (see aexp.com). Although it does reduce phishing from Paypal etc; but the CitiBank and BofA and so forth phishing is unlikely to ever work in NZ because the average NZer won't have an account with them. SPF doesn't solve spam, though. Unauthorised "hijacking" of domains, on the other hand, it might help reduce the occurence of. aj

Reading through all of that, you have to wonder if SPF isn't creating more problems than it solves. Juha

But that's what constraints are all about... It's very hard to increase restrictions without increasing complexity, just ask the security industry. I subscribe to one of the spf mailing lists (http://archives.listbox.com/spf-help/current/) and it's showing just how hard it is for a lot of IT/ISP teams to get a grip on it. The biggest headache for users, is that they will need to use the right email address in the FROM: field and then the one they want everyone to send to in the REPLY-TO: field, otherwise anyone who had multiple (ISP) email address, but only sends via a single smtp server (e.g. their current ISP). I'm a classic example, I'm using craig dot humphrey dot work at paradise dot net dot nz for this list, while I'm at work, but because Paradise wont let me send email via their smtp server, unless I'm directly connected to their network [e.g. dial-up, jetstream, etc], I have to send via the ISP I'm currently connected to. Which is even more interesting, since it's Global-Gateway. Fortunately, Xtra's smtp server is happy to "relay" for us, but if Xtra ever change their spf record from ?all to -all, I'm poked. I don't have a user at xtra dot co dot nz address to use in the from field. ISP's are going to need to open their smtp servers up to authenticated relaying from outside their networks. BTW I see that no one has mentioned that Microsoft are going to enforce spf for Hotmail (http://www.geek.com/news/geeknews/2005Jun/gee20050624031084.htm) if you don't publish spf records, then your email to Hotmail will be marked as spam. I'm guessing that this is a precursor to enforcing it for all Microsoft controlled domains. Though presumably they will have trouble enforcing it for Microsoft.com, unless they're already prepping the next version of Exchange to include spf/senderid support :) In my opinion, SPF is not a silver bullet, but it's got the potential to help. But it's hampered by the need for everyone to use SPF aware mail servers and the (increasing) complexity of SPF records (the mailing list is full of "the wizards over-simply and are often simply wrong".) Oh and I see that MS's SenderID wizard outputs SPF v1 records, not SPF v2 which is what SenderID is supposed to be :) Until everyone implements SPF records, Spammers using spoofed domains will just work their way around non-SPF'ed domains. Until everyone implements SPF aware mail servers, spammers will end up targeting users who aren't behind SPF aware mail servers. Just my 2c..... Nothing like a Friday morning rant... I need a V.... Later'ish Craig

-----Original Message----- From: Simon Byrnand [mailto:simon(a)igrin.co.nz]

[snip snip]

Do paradise not allow the use of SMTP auth ? To be honest I can only ever see SPF becoming a viable solution if everybody who uses their email address in a "roaming" fashion uses SMTP auth. We've provided SMTP auth for a couple of years now, and it helps solve a lot of problems.

I've been testing it every so often for the last few years (I've been with Paradise for about 5 years), but never got it working. Never took it up with their helpdesk cause it's wasn't much of a bother. Perhaps it's time I did....

The classic ones being users switching back and forth between GPRS/Mobile Jetstream and a normal dialup on a laptop, and also using their email address from Jetstream with another ISP (often when they take their computer into work) enabling SMTP auth and using our smtp server solves all those problems in one stroke.

Yeah, I have this kind of issue. Multiple email addresses with multiple ISP's (and others like mail.com) and then switching between the office (Global Gateway), MobileJetstream (Xtra), JetStream (Xtra) and Dial-up (Paradise). I think Xtra are now supporting SMTP auth on a separate host (not their normal SMTP/POP3 servers I think), but until Paradise does...

My brain might not be fully engaged yet this morning, but what does xtra's SPF records have to do with you sending using a paradise email address ? Surely its paradise adding an spf record that would cause you problems relaying through xtra's mail server ?

Irk! Yes, you're right, since it's the domain in the MAIL FROM (SMTP command) address that is checked. Hmm... Reading (http://spf.pobox.com/faq.html#whichfield) suggests that the FROM: field should not be checked. Still, I guess it's only a matter of time before Xtra tidy up who can relay through them.

Yep. If you do a survey of various ISP's SMTP servers, you'll see that quite a number support it now, (with a few notable big name exceptions :) and regardless of whether SPF gets adopted I hope all ISP's see the light and start moving towards providing SMTP auth.... certainly they shouldn't start publishing strict SPF records without SMTP auth as a lot of their customers will get left out in the cold with no way to send their email reliably...

Regards, Simon

Agreed. A remarkable number aren't yet publishing SPF records at all... I guess everyone is sitting on the fence until it's either fully ratified or their hand is forced (e.g. Hotmail enforcing SPF). Later'ish Craig

Craig Humphrey wrote:

...

But that's what constraints are all about...

Creating more problems than they solve?

Nearly :) It's about the steep learning curve. Once the dust settles on SPF (and/or SenderID), the knowledge on how to set it up correctly (and hopefully simply) will start to disseminate more quickly. At that point, the problems start to go away. It's not too different from the old days when just about every SMTP server out there was happy to relay. There was a time when this was thought to be a "Good Thing" (tm). Times have changed, and when SMTP servers stopped relaying (well, all the responsibly maintained ones...) I wonder how many users weren't able to send emails....

Good luck with explaining that (and SPF) to customers paying you to deliver emails.

-- Juha

Fortunately I don't have to. We don't have customers pay us to deliver email. We're just a firm that needs to send our own emails, do our best to protect our users from SPAM (viri, etc) and be responsible netizins. So I'll certainly be putting SPF records in our DNS and pressing our mail server vendor to support SPF. If I was working for a firm that had customers paying to us to deliver email, then I'd probably be doing my darndest to research SPF (and probably SenderID), learn how best use SPF to protect our clients from SPAM (at least the domain spoofed kind) and how best to explain the ramifications of SPF to my clients. ISP's who relay outbound email for their clients are probably going to have some very complex SPF records if they want it to be tight. Later'ish Craig