ietf-mxcomp
[Top] [All Lists]

TECH-DOC: Re: I-D ACTION:draft-ietf-marid-mailfrom-00.txt

2004-09-17 00:05:02

I have a few some comments regarding:

http://www.ietf.org/internet-drafts/draft-ietf-marid-mailfrom-00.txt


In "2.4  Interpreting the Result,"  add a summary of the possible results
for better reading:

| 2.4  Interpreting the Result
|
|   The check_host() function returns one of seven (eight?) following
results, some with
|   additional information:
|
|       Neutral
|       Pass
|       Fail
|       SoftFail
|       None
|       TempError
|       PermError
|
|   This section describes how software that
|   performs the authorization must interpret the results.  If the check
|   is being performed during the SMTP mail transaction, it also
|   describes how to respond.

Relaxed Provisions:

I have mentioned this a few times.  I believe that SPF is partially
defeating the purpuse of its goal by having unrestricted relaxed provisions
for Neutral and SoftFail results with no functional specification on how to
deal with it.   In my opinion, this will plaque SPF until inevitably the
problems it present is better  recognized in mass practice and it is finally
addressed in the future. Unfortunately, by then it might be too late as
there will be far too many legacy systems in place.  Lets not close current
SMTP shortcomings by opening new ones.

The key issue is that the relaxed provisions should be limited in usage.
Although, section 2.4.4 states:

        "This value (softfail) is used by domains as an intermediate state
         during roll-out of publishing records."

I believe the options opens a hole in SPF that should not be there in the
first place.  While a good intention system my play by the rules and
eventually gets its SPF setup right when rollout is complete,  I see this
being abused and will become a source for SPF spoofers.

I don't think we need a technical method to control this. Rather what is
simply required is a functional description with strong statement for usage
limitations with a strong indication that SPF clients MAY implement
expiration concepts.

Suggested addition/changes to document regarding Neutral and SoftFail:

| 2.4.1  Neutral
|
|    A Neutral result MUST be treated exactly like a None result.
|
|    See "2.5 Handling Relaxed Provisions (Neutral and SoftFail)"


| 2.4.4  SoftFail
|
|    A SoftFail result should be treated as somewhere between a Fail and a
|    Neutral.  This value is used by domains as an intermediate state
|    during roll-out of publishing records.  The domain believes the host
|    isn't authorized but isn't willing to make that strong of a
|    statement.  Receiving software SHOULD NOT reject the message based on
|    this result, but MAY subject the message to closer scrutiny.
|
|    See "2.5 Handling Relaxed Provisions (Neutral and SoftFail)"


|  2.5  Handling Relaxed Provisions (Neutral and SoftFail)
|
|     The relaxed SPF results, Neutral and SoftFail, are considered
|     temporary and time limited domain policies. They are intended to be
|     used as intermediate states during roll-out periods.
|
|     Once the roll-out is complete, the policy result should be changed
|     to provide strong pass or fail results.
|
|     Since this is an area where possible exploitable may occurred, SPF
|     offers implementators the option to impose expiration periods for
|     continued usage of relaxed provisions or results.
|
|     The expiration period starts with the first usage of the SPF domain
|     resulting with a relaxed provision.
|
|     The recommended time period is: 3-6 months.
|
|       SPF clients who wish to implement an expiration method could
|       use a simple database to record the first time usage. Subsequent
|       mail transactions with relaxed SPF results can be checked for
|       expiration.
|
|
|       Example pseudo code with example expiration responses:
|
|         spf-result = check_host()
|
|         if spf-result in [Neutral, SoftFail] then
|
|            Expired = record_check_host_expiration()
|
|            if Expired then
|
|               550-SPF Mail From check failed: Expired
|               550 The domain example.com usage SPF relaxed results has
expired.
|
|            else
|
|               250 Temporary SPF acceptance. Expiration Date:
get_expiration_date()
|

What is important to understand is that serious SPF domains will take this
usage with the added knowledge that it will be temporary, thus they must
work at getting their SPF policy and network operations in order.  Without a
specific specification addressing relaxed provisions,  it will provided
irresponsible and unrestricted usage and worst, provide a real loophole for
SPF spoofers to exploit.

Thanks

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office







<Prev in Thread] Current Thread [Next in Thread>