Julian Mehnle wrote:
I have now finally managed to read through the whole spec. Here are my
suggestions [...]
Also, I have the following additional suggestions:
1. Suggest "HELO domain" instead of "HELO mx.domain".
Section 3.1 ("Publishing") mentions that the zone cut feature can be used
to avoid having to publish additional SPF records for all MX names
(mx.example.org), but that this requires additional DNS lookups. However,
if the MTA(s) can use the domain name (example.org) instead of the MX name
(mx.example.org) in its HELO/EHLO commands, additional SPF records can be
saved without requiring additional lookups. This is the case if
example.org points to the same IP address(es) in DNS as mx.example.org,
which applies to many small sites. I think this would be worth a mention
in 3.1.
2. HELO checking and MAIL FROM checking.
The current spec lacks a clear vision of the relation between HELO and
MAIL FROM identities. This is partly due to the historical fuzzy
definition of the HELO identity. We have two options:
* We can either leave it at that, which would leave those HELO checks in
a somewhat pointless limbo: HELO is only checked if MAIL FROM is <>.
This is the current and traditional vision of SPF. This makes the
HELO identity more or less irrelevant in the general case, because
like in RFC 821 and 2821, it isn't used for anything meaningful
(except for SPF checks in the "bastard" MAIL FROM: <> case).
* Or we can describe a clear vision to actually make HELO checks useful:
HELO is always checked, regardless whether MAIL FROM is <>.
This is my preferred vision. It gives the combined HELO+MAIL FROM SPF
checking procedure a modular structure because we can say that
MAIL FROM checking relies on prior HELO checking. Thus the HELO
identity has a clearly defined meaning.
Both options don't really differ in how HELO is being used by SPF, but the
second one gives a clear vision of what HELO means and, like MAIL FROM,
properly protects it from being forged.
3. Lookup/processing limits.
Section 7.1 ("Processing Limits") should be moved under section 10
("Security Considerations"), probably as 10.2, turning the current 10 into
10.1. Also, even though I have missed my opportunity to take part in
discussing this topic in the past, I'd like to suggest that the SPF spec
not provide for mechanism count limits and per-mechanism lookup limits,
but a global lookup limit. This is more flexible for complex mail server
infrastructure. The argument, that a global lookup limit would make it
hard for publishers to see whether they exceed the limit when drafting SPF
records, doesn't hold because record creation wizards and command-line
tools can easily compute the maximum number of limits that can be caused
by a given record.
4. "Authentication-Results:" header.
We should work with the authors of draft-kucherawy-sender-auth-header-00
to make the "Authentication-Results:" header work well with SPF, and then
recommend its use (idependent from "Received-SPF:") in the SPF spec. If a
generic header exists, it should be used for interoperability reasons.
Also see my latest reply to the discussion by Wayne and William.
(I'd like to discuss the above issues on an abstract level before I create
concrete patches for them.)