Radu Hociung wrote:
The "HELO" check not a useful or reliable check as far as I
can tell.
It's a SHOULD in what I think might be draft -01. But I'm of
course not sure, -01 was never discussed or announced anywhere
in the Community. This SHOULD was an SPF Council reolution.
neither makes it a requirement to be a domain name, much less
an FDQN.
You don't check SPF on something that's no FQDN. That was one
of the bugs in draft Lentczner, where it said "FAIL malformed
domain" to a perfectly legal domain literal.
the name following the HELO is inconsequential to the SMTP
state machine, as no decisions are made on its contents
That's not the case, the RfC 2821 syntax wants at least one dot
in an FQDN. Without this dot you have an SMTP syntax error if
you want to be strict (an MX only talking to real MTAs and not
MUAs can be strict).
Another obvious check allowed by RfC 2821: Whoever the client
claims to be, it can't be "you", because "you" (= the server)
don't talk to yourself.
So it is a "don't care" input.
Don't pull this stunt on CLEAR, just... don't.
So what is the meaning of the word following HELO ?
Whatever your forwardmaster-list defines. Just an example.
For more ambitious ideas see CLEAR, op=trusted, and op=helo,
or better the original articles written by Hector and Meng.
When you get letters, does the name of the postman make
any difference?
Of course. If it's my normal postman I'd trust him to a
certain degree based on his previous behaviour, otherwise
it's Meng's AGUPI (= assume guilty until proven innocent).
I do not see the need to do SPF or _any_ other checks on
HELO.
It's only a new SHOULD. As long as your SPF implementation
is older than the future draft -01 it's still SPF compliant.
The "local" part of the MAIL-FROM email address is not used
for SPF other than to expand the "%{l}" macro.
Sure, for per-user policies. You said account(_at_)forwarders(_dot_)com,
I was merely curious why you need any account@ for your idea.
This macro will soon be obsoleted, so it becomes a non-issue.
There's not even the slightest hint that anything in SPF will
be obsoleted this year, let alone "soon". The %{l] (= local)
macro is odd, but it's defined for v=spf1 and known variants
of spf2.0/whatever, it allows per-user policies.
I'm no big fan of this feature, quite the contrary, but your
statement "will soon be obsoleted" based on exactly no prior
discussion at all is wrong.
The earliest SPF version where it could be obsoleted would be
an v=spf2 or spf2.1/whatever. In that case I'd add some more
dubious features like exp= or ptr to the list.
HELO is not a reliable basis for any processing.
Like MAIL FROM after RfC 1123 and before SPF. It's the very
idea of CSV and the SHOULD in the future -01 draft to make it
a reliable basis for white lists.
when 1000 domains are forwarded by the same service (say
godaddy.com), the HELO will not be any of the 1000 domains
being forwarded, but mailout.godaddy.com.
If a user adds mailout.godaddy.com to his personal list of
forwarders, i.e. your forwardmaster-list, then he obviously
wants mails forwarded by mailout.godaddy.com, otherwise he
shouldn't say so.
And if HELO mailout.godaddy.com is an unreliable forwarder,
e.g. if it doesn't check SPF, then it's the problem of this
user, who else should care about it ? Certainly not godaddy.
Bye, Frank