spf-discuss
[Top] [All Lists]

Re: [spf-discuss] promoting softfail to fail

2005-08-27 07:20:53

----- Original Message -----
From: "David" <david(_at_)ols(_dot_)es>


Hi !!

Now most providers publish softfail instead fail to avoid problems
with forwarding. One way to detect if a message has not been forwarded
is to check if the envelope recipient is in the To: header field, if
the envelope recipient is in the To: header field then the message has
not been forwarded and if not nothing could be assured. This could be
used to promote a softfail to fail, but there is no way to know if the
domain owner has published a softfail because he don't want to have
problems with forwarding or because he want to allow some users to
break the policy. As i remeber softfail was mainly created to avoid
problems wiht forwarding but is there any other use for it ? should
domain owners use another policies for the other cases ?

We need to remove "policy" concepts from a technical algorithm?

First, this is a payload suggestion.  Only those people using
SPF the POST SMTP level can do this.  Those with a DATA hook or sink
can do it also.  I am personally resistance to any PAYLOAD idea that
doesn't have a high payoff in its result.

Second, the 2822.TO header is not a requirement.  Only a 822.TO header
is a requirement.  But that requirement is suggestive because some
systems may actually regenerate the Destination Field where no required
x822 fields are present.  In fact, the last I checked, the HOTMAIL server
will throw away your mail if it has no 822 headers.  That's a rare and new
behavior that I wish does not catch on.

Anyway, much of this depends of the type of "Forwarding" in action. i.e. its
a relay or reroute style.  But it can be a direct MSA type of forwarding
where this is no multiple hops.  The former is the IP forwarding issues that
people have where is some middle ware involved.

Currently,  the closest thing you have to detecting a FORWARD is the
relay/reroute type which is counting the number of hops (Received: lines).

Another way is to check MIX policies:

    SPF(MAILFROM) --> SOFTFAIL
    SPF(HELO)     --> PASS

This is an example of a MIX POLICY which can probably lend a hand at making
some kind of "this might be a forward situation" assertion.  The problem is
that you don't know the relationship between the responsible domain and the
relay machine.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com