[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] Email Spoofing
Quoting Arjen de Korte <suse+security@xxxxxxxxxxxx>:
> On Wednesday 21 July 2004 20:54, Dirk Schreiner wrote:
> > SPF causes tons of trouble and
> > no real benefit.
> SPF works for me and for about 20.000 registered domains that publish SPF
> records at the moment (http://spf.pobox.com/adoption.html). Yes, checking SPF
> records on inbound e-mail breaks forwarding, but there are ways around this.
> Remailing instead of forwarding is one of them. If your hosting provider
> doesn't support this, go to one that does or exclude their mailservers from
> SPF checks.
> There is a whole lot of difference between publishing a SPF record and
> checking for SPF on inbound mail. Publishing a SPF record doesn't necessarily
> break things. You should either have all your domain users use your servers
> for outbound mail (SASL can be used for that) or be lenient in the fallback
> (publish ?all or ~all as last parameter).
This is patently wrong.
I set up my servers to publish SPF, but not check it for incoming mail. My
customers attempted to e-mail people who used domain hosting sites that did not
specifically modify their software for SPF. My customer's e-mail did not reach
The whole problem is that the breakage is not at the publishing domain nor the
recipient, but at the middle man. The "ways around" all involve convincing the
middle man to change their software.
As the originating ISP of the e-mail, there is nothing I can do. I'd like to
see you try to explain this problem to someone who can barely operate Outlook
Express. You know what happens? I get blamed. The recipient says "I can get
e-mail from other people!" (because most domains don't publish SPF), the middle
man says "It's not my responsibility" (Try explaining the whole SPF thing to a
hosting company on a different continent), and my customer blames me.
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here