----- Original Message -----
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, January 07, 2005 2:28 AM
Subject: RE: [spf-discuss] Should I include major ISPs in SPF for our hosted
domains?
Is this kind of checking even possible with most modern MSAs? I seem to
remember Postfix has a map that can correlate usernames to allowed email
addresses, am I right? Is this possible with sendmail or qmail or others?
This is all assuming that $ISP can build a list as described above. Of
course, web sites where you enter an email address, and the system keeps a
list of "your other email addresses" and whether they are confirmed, is
not
a new thing, just something most ISPs have not had to do before.
Hi Greg,
If I am following you right, this has been part of your better system for
many years even before web based communications existed. In our Wildcat!
SMTP system, it is all dependent on a backend user database, with possible
alias and translation tables.
As long as a operation authorized an SMTP AUTH session or used an IP
AllowList, then everything else doesn't apply.
The only reason SMTP AUTH may not be used is because it is really still an
"extended" protocol. It is not required so not all MUAs originally had it.
Most, if not all, today do. It is become more important today because of
the greater market of roaming users, especially within the cell phone
market.
Also, as a side-note reminder, every system worth its salt already has long
established "pseudo-standard" technical logic to process route/relay vs
local/final mail transactions
For a route transaction, long established methods already exist with these
systems and 99.99% of the time it is a requirement for a client/server route
transaction. All security issues are straight forward that can already be
fixed, i.e, configuration and/or closing an open relay/proxy.
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.
Hopefully if things go our way, spammers will start to avoid any domain
that publishes SPF records at all. That will be the first sign that we're
having an effect and starting to gain back some inches from the miles
already lost to the arms race. The spammers will still be winning, but by
forcing them to change behavior even a little bit, we will have started on
our thousand-mile journey.
In my view, as SPF gets more widely adopted, spammers will fall in four
categories:
1- Out of Business
2- Adopters
3- Non-Adopters
4- SPF spoofers exploiting domains with relaxed SPF provisions.
Why the 4th? Because it's possible, therefore it will happen.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office