[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HELO, and how to mix various checks


--Hector Santos <hsantos@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx>