On Wed, 5 Jan 2005, Julian Mehnle wrote:
2. HELO checking and MAIL FROM checking.
Agreed. I like the second one better, though we shouldn't be
heavy-handed about saying "HELO should be used for X"... maybe more
passive like "If HELO is a domain name with an SPF record, it can be
checked in this way." As in, we generally expect it to be used in a
certain way, but we're not mandating it.
This is also somewhat implicitly noted in the current SPF spec in sections
2.1 and 2.4, but should be made more explicit, i.e. "malformed" HELO
strings should be declared broken as per RFC 2821. Also, de facto SPF
does not enforce this because a malformed HELO string results in "None",
which allows forgers to say "HELO non-existent-subdomain.debian.org, MAIL
FROM: <>" and not get caught. But a strict interpretation of RFC 2821
actually allows banning such behavior, so why is the SPF spec reluctant to
do so?
Basically I would like the spec to pave the way for HELO checking, but
not specifically require it. [...]
Ok, so why exactly don't you want to require HELO checking?
Hmmm, let me think about that. What I really want is for as many people to do
HELO checking as possible, and to make it as easy as possible. I guess the
reason I don't want to make it 'required' or a 'dependency' is that I'm
anticipating there might be a backlash from the greybeards at ietf or other
fundamentalists.
Perhaps we can state it as "SHOULD check HELO using SPF" - it makes the
recommendation pretty clear but leaves the door open to those who can't check
HELO or won't. Something that causes software vendors to do the right thing
(such as shipping with the HELO check defaulted to ON) but doesn't cause
objections from the peanut gallery would be ideal.
We can also make some statements about nonexistent names, such as "Receivers
may decide to implement a local policy, such as requiring helo names to be
fully qualified and resolve to an A or MX record, but such receiver policies
are beyond the scope of this document"
Here's another idea, what about using a HELO PASS result to override a
"require reverse DNS" policy? I currently reject mail from MTAs that don't
have a proper reverse address, but some of the unfortunate souls with no
reverse IP might still get through if I allowed HELO to override that. This
seems like another area that's skirting the edges of "what is SPF" and "what
is generally good receiver policy" -- maybe it's a good candidate for "If you
decide to do X well okay" type of language.
--
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"