On Mon, 2004-04-26 at 01:29, Roger Moser wrote:
The latest specification says:
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.
On the surface, I don't see a major problem here. They'll only be happy
if SPF is the sole component of what has already been suggested should
be a multicomponent spam fighting implementation. The message gets
accepted in the case of "unknown", but then additional tools, specificly
designed to fight spam and viruses take effect, which can make more fine
grained decisions as to if something actually ends up in a mailbox or
not. Note that there are no requirements to publish SPF records --
domain owners are free to publish or not, and this largely maintains
backward compatiblity with the existing mail system.
Digging deeper, I could see a need for making a distinction between
"domain doesn't exist", "domain doesn't publish SPF records" and
"domain's SPF records are unparsable/invalid", but this only has
usefulness outside of the MTA proper. As far as the MTA is concerned,
any of these three states are exactly equilvent, erring on the side of
caution (continue on, accept the mail, so as to not to lose/block any
domains), and tell the MTA to take the same action -- so making a
distiction doesn't actually help the MTA at all. Finer granularity is
much more useful in the MDA, at least at this stage of SPF's deployment.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>