In
<ec6804cf0510161841x3a0b84efoadc2962de7218ba4(_at_)mail(_dot_)gmail(_dot_)com>
Andreas Saurwein <saurwein(_at_)gmail(_dot_)com> writes:
On 10/16/05, wayne <wayne(_at_)schlitt(_dot_)net> wrote:
In
<ec6804cf0510161802h18d4d220sa2fb4867b20b4681(_at_)mail(_dot_)gmail(_dot_)com>
Andreas
Saurwein <saurwein(_at_)gmail(_dot_)com> writes:
When doing a HELO check, for example the macros s, l, and o will not be
available, yet the spec does not exclude their use or suggest
alternatives.
Section 4.3. "Initial Processing" says:
If the <sender> has no localpart, substitute the string "postmaster"
for the localpart.
This is further stated in Section 8.1. "Macro definitions":
The "s" macro expands to the <sender> argument. It is an e-mail
address with a localpart, an "@" character, and a domain. The "l"
macro expands to just the localpart. The "o" macro expands to just
the domain part. Note that these values remain the same during
recursive and chained evaluations due to "include" and/or "redirect".
Note also that if the original <sender> had no localpart, the
localpart was set to "postmaster" in initial processing (see
Section 4.3).
So far so fine. So: during an HELO check,
s = "postmaster"
o = ""
l = "postmaster"
This will lead to unintended results if not used carefully by the publisher
of the SPF record. I've seen some discussions about the scope of macros, but
no real solution.
Section 2.1. "The HELO Identity" says:
It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
identity, but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the
<sender>.
Also, section 2.4. "Checking Authorization" says:
<domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity.
Section 4.1 says similar things as section 2.4.
So,
s="postmaster@<helo-domain>"
o="<helo-domain>"
l="postmaster"
Yes, the HELO data is required for both the "MAIL FROM" and "HELO"
identities, as is the IP address and all other macro variables.
You are right, the spec doesn't explicitly say this, but then, it
doesn't give an exception either. I don't think you can spell out
every case. (e.g. "Yes, you need to support the "i" macro even on
odd-numbered Tuesdays.") Do you think this case really need to be
clarified?
Yes, I think so. Since the spec says that the SPF check can be applied to
HELO or MFROM checks, I think it should be at least mentioned that for a
MFROM check the HELO data must be present.
Hmmm.... In section 2.2. "The MAIL FROM Identity", it already talks
about using the "HELO" identity in the case of "MAIL FROM" being
null. The HELO information is also often put in the Received-SPF:
header.
The SPF spec is already quite long. It would be *MUCH* longer if I
had accepted every suggestion to "clarify this", or "add a note about
that". The longer the spec is, the harder it is to understand the
whole thing. While I was editor, I asked people to suggest an
equivalent amount of text that they would rather see deleted in order
to add the text they are suggesting to be added.
What text do you think should be deleted? (And what, exactly, would
you add?)
What do other people think about this?
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com