--Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Which is why I say, relaxed provisions should be time-limited. AOL has
this problem with using a MAIL FROM AOL.COM domain resulting in a neutral
result however, the HELO domain is also a AOL domain, with PTR/A records
all correct.
I see this as part of the chain of trust and mix policy issue.
HELO needs to taken very seriously. I hope the following to become part
of the domain policy definition outlined by Pete.
I also agree that HELO checks are important. I think (hope) that is
included in the general category of "2821 checks". SPF does HELO checks so
this can be used as a starting point/example for discussion.
In my view, HELO lookups can only logical yield a none, accept or fail
and in situations where HELO SPF result other than none conflicts with the
return path SPF result, HELO should prevail.
marid(HELO::IP) -> none, accept, reject
marid(RPD::IP) -> none, accept, reject, other (currently neutral,
softfail)
I'm not a big fan of "If this, Then do this other check"... I think it's
simpler to stick to defining each individual piece on its own. I think
each piece should give a result from:
known good = validated, eligible for white list if appropriate
known bad = stop transaction and reject now
unknown = fall back to unprotected mode (including softfail, neutral)
If HELO results in "FAIL" I would terminate the transaction then and there.
But if the HELO results in "PASS" I wouldn't give the whole message a free
ride... I would still want to check the return address for proper usage
there.
Actually since HELO occurs first in the transaction, this is probably
consistent with what you said. :) I just wouldn't express it in terms of
one result "prevailing"... If the receiver wants to do ALL possible checks
regardless of PASS result at a previous step, they should be free to.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>