Subject: I-D ACTION:draft-ietf-marid-mailfrom-00.txt

From: [email-masked]
Date: Thu, 16 Sep 2004 15:39:47 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF.

	Title		: Authorizing Use of Domains in MAIL FROM
	Author(s)	: M. Lentczner, M. Wong
	Filename	: draft-ietf-marid-mailfrom-00.txt
	Pages		: 11
	Date		: 2004-9-16
	
Mail on the Internet can be forged in a number of ways.  In
   particular, existing protocols place no restriction in what a sending
   host can use as the reverse-path of a message.  This document
   describes a protocol whereby a domain can explicitly authorize the
   hosts that are allowed to use its domain name in a reverse-path, and
   a way for receiving hosts to check such authorization.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marid-mailfrom-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-marid-mailfrom-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-marid-mailfrom-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 17 Sep 2004 03:01:42 -0400

I have a few some comments regarding:

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