On Mar 6, 2004, at 9:46 PM, Meng Weng Wong wrote:
OK. Evidently the spec and the library need changing. How about this:
if the return-path domain does not exist (NXDOMAIN), return FAIL
if the helo domain does not exist, return UNKNOWN
or should they return UNKNOWN in both cases?
unkown. It is very easy to have NXDOMAIN returned in the event of a
nameserver failure or a network service interruption. Happens all the
time, mostly for small domains that aren't seen often and the answer
isn't cached locally.
returning fail on either is a policy that should reside outside of SPF.
The RFC (2821) says that the sending domain (domain part of the
envelope sender seen in MAIL FROM) should exist and be valid. It is up
the MTA implementation to enforce this -- and many MTAs do. I don't
think that this enforcement should be moved into SPF at all. It would
require me as an admin to make sure that the SPF enforcement of that
policy aligns with my MTA policy of that enforcement. When I configure
things, I like to configure them in _one_ place -- less room for
mistakes.
Logic being:
My MTA doesn't do SPF natively, the SPF module/milter/etc does...
My MTA _can_ do domain validation on the MAIL FROM, so my SPF
module/milter/etc should not...
Returning fail in SPF tells me it is safe to issue a 55x back the
remote SMTP client. However, in my MTA it is perfectly legitimate to
hand back a "45x name resolution failure" error in the event that I get
an NXDOMAIN on the MAIL FROM domain.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth