In <200505080333(_dot_)58079(_dot_)bulk(_at_)mehnle(_dot_)net> Julian Mehnle
<bulk(_at_)mehnle(_dot_)net> writes:
Besides, I found two issues I could not directly turn into patches:
1) Section 2.4, "Checking Authorization":
| While invalid, malformed, or non-existent domains cause SPF checks to
| return "none" because no SPF record can be found, it has long been
| the policy of many MTAs to reject e-mail from such domains,
| especially in the MAIL FROM. In order to prevent the circumvention
| of SPF records, rejecting e-mail from invalid domains should be
| considered.
What SPF records could be circumvented by using invalid domains in any of
the identities? IMO that doesn't make sense. The only "exploit" I can
see in this is a way to avoid a "None" result due to he use of a
non-SPF-equipped domain, and instead get a "None" result due to the use of
an invalid (invalid or non-existent) domain. Big deal. (The entire issue
of how to handle SPF(non-existent-domain) is still not really resolved
anyway.)
Well, you may have missed it, but in another post, I said:
note: in -01pre4, this last sentence was changed to:
In order to prevent the circumvention
of SPF records, rejecting e-mail from invalid domains should be
considered.
This recommendation to reject invalid domains was suggested by the
folks on the IETF namedroppers list as part of the remove of zone
cuts. One of the things that zone cuts allowed is a way for domain
owners to have some say in the use of non-existent subdomains of thier
domain.
Yes, this is reciever policy, but we make other recommendations about
receiver policies when they have ramifications on the sender policy.
For example, we say that Neutral MUST be treated the same as None.
2) Section 12.2, "The Received-SPF mail header":
| Per [RFC3864], the "Received-SPF:" header field is added to the IANA
| Permanent Message Header Field Registry. The following is the
| registration template:
|
| Header field name: Received-SPF
| Applicable protocol: mail
| Status: standard
| Author/Change controller: wayne(_at_)schlitt(_dot_)net
| Specification document(s): this Internet Draft
| (Note to RFC Editor: Replace this with RFC YYYY (RFC number of
| this spec))
| Related information: http://spf.mehnle.net/
I guess this registration template is still in its infant stages, right?
If not: what's the point of referring to http://spf.mehnle.net here?
As Frank points out, this was largely stuff that he supplied.
--- draft-schlitt-spf-classic-01pre5.xml 2005-05-06 00:35:37.000000000
+0200
+++ draft-schlitt-spf-classic-01pre5+mehnle.xml 2005-05-08
03:07:56.903923982 +0200
@@ -231,5 +231,5 @@
described in <xref target="records"/>. This record
authorizes the use of the domain name in the "HELO" and
- "MAIL FROM" identity, by some sending MTAs, and not by
+ "MAIL FROM" identities, by some sending MTAs, and not by
others.
</t>
@@ -298,5 +298,5 @@
formed domain name. For example, if the reverse-path was
null, then the EHLO/HELO domain is used, with its associated
- problems. (see <xref target="helo-ident" />) In these
+ problems (see <xref target="helo-ident"/>). In these
cases, check_host() is defined in <xref target="initial"/>
to return a "None" result.
@@ -324,5 +324,5 @@
checks to return "none" because no SPF record can be found,
it has long been the policy of many MTAs to reject e-mail
- from such domains, especially in the MAIL FROM. In order to
+ from such domains, especially in the "MAIL FROM". In order to
prevent the circumvention of SPF records, rejecting e-mail
from invalid domains should be considered.
all fixed.
@@ -492,5 +492,5 @@
<figure>
<artwork>
- example.com. IN TXT "v=spf1 +mx a:colo.example.com -all"
+ example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. IN TXT "v=spf1 a -all"
</artwork>
#
# You had removed "/28" from the end of line 494, probably due to line
# length limits. But that made the example inconsistent with the other
# examples in section 3. Either change all of them, or none.
Your guess is correct, and you are right. I did a s/IN TXT/TXT/
instead.
Good catch.
@@ -1839,5 +1839,5 @@
<t>
Forwarding services take mail that is received at a mailbox
- and directs it to some external mailbox. At the time of this
+ and direct it to some external mailbox. At the time of this
writing, the near-universal practice of such services is to
use the original "MAIL FROM" of a message when re-injecting
#
# You had done s/direct/directs/, but this is grammatically wrong.
fixed.
@@ -1883,5 +1883,5 @@
While this requires an extra DNS lookup, this only
happens when the e-mail would otherwise be rejected
- as not coming from a known, good source.
+ as not coming from a known good source.
Ok.
@@ -1954,5 +1954,5 @@
domains, such as sending of bulk mail, may have to adjust
their setup in light of the authorization check described in
- this document. If the "MAIL FROM" used for such e-mail uses
+ this document. If the "MAIL FROM" identity used for such e-mail
uses
the domain of the service provider, then the provider needs
only to ensure that their sending host is authorized by
@@ -1960,5 +1960,5 @@
</t>
<t>
- If the "MAIL FROM" does not use the mail service provider's
+ If the "MAIL FROM" identity does not use the mail service
provider's
domain, then extra care must be taken. The SPF record
format has several options for the third party domain to
@@ -2001,5 +2001,5 @@
</section>
<section title="Security Considerations" anchor="security">
- <section title="SPF-Authorized E-Mail May Still Be UBE">
+ <section title="SPF-Authorized E-Mail May Be UBE">
<t>
The "MAIL FROM" and "HELO" identity authorizations must not be
#
# You had added the word "Still", but this insinuates that SPF makes, in
# some way, an assertion about the UBE-ishness of messages, the exact
# notion of which this section is trying to refute according to its title.
# IMO, the section title is significantly better without the word "Still".
#
@@ -2071,5 +2071,5 @@
</t>
<t>
- Malicious parties could send a large volume mail
+ Malicious parties could send a large volume of mail
purporting to come from the intended target to a wide
variety of legitimate mail hosts. These legitimate
#
# Fix semantics. "a large volume mail" means a single message of great
# size, which is inappropriate here.
#
@@ -2167,6 +2167,6 @@
<t>
SPF uses information supplied by third parties, such as the
- "HELO" domain name, the "MAIL FROM" and SPF records. This
- information is then sent to the receiver in the Received-SPF:
+ "HELO" domain name, the "MAIL FROM" address, and SPF records. This
+ information is then passed to the receiver in the Received-SPF:
mail headers and possibly returned to the client MTA in the
form of an SMTP rejection message. This information must be
#
# Improve wording.
#
All applied.
@@ -2181,7 +2181,7 @@
who is sending e-mail and likely to which MTA the e-mail is
being sent to. This can introduce some privacy
- concerns, which may be more or less of an issue
+ problems, which may be more or less of an issue
depending on local laws and the relationships between the
- domain owner and the persons sending the e-mail.
+ domain owner and the person sending the e-mail.
</t>
</section>
#
# "introduce concerns" isn't any better than "introduce considerations".
# It's still bad style. Let's try "introduce problems".
#
I think "concerns" is a better word than "problems" in this case. the
s/persons/person/ has been fixed. (Actually, I also did an
s/relationships/relationship/ )
-wayne