Subject: [spfbis] Comments on RFC 4408

From: SM <[email-masked]>
Date: Wed, 08 Feb 2012 08:24:17 -0800

Hello,

The following comments are on RFC 4408.  Some of them may be out of 
scope.  I avoided getting into editorial comments as far as 
possible.  The RFC 2119 key words should be reviewed.

The IESG Note mentions that "Sender ID experiment may use DNS records 
that may have been created for the current SPF experiment or earlier 
versions in this set of experiments.  Depending on the content of the 
record, this may mean that Sender-ID heuristics would be applied 
incorrectly to a message.  Depending on the actions associated by the 
recipient with those heuristics, the message may not be delivered or 
may be discarded on receipt".

I suggest that the WG considers the above.

The IESG Note also mentions that "Participants publishing SPF 
experiment DNS records should consider the advice given in section 
3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 
records to avoid the conflict".

I suggest using data gathered to determine whether the advice was followed.

"Participants in the Sender-ID experiment need to be aware that the 
way Resent-* header fields are used will result in failure to receive 
legitimate email when interacting with standards-compliant systems 
(specifically automatic forwarders which comply with the standards by 
not adding Resent-* headers, and systems which comply with RFC 822 
but have not yet implemented RFC 2822 Resent-* semantics)".

I suggest taking the above into consideration for the "conclusion" document.

In Section 2.4:

   "When a mail receiver decides to perform an SPF check, it MUST use a
    correctly-implemented check_host() function (Section 4) evaluated
    with the correct parameters".

RFC 2119 key words should be used for interoperability.  A 
requirement to use a correctly-implemented function with correct 
parameters comes out as stating the obvious.

In Section 2.5:

   "The authorization check SHOULD be performed during the processing of the
    SMTP transaction that sends the mail."

The "that sends the mail" is superfluous in the above.

In Section 2.5.4:

   "If the information does not originate with the checking software, it
    should be made clear that the text is provided by the sender's domain.
    For example:

        550-5.7.1 SPF MAIL FROM check failed:
        550-5.7.1 The domain example.com explains:
        550 5.7.1 Please see http://www.example.com/mailpolicy.html"

It is better not to document the multiline response as it comes out 
as a recommendation.

In Section 2.5.5:

   'The domain owner wants to discourage the use of this host and thus
    desires limited feedback when a "SoftFail" result occurs.'

I suggest avoiding terms such as "domain owner".

   'For example, the recipient's Mail User Agent (MUA) could highlight the
    "SoftFail" status, or the receiving MTA could give the sender a
    message using a technique called "greylisting" whereby the MTA can
    issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
    first time the message is received, but accept it the second time.'

It is better not to encourage a "greylisting" technique in this 
specification as it is more of an "antispam" technique than one about 
"sender policy".

In Section 2.5.6:

   "If the message is rejected during the SMTP transaction for this reason,
    the software SHOULD use an SMTP reply code of 451 and, if supported,
    the 4.4.3 DSN code."

The "4.4.3" is an extended status code.  It is not a "DNS code".  The 
extended status code used is incorrect.

In Section 3.1.1:

   "It is recognized that the current practice (using a TXT record) is
    not optimal, but it is necessary because there are a number of DNS
    server and resolver implementations in common use that cannot handle
    the new RR type.  The two-record-type scheme provides a forward path
    to the better solution of using an RR type reserved for this purpose.

    An SPF-compliant domain name SHOULD have SPF records of both RR
    types."

This "SHOULD" is not being followed.

In Section 3.1.4:

   "The published SPF record for a given domain name SHOULD remain small
    enough that the results of a query for it will fit within 512 octets."

   "Records that are too long to fit in a single UDP packet MAY be
    silently ignored by SPF clients."

I suggest either setting a maximum size for the record or 
reconsidering the text about ignoring a SPF record.  BTW, some 
implementation encountered issues with DNS TXT record parsing.

The example in Section 3.1.5 about wildcard records should be rewritten.

In Section 5.4:

   'Note regarding implicit MXs: If the <target-name> has no MX records,
    check_host() MUST NOT pretend the target is its single MX, and MUST
    NOT default to an A lookup on the <target-name> directly.  This
    behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
    Section 5.  If such behavior is desired, the publisher should specify
    an "a" directive.'

This paragraph should be updated to cover IPv6.

In Section 5.5:

   "If a DNS error occurs while doing an A RR lookup, then that
    domain name is skipped and the search continues."

AAAA RRs should also be taken into account.

In Section 7:

   'Other keys may be defined by SPF clients.  Until a new key name
    becomes widely accepted, new key names should start with "x-".'

"x-" is being deprecated.

   "SPF clients MUST make sure that the Received-SPF header field does
    not contain invalid characters, is not excessively long, and does not
    contain malicious data that has been provided by the sender."

The above requirement is subject to interpretation.

In Section 9.3:

  '[RFC1123] and [RFC2821] describe this action as an "alias"
   rather than a "mail list".'

The mail transport material in RFC 1123 has been replaced in RFC 5321.

In Section 10.4:

   "Another means to verify the identity of individual users is
    message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851])."

The term generally used is "digital signatures".

The normative references should be updated to RFC 5321, RFC 5322 and 
RFC 5234.  The informative reference for SUBMIT should be updated to 
RFC 6409.  The references for RMX, DMP, Vixie and Green should be 
removed if there aren't stable references to the material.

Regards,
-sm

---

From: Philip Gladstone <[email-masked]>
Date: Wed, 08 Feb 2012 12:27:02 -0500

On 2/8/2012 11:24 AM, SM wrote:
> experiment DNS records should consider the advice given in section 3.4 
> of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to 
> avoid the conflict". 

In my list of collected records, I have 578 v=spf2 records. This is an 
underestimate as it turns out that I only saved the *first* spf record 
if there were multiple (Yes, my bad). However, if we assume that the 
ordering of TXT RRs is random, then this would indicate that maybe 1200 
domains have both records (out of 278,000 which have at least one).

Philip

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 22:09:30 -0500

On Wednesday, February 08, 2012 08:24:17 AM SM wrote:
...
> The example in Section 3.1.5 about wildcard records should be rewritten.
...

This is a proposed solution to an issue, not an issue.  I think while we are 
collecting issues, it's important to have a clear statement of what problem in 
RFC 4408 has been found that needs to be solved.

Scott K