Do not spoof me

On Thu, 2004-12-09 at 05:05, Alex van den Bogaerdt wrote:
> On Thu, Dec 09, 2004 at 12:06:13PM +0000, David Woodhouse wrote:
> > 
> > On Thu, 2004-12-09 at 10:40 +0100, Alex van den Bogaerdt wrote:
> > > Here you say it again.  SPF does NOT say "no forwarding".
> > > SPF _does_ say: "No spoofing my name".
> > 
> > You're arguing over nomenclature, which is pointless.
> 
> That is your opinion.  For me, the difference is quite relevant.
> 
> > Alex, you're right then SPF advocates do indeed phrase it as "No
> > spoofing my name". But John is also right because what they _mean_ by
> > that is "no forwarding", since normal forwarding does involve, and
> > always has involved, the behaviour which SPF advocates now want to call
> > "spoofing".
> 
> If you know what "SPF advocates" mean to say, why do most (if not
> all) disagree with your opinion?
> 
> Could it be that you are spreading your opinion, disguised as theirs?
> 
> 
> I think that the SPF community is well aware of the fact that there
> is a number of people using a way of forwarding that will become
> impossible in the future (if and when SPF is deployed).  I don't
> think all of them consider this way of forwarding "normal".  Perhaps
> most of them agree on this method being "in use", but that doesn't
> mean it is THE right way.
> 
> There are alternatives. You just don't want to accept them because
> YOU think they are unnecessary alternatives.  Newsflash: Others
> have opinions to and they may not agree with yours.

There are two flaws with respect to this "do not spoof me" assertion. 
One, there are ways to prevent the SPF record from being discovered from
sub-domains negating supposed spoof protections.  Two, there is no way
to know if the recipient of a message from such an SPF-domain will be
forwarding the message.  These forwarded accounts are utilized by a high
enough percentage of the populous as to cause inordinate support issues
should this mail become categorically rejected and perhaps lost.

One of the alternatives offered by SPF for this problem is the use of
the '?all' statement.  In other words, SPF becomes a scheme of graduated
levels of authorization and, of course, with the continuation of
spoofing.  This also means any shared MTA authorized by the SPF record
also allows the SPF-domain to now be spoofed where the message obtains
the highest level of authorization.

Deployable "do not spoof me" solutions that also have a chance of
actually working are being developed within the MASS wg. 

http://mipassoc.org/mass/

-Doug