"Julian Mehnle" suggested:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
I did not apply this one. As discussed on #spf, Chuck feels very
strongly about requiring SPF being done during the SMTP transaction
and not during later processing, such as SpamAssassin and other
filters are doing.
On the one hand, Chuck is correct in that this is the "right thing" to do,
because during the SMTP transaction, the required identities are
_reliably_ known, and "Received-SPF" headers can be generated for
applications that need to "check" SPF at a later time.
On the other hand, there is little reason why checking SPF at a later time
is _inherently_ worse. Systems don't necessarily have to use unreliable
identities after SMTP time. Systems don't necessarily have to generate
bounces after SMTP time. As long as you are guaranteed to work on
reliable identities, you can be SPF compliant. (Also, whether bounces are
generated is outside the scope of SPF, even though it is unsocial
behavior. Recommend against it if you wish, but not in RFC 2119 terms.)
I think we should go the latter route, but it is not a strong preference.
Consulting and testing an SPF after the SMTP transaction has been completed
lacks transactional integrity
The SPF policy (the IP addresses it identifies), is time-sensitive. If you
consult the SPF policy for a domain some time after the transaction, you have no
means of knowing whether or not the IP address seen at the time of the
transaction was authorised by the policy current at the time of that
transaction.
IMHO as a solutions architect, the SPF policy used to test an IP address MUST be
the version which was current at the time of the transaction involving that
address.
I thought this had been discussed and agreed _long_ ago!
Chris Haynes