Spf Pobox wrote:
Roger Moser wrote:
2.2.2. Lookup
...
If the domain does not exist (NXDOMAIN) an SPF client MUST return
"unknown".
3. SPF Record Evaluation
...
Unknown: indicates incomplete processing: an MTA MUST proceed as if a
domain did not publish SPF data.
This will make the spammers and virus authors happy. Now they
simply have to
use a return-path with an non-existing domain, and their spam
or virus will
be delivered.
If spammers use an invalid domain in their return path, I don't
need SPF to bin it, my MTA, like Sendmail and others can (an
will) reject it anyway.
I see this change as helping to avoid duplication with the MTA
allowing the MTA to make simple no-brainer decisions.
Additionally not clouding any scoring mechanism by double
counting
Hello,
I would like re-open this can of worms, because this standard forces a
needless performance penalty on systems that implement SPF.
A typical MTA+SPF implementation does two checks on the sender address:
1. does the domain exist? (DNS lookup)
2. does the domain allow this piece of mail ? (SPF check)
Unfortunately, the "does the domain exist" query is executed twice, once
at each step.
The two questions could be merged, and only one question asked instead
if SPF did not hide the fact that the domain may not exist.
Thus, I think that a "nodomain" SPF response is needed. The SPF spec
need not require action on this result, and should recommend the MTA
interpret the condition and do what is appropriate.
Since the spec requires an SPF library to perform a DNS lookup, it
should also require that as much information as possible is conveyed in
the SPF answer. Otherwise, it should permit a wrapper around the SPF
library which does the lookup itself and delivers only the TXT to the
library, while handling the unspecified conditions in the wrapper.
The default policy outcome should be changed from "none" to "nodomain"
upon finding a non-existent domain, so that a local policy can still be
specified that would mark bogus email from trusted IP's as "pass", ie:
local-policy="+ptr:192.168.0.4" would be permitted to send email as
anything it pleased.
Regards,
Radu Hociung.