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.
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.
But then again, maybe I am just picky. Anyway, I prefer to see something
explicitly stated. (Just think about how many MTAs/MUAs dont even get the
RFC 821 date format right, and now imagine those programmers writing a SPF
implementation...)
cheers,
Andreas
-------
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