wayne wrote:
If SPF(HELO) is not either Neutral, None or pass, reject the
connection and don't even let the client SMTP connection get
to the MAIL FROM command.
That's different from what I thought for a HELO Softfail or a
HELO TempError - my idea was ignore anything but HELO FAIL or
HELO PermError for HELO.
What you propose is similar to op=helo, an "op" as in "opt in",
i.e. incompatible with old published policies.
If SPF(HELO) is PASS and the HELO identity is a known, good
forwarder, then override the MAIL FROM result
That's possible, it sounds a bit like "delete op=trusted, it's
redundant besides from being irrelevant". OTOH the op=trusted
includes op=helo, i.e. reject any HELO without PASS.
The "receiver policy" mantra has its limits.
True, but it also has some basis in reality.
Not if it's needed to justify actions like a HELO FAIL reject.
The harsh stuff needs a justification in the spec. If a "few"
(= all) old implementations are more liberal, it's no big deal.
But if receivers play hardball (like your HELO proposal) and
this is _not_ specified, it will terrify senders / publishers.
How is a support desk supposed to explain this to their users ?
Bye, Frank