Hector Santos [winserver(_dot_)support(_at_)winserver(_dot_)com] wrote:
The reason we use SPF or any new "Transaction Authorization" as I call
it, not email authentication, not path authentication, is to address
the SMTP hole for Anonymous Transactions not requiring any
authorization.
Thus, if a ROUTE requires authorization to begin with, any operation
forcing SMTP AUTH for local transactions as well, will thrump SPF or any
other new transaction authorization scheme. That is how our
WCSMTP/WCSAP system is designed. SPF, CBV, Black/White List, etc only
come into play for an unsecured anonymous local transaction.
Here you are in error.
For SPF to protect me from (cross-domain) MAIL FROM forgery, I have to
perform SPF checking, and I have to trust every domain owner on the planet
to (more or less) correctly specify their sending MTAs in an SPF record.
The latter is easy since it is in every domain owner's (even spammer's)
best interest to specify a correct SPF record.
For SMTP-AUTH identity enforcement to protect me from (cross-domain and
cross-user) MAIL FROM forgery, I have to trust every sending MTA on the
planet to perform SMTP-AUTH identity enforcement. That is nearly
impossible because this is _not_ in every sending MTA owner's (especially
not spammer's) best interest to perform SMTP-AUTH identity enforcement.
Thus, SPF is useful far beyond unauthenticated message transport.