getFallbackPolicy().addEntry(somepattern, record) activates fallback.
But I don't think SPF fallback is the same you expect. Fallback allow
you to define custom records for host patterns.
I don't think the fallback you describe is good in any way as I have
domains where the main domain publish an SPF record for that specific
domain and subdomains do not publish an SPF record because mails for
them is sent from many IP I can't control.
Hi - Thank you for the response. I have come to understand that the
fallback idea (as i meant it, not as meant in jSPF) is not a good one in
general. For various reasons we aren't rejecting non-existent domains at
postfix, so our code needs to handle it, but our spam-scoring should
cover that case, so i'm not going to worry about it.
Regarding the DNS info:
First question: when running an SPF check with jSPF using the DefaultSPF
> checker method checkSPF(ip, address, helo) and receiving an SPFResult
> object, it doesn't look like there is a way to distinguish between a "NONE"
> result because the domain doesn't exist, and "NONE" because the domain has
> no SPF/TXT record. I'm sure that's correct/good for SPF checking in general,
> but any chance of that feature being added some day? I tried to figure out
> how to subclass SPF.java to do it, but gave up eventually... maybe there is
> a way to just subclass and expose a little more data? Any tips are welcome.
As the SPF spec does not require different behaviour for the 2 cases
we didn't bothered to differentiate them.
Makes sense. Thanks for your detailed response about the interfaces/etc,
it's good to know what the options are. As i said, we aren't rejecting
non-existent domains on-the-wire, so i was hoping there was an easy way
to expose the DNS results to avoid doing another lookup (even if it is
cached) - basically to use the DNS work jSPF is already doing to our
advantage. Anyway, thanks for the guidance...
-Casey
