On Thu, 12 Jan 2006, Dick St.Peters wrote:
Either way, this thread has drifted far away from what is important to
me: that my SPF policies not be applied to my servers' HELO
identities.
This has become operationally less important since the zone cuts were
removed, but I still regard it as ludicrous to think that a single
policy applies to both MAIL-FROM identities and HELO identities. My
servers send mail for hundreds of domains, but the servers themselves
are in a domain never used legitimately in a MAIL-FROM.
I think I understand where Dick is coming from here. I think we can agree
that SPF as it exists today doesn't have a really great answer[1] to "my
domain is used for HELO but not MAIL FROM" and vice-versa. HELO checking was
built as a fallback behavior but it turned out to be a good tool for catching
some simple, obvious kinds of forgery, so I think it was the right thing to
do, it was just done inelegantly.
Dick, you made two important statements that seem to suggest why you feel
strongly on this issue, but they also deserve clarification. If you send mail
for a lot of different domains (MAIL FROM) and the server's HELO is not one of
them, that doesn't seem to be a big deal to me, but your reaction suggests
it's a big deal to you. My feeling is that it's a non-issue if the domains
are different (as Frank and I think Scott pointed out) -- just publish
different SPF records for the various domains.
Since you also mentioned zone cuts, I am guessing that cases like
"mydomain.com" and "mail1.mydomain.com" are important. Zone cuts are just a
shortcut, though, and domain owners are still free to publish different
records for domain and sub.domain.
Based on those reasons, I believe that "I'm using different names for HELO and
MAIL FROM" is an entirely different problem from "I'm using the same name
(mydomain.com) as both HELO and MAIL FROM but with different policies" or even
"I'm using a name as MAIL FROM but never HELO" and vice versa. I still
believe that most of the time, a simple SPF record can be constructed that
serves both purposes. The side effect is that if you authorize a server for
MAIL FROM, it's also authorized to use that name for HELO, even if it
shouldn't, but that seems to me to still be an improvement over "anyone in the
world can abuse my domain as their HELO".
Please tell me if I'm misunderstanding your point here... I can tell you feel
strongly about it but I'm not sure if I just plain disagree or if I'm not
understanding you correctly.
[1] When I say "SPF doesn't have a really great answer" -- there IS an answer,
it's just not a great one :) If you use a given name for HELO, not MAIL FROM,
do something like this:
s1.mydomain.com. TXT "v=spf1 redirect=%{l}._spf.mydomain.com"
postmaster._spf.mydomain.com. TXT "v=spf1 +a -all"
*._spf.mydomain.com. TXT "v=spf1 -all"
If the opposite is true, a name is used for MAIL FROM and never HELO, try
this:
mydomain.com. TXT "v=spf1 redirect=%{l}._spf.mydomain.com"
postmaster._spf.mydomain.com. TXT "v=spf1 -all"
*._spf.mydomain.com. TXT "v=spf1 +a +mx +include:out-spf.myisp.com ~all"
It is hacky and strange, and most people will probably not need to use it, but
the workaround is there if it's needed for extreme cases. Being able to
specify per-user SPF records is also cool - you can give a "-all" for
addresses that can receive but should never send. You can also give ?all for
certain users, +include:otherisp.com for some others, and -all for most. The
fact that "postmaster" is linked to HELO checks (either required by MAIL
FROM:<> or the optional-but-recommended stand-alone HELO check) seems to me to
be a happy compromise :)
Thanks for taking the time to discuss. Talk to you soon...
gregc
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"
-------
Sender Policy Framework: http://www.openspf.org/
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