You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marc Perkel <ma...@perkel.com> on 2006/07/24 15:24:25 UTC

SPF breaks email forwarding


Michael Scheidell wrote:
>> -----Original Message-----
>> From: Graham Murray [mailto:graham@gmurray.org.uk] 
>> Sent: Monday, July 24, 2006 7:44 AM
>> To: users@spamassassin.apache.org
>> Subject: Re: New DNS Black list, White List, Yellow List
>>
>>
>> Ramprasad <ra...@netcore.co.in> writes:
>>
>>     
>>>  A lot of banks/legitimate bulk email senders  change their relay 
>>> server. Many reasons for that. The most common is that they use a 
>>> third party to relay their mails and these would keep changing
>>>       
>> Especially for banks and other high risk phishing targets, it 
>> would be much better if they did not do this. If all banks 
>> etc sent mail from a server whose IP address whose rDNS is 
>> xxx.bank.com and where xxx.bank.com resolves to the IP 
>> address from which the mail is sent, then it would 
>> considerably easier to detecting phishing and greatly improve 
>> the security for their customers.
>>     
>
> Even if the banks used spf hardfail, it would at least stop phishing to
> ISP's ans servers that knew about SPF.
>
> (you could bump SPF_HARDFAIL score to 15, or use spf to block offending
> connection right in postfix!)
>   

Except = SPF breaks email forwarding. It requires that the world change 
how email is forwarded and that's not going to happen. Thus if a bank 
has a hard fail and someone with an account on my server gets email from 
an account that is forwarded then my server sees the email as coming 
from an illegitimate source.


Re: SPF breaks email forwarding

Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 24 Jul 2006, Ramprasad wrote:

> > Except = SPF breaks email forwarding. It requires that the world
> > change how email is forwarded and that's not going to happen. Thus if
> > a bank has a hard fail and someone with an account on my server gets
> > email from an account that is forwarded then my server sees the email
> > as coming from an illegitimate source.

[snip..]

> Yes SPF breaks email forwarding, so does PTR checking ( which never was
> a great idea IMHO ). Every technique has some drawbacks. SPF has some
> but is still better than the rest
> When you want add security to an inherently insecure medium you cant say
> I will not change my servers.
> You want to put a .forward and receive mails from banks, get you mail-
> admin to use SRS. What is unreasonable in that ?

An even better way to deal with this scenario; tell your customer:

"When you forward mail thru a 3'rd party it introduces potential
security risks. Your bank is not willing to tolerate those risks and
demands (via SPF-hardfail) that their messages get delivered directly
to their customers. When you (the customer) change ISPs you need to
go to your bank-account's profile and update the e-mail address.
To maintain security and reliability of delivery you should want to
do this."

That little dialog should impress the customer with your sincerity
and their bank's commitment to security (as well as redirect any
potential complaints to the bank, the bank made us do this ;).
It's also the simple truth. The analogy would be, if you move you
file a change-of-address with your bank, you don't trust the people
at your old apartment to always forward your bank statements to
your new home.

Dave


-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Re: SPF breaks email forwarding

Posted by Michael Scheidell <sc...@secnap.net>.
Marc Perkel wrote:
> But I have no control over the servers that forward to me. Thus SPF is 
> useless.

so, again, bottom line:

SMTP is broken.  has been, phishing, forgeries, email viruses prove it.

YOU fix it without breaking something.
It can't be done.
All you can do is compromise., and ps, SPF doesn't break forwarding, its 
the other way around: forwarding breaks SPF.

If you can't come up with a proposal (something SPAML list has argued 
about for 12 years) to fix it without breaking it than there really is 
no need to attempt to educate you any further.

Turn off SMTP, firewall port 25, no more email problems.

-- 
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
scheidell@secnap.net  / 1+561-999-5000, x 1131


Re: SPF breaks email forwarding

Posted by Marc Perkel <ma...@perkel.com>.
But I have no control over the servers that forward to me. Thus SPF is 
useless.

Michael Scheidell wrote:
> Ramprasad wrote:
>> I know this is a troll subject
>>
>> Yes SPF breaks email forwarding, so does PTR checking ( which never was
>> a great idea IMHO ). Every technique has some drawbacks. SPF has some
>> but is still better than the rest
>> When you want add security to an inherently insecure medium you cant say
>> I will not change my servers.
>> You want to put a .forward and receive mails from banks, get you mail-
>> admin to use SRS. What is unreasonable in that ?
>>   
> you hit the nail on the head:
>
> If you want things to change, you have to change things.
> You cannot fix SMTP without breaking something.
>

Re: SPF breaks email forwarding

Posted by Michael Scheidell <sc...@secnap.net>.
Ramprasad wrote:
> I know this is a troll subject
>
> Yes SPF breaks email forwarding, so does PTR checking ( which never was
> a great idea IMHO ). Every technique has some drawbacks. SPF has some
> but is still better than the rest
> When you want add security to an inherently insecure medium you cant say
> I will not change my servers.
> You want to put a .forward and receive mails from banks, get you mail-
> admin to use SRS. What is unreasonable in that ? 
>
>   
you hit the nail on the head:

If you want things to change, you have to change things.
You cannot fix SMTP without breaking something.

-- 
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
scheidell@secnap.net  / 1+561-999-5000, x 1131


Re: SPF breaks email forwarding

Posted by Ramprasad <ra...@netcore.co.in>.
> Except = SPF breaks email forwarding. It requires that the world
> change how email is forwarded and that's not going to happen. Thus if
> a bank has a hard fail and someone with an account on my server gets
> email from an account that is forwarded then my server sees the email
> as coming from an illegitimate source.
> 

I know this is a troll subject

Yes SPF breaks email forwarding, so does PTR checking ( which never was
a great idea IMHO ). Every technique has some drawbacks. SPF has some
but is still better than the rest
When you want add security to an inherently insecure medium you cant say
I will not change my servers.
You want to put a .forward and receive mails from banks, get you mail-
admin to use SRS. What is unreasonable in that ? 

Thanks
Ram





Re: SPF breaks email forwarding

Posted by Graham Murray <gr...@gmurray.org.uk>.
Michael Scheidell <sc...@secnap.net> writes:

> Also, and if you require all mail servers to only take mail from
> xxx.bank.com, what good is that? doesn't that break how everyone
> receives email?

No. It just rings very loud alarm bells when an email claiming to be
from the bank comes from a server other than *.bank.com. It does, of
course, require the user to check but this can be done either
automatically by something like Spamassassin or using the Mk1 human
eyeball to examine the message headers. It would not be necessary for
the user to examine the headers of every message, just those claiming
to come from 'high risk' (to the recipient) senders.

Re: SPF breaks email forwarding

Posted by Michael Scheidell <sc...@secnap.net>.
Marc Perkel wrote:
>
>
Except = SPF breaks email forwarding. It requires that the world change 
how email is forwarded and that's not going to happen. Thus if a bank 
has a hard fail and someone with an account on my server gets email from 
an account that is forwarded then my server sees the email as coming 
from an illegitimate source.
>

This was in response to the posted who suggested the fix was to make 
banks use a defined reverse dns (which would NOT break forwarding?)

old news, see SRS.

If you want to go on a spf jihad, I suggest you do some research.

Also, and if you require all mail servers to only take mail from 
xxx.bank.com, what good is that? doesn't that break how everyone 
receives email?

What about marketing campaigns (yes, we hate them) with spf records, the 
DNS admin can coordinate email marketing campaigns.

you have to reach into every mail server in the world and so something 
like.. spf.



-- 
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
scheidell@secnap.net  / 1+561-999-5000, x 1131


Re: SPF breaks email forwarding

Posted by Magnus Holmgren <ho...@lysator.liu.se>.
On Monday 24 July 2006 15:24, Marc Perkel took the opportunity to write:
> Except = SPF breaks email forwarding. It requires that the world change
> how email is forwarded and that's not going to happen. Thus if a bank
> has a hard fail and someone with an account on my server gets email from
> an account that is forwarded then my server sees the email as coming
> from an illegitimate source.

Not entirely true. It requires you to make exceptions for mail forwarded from 
those of your users' accounts elsewhere where SRS is not yet employed (which 
is not trivial, I must admit, but not impossible either) before enforcing 
such hardfails. The users must know where they are forwarding mail from and 
to. If mail comes any other way it's illegitimate, or at least 
indistinguishable from illegitimate mail.

The problem is, of course, that it's generally not possible to know all 
outgoing MTAs of a domain, unless that domain also uses SPF, and in that case 
they also ought to know about SRS.

If the intermediate system adds a Resent-From: header it also helps. Spammers 
can't know all the ways people forward mail.

-- 
Magnus Holmgren        holmgren@lysator.liu.se
                       (No Cc of list mail needed, thanks)