Make %{h} macro expand to helo string, not sender domain

[Gianni Ceccarelli]

Hello!

I've just started using the spf module, and discovered a problem: the
%{h} macro expands to the sender's domain (like %{o}), but that's not
what the RFC seems to say, and it's not what at least one SPF record
I've encountered expects.

The SPF record at robertwalters.com.tw says:

v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email ~all

and it expects that %{i} matches the address of the %{h} name, so if I
expand it to:

208.82.5.201._ip.robertwalters.com.tw._ehlo.robertwalters.com.tw._spf.vali.email

(like the go module currently does), I get `v=spf1 -all`, but if I
expand it to:

208.82.5.201._ip.mailpmta200a.broadbean.net._ehlo.robertwalters.com.tw._spf.vali.email

(like other SPF validation libraries do, for example Perl's
Mail::SPF), I get `v=spf1 ip4:208.82.5.0/24 -all` which resolves to
"pass"

Since we can send email on behalf of robertwalters.com.tw from our
MTA, I have to conclude that the Go SPF module needs patching.

I'm attaching such a patch, with tests.

--
dakkar
a.k.a. Gianni Ceccarelli

[Alberto Bertogli]

On 1 November 2021 10:53:39 GMT, Gianni Ceccarelli <gianni.c...@broadbean.com> wrote:
>Hello!
>
>I've just started using the spf module, and discovered a problem: the
>%{h} macro expands to the sender's domain (like %{o}), but that's not
>what the RFC seems to say, and it's not what at least one SPF record
>I've encountered expects.

Hi! Thanks a lot for investigating and finding this issue!

I'm with limited connectivity for the next couple of weeks, but I took a cursory look at the patch and it looks good to me.

In about two weeks I'll incorporate it in the repository and cut a new release.

Thanks again for providing a patch and even tests, much appreciated!

Alberto

[Alberto Bertogli]

The patch was applied [1], and I've just cut release 1.3.0 which
includes it.

Thanks again!
Alberto

[1]: https://blitiri.com.ar/git/r/spf/c/1bd7bc8bd40d633f9e51980e04a1264bb16082a8/