spf-discuss
[Top] [All Lists]

Re: Re: draft-schlitt-spf-02 now available and submitted to the IETF

2004-12-28 12:15:13
In 
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412272035180(_dot_)2737-100000(_at_)sokol(_dot_)elan(_dot_)net>
 "william(at)elan.net" <william(_at_)elan(_dot_)net> writes:

http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.txt

----------------------------------------------------------------------

| 1. Introduction
|
|   The current e-mail infrastructure has the property that any host
|   injecting mail into the mail system can identify itself as any domain
|   name it wants.

Hosts do not identify themselve as domains! Hosts can use domain as part 
of the host's FQDN though.. So change wording in some fashion, I suggest:

I think I'm missing something here.  Why can't hosts identify
themselves with domain names?


1. Introduction

  The current e-mail infrastructure has the property that any host
  injecting mail into the mail system can identify itself as any 
  name it wants and use any domain as part of it.

I find this suggested clarification more confusing than the original.


----------------------------------------------------------------------

| 2.4 Checking Authorization
|
|  A mail receiver can perform an SPF compliant check for each mail
|  message it receives.  This check tests the authorization of a client
|  host to inject mail with a given "MAIL FROM" identity.  This check
|  MAY also be applied to the "HELO" identity.  Typically, such checks
|  are done by a receiving MTA, but can be performed elsewhere in the
|  mail processing chain so long as the required information is available.  
|
|  Checking other identities against SPF records is NOT RECOMMENDED 
|  because there are cases that are known to give incorrect results.

I have serious problem with this. The information may be available but
it maybe old as such SPF record may have changed, also deciding on if
information is available is not quite right because you can not be sure
such "available" information is actually accurate unless its MTA doing
authorization directly. 

May I suggest that you use instead the text [...]


I've pretty much stayed out of the debates about how long an SPF
record must remain accurate.  I realize that this is a somewhat
controversial topic and I doubt that we will all be able to agree on
any given position.


I personally think it needs to remain accurate for a fair while in
order to deal with mail relays that hold the mail for a non-trivial
amount of time.  For example, if receiver.com has a secondary MX of
secondary.com, I think it is ok for receiver.com to do SPF checking on
mail relayed through secondary.com, knowing that secondary.com can be
trusted.  Domain owners who publish SPF records should be prepared for
receiver.com to goes down for a few days and have their SPF records
checked later.  The same goes for checking in spam filters or MUAs.


Right now, I think the SPF draft is silent on this subject, with only
vague hints such as the above paragraph implying that SPF records are
assumed to be valid for a while.

Should we explicitly make note of this issue?  Should we give some
guidelines about how long an SPF record must remain valid after the
email leaves the sending domain's MTA?



|  It is expected that [...]

The above sounds like policy recomendation (not appropriate for IETF
protocol document),

fixed.


|  [...] (see [RFC1983]).  Spammers often use of such archaic features
|  to try and trick MTAs into being open relays.

[...] I suggest changing this into [...]

The point of the wasn't about creating open relays as much that those
archaic "features" are currently being used maliciously and SPF
implementors need to worry about similar malicious uses.

I've changed it to:
 
  These archaic features have been maliciously used to bypass security
  systems. 


|  Software can perform the authorization after the [...]

I recommend changing this into:

This is related to the above discussion on delayed checking.  Again,
I'd like to hear opinions on this subject.



| 2.5.5  SoftFail
|  ...
|   Because the domain has discouraged any legitimate use of this IP
|   address, receivers MAY try to inform either the sender or the
|   recipient of the e-mail.  For example, the MUA could highlight the
|   SoftFail status for the receiver, or the MTA could issue an SMTP
|   reply code of 451 and the 4.3.0 DSN code, in addition to an with a
|   note the first time the message was received, but accept it the
|   second time.

In the past, it has been suggested that this paragraph be deleted.  I
thought it was important to give a functional use of the SoftFail
result.  

I have changed it to:

            Because the domain has discouraged any legitimate use of
            this IP address, receivers MAY try to inform either the
            sender or the recipient of the e-mail.  As examples, the
            recipient's MUA could highlight the SoftFail status.  Or
            the MTA could give the sender a message using a technique
            called "graylisting" where by the MTA can issue an SMTP
            reply code of 451 (4.3.0 DSN code) with a note the first
            time the message was received, but accept it the second
            time.

However, if people don't think this is an important issue, I would be
willing to just delete it.  


Ok. That is it for tonight, I'll resume reading the document and send
my comments and notes (if any) for sections 3.0 and above tomorrow.

Thank you very much for your comments.  I'm looking forward to more.


Overall good job though, better then previous drafts...

Yes, I'm feeling much better about this draft than any of the previous
drafts.  I think that many people reviewing it has helped a great
deal.


-wayne