pitt.edu

[editorassistant]

getIPStringResult("52.70.139.219", "pitt.edu")

leads to an preg_split(): Argument #2 ($subject) must be of type string error.

[Mika56]

Your query is missing a value for the $helo argument. While not strictly required, because the SPF of pitt.edu is v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email ~all, it tries to resolve 52.70.139.219._ip.._ehlo.pitt.edu._spf.vali.email which is an invalid domain name (notice the two dots in the middle, where the value of $helo would be added).

I'm not sure if the library should provide a default value, make it mandatory, add a warning to SPFResult when %{h} or %{s} is used in a SPF record and not set in the query, or throw an Exception?

[editorassistant]

I'm confused. The signature for getIPStringResult is getIPStringResult(string $ipAddress, string $domain), i.e., there is no "helo" argument.

[derikb]

Just had this come up for rush.edu and am also a little confused about where the helo argument goes and... what one would put in there...

[derikb]

Found some syntax info here: https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/#macro-syntax Looks to me like outside the context of processing a specific message you wouldn't be able to check spf records with these variables unless you also had some IP info.

[derikb]

Throwing an Exception might be cleanest when this happens.

[Mika56]

I'm confused. The signature for getIPStringResult is getIPStringResult(string $ipAddress, string $domain), i.e., there is no "helo" argument.

getIPStringResult is the easier way to get a result. If you need advanced features like ehlo string or sender email, create a Query object directly:

<?php

$checker = new SPFCheck(new DNSRecordGetter());
$query = new Query($ipAddress, $domain, $ehlo, $sender);
$result = $checker->getResult($query);
var_dump($result->getShortResult()); // One of + - ~ ? NO TE PE
var_dump($result->getResult()); // One of Result::PASS, Result::FAIL, Result::SOFTFAIL, Result::NEUTRAL, Result::NONE, Result::TEMPERROR, Result::PERMERROR

Found some syntax info here: https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/#macro-syntax Looks to me like outside the context of processing a specific message you wouldn't be able to check spf records with these variables unless you also had some IP info.

Yes, EHLO and Sender are used in macros, which aren't widely used.

Throwing an Exception has the disadvantage of stopping the execution of the check. I feel like a better solution would be to add a hasWarning() method to Result.
We could also add an option to SPFCheck: bool $throwExceptionOnMissingMacroArgument = false (but a developer explicitly changing it to true would then probably already be aware of the $ehlo and $sender arguments)