spf-discuss
[Top] [All Lists]

Re: draft-schlitt-spf-02pre1 now available

2004-12-26 05:37:13
on Sun, Dec 26, 2004 at 12:17:10AM -0600, wayne wrote:

First off, I'm sorry that I haven't gotten this SPF spec out sooner, I
should have gotten this out at least a week ago. 
[...]
So, I'm sorry for leaving so little time, and during the holiday
season no less, for people to review and comment on this draft.

I'll keep it short, for the same reasons you are sorry for.

There are a couple of comments I'd like to make; especially
the first one is _very_ important IMHO.

Best wishes to everyone,
Alex


2.1:
  "Note that requirements for the domain presented in
   the EHLO and HELO commands are not strict, and software must be
   prepared for the "HELO" identity to be malformed."

Requirements _are_ strict.  RFC2821 is clear on this:
2.3.5 describes the domain name
3.6 describes the domain name again
4.1.1.1 describes the helo parameter

There can be only one of the following two:
-1- The FQDN of the host
-2- Its address

Saying that the requirements "are not strict" not only is a false
statement (IMHO!) but also validates the abuse frequently seen.

However, there is a lot of confusion and therefore there are a
lot of bad clients out there.  I suggest:

  "Note that requirements for the domain presented in the
   EHLO or HELO command are not always clear to the sending
   party, and receiving software must be prepared for the
   "HELO" identity to be malformed."


2.4:
  "If the authorization fails, then generating a non-delivery
   notification to the alleged sender is problematic as such an action
   would go against the explicit wishes of the alleged sender."

I'd prefer an addition.  It needs to be clear even for the casual
reader that this may easily result in bounces to someone other than
the sender of the message.  For instance:

  ...."wishes of the alleged sender.  Furthermore, in todays
   Internet there's a high probability the claimed sender is
   a falsification and the non-delivery notification would be
   sent not to the real sender of the original message but to
   the victim of an attack.  MTAs SHOULD NOT send non-delivery
   reports in this case."

2.5.2:
  ...."like the None result."  --> "like the None result.  The
   different response if for logging purposes only."

2.5.6:
   Unless the 450 is really THE number to use, I suggest:
  ...."MUST use a 450 reply"... --> "MUST use a 4xx series reply"

2.5.7:
   dito