spf-discuss
[Top] [All Lists]

Re: Should I include major ISPs in SPF for our hosted domains?

2005-01-07 06:04:54


Allow me to correct you again! :-)

Once an SMTP AUTH session is established, everthing else is MUTE!   SPF
does
not apply.

Yes, it does, because a SOFTFAIL, or for sites that merely SPF publish but
don't block messages, a REJECT message, is now available for other more
complex mailfilters to operate upon. This is especially true in testing
setups, where you're gathering SPF statistics rather than simply turning
it
on abruptly and wholesale.

A user who has been authorized to send mail is not GOING to be restricted on
our system and I certainly HOPE most systems.  This is NOT the business of
SPF if only for one reason, lack of reliability.

SPF should augment the existing system by helping in filling in the
holes
for Anonymous SMTP Transactions.  An SMTP AUTH session is not anonymous.

No. Lack of anonymity is not the point, forgery is. Whether the user has
authorized the message doesn't mean their *domain* permits that message.

If the authorized user is an maliciuous abuser he can handled according
using normal system policies.

In addition, the SENDER is the ISP.  The ISP is the DOMAIN to be authorized
at the downlink. It has nothing to do with the authorized user at the MSA.

And you'd better believe that the next crop of email worms will take
advantage of the locally stored user authentication to submit their spew
into the user's own upstream SMTP sites, some of them already have.

Again, same issue. Read above.  If exploited account is already handled.

The SPFC (SPF Council) should not take on issues that are already part
of
the system to establish credentials.   What you propose takes away from
backward compatibility, hence adds a greater barrier to adoption.   In
addition, the SMTP AUTH concept is highly backend dependent.

Well, true about backend dependencies, but it's not fair to say "except
for
SMTP AUTH messages". It adds a nasty layer of complexity in the SPF
filtering that's not necessary.

SPF or any other system has no business breaking 20 years of traditional and
working email infrastructure.   The problem is not by far, without a doubt,
uncategorically related to authorized transactions. The problem is anonymous
local transactions.  Fix the anonymous transaction and your spam issue is
reduced. Of course, I am speaking on real practical experience and
operations across thousands of systems. I have stats to prove it and guess
what?  Its backward compatible :-).

Anyway, SPF has nothing to do with it.  Of course, any implementation can do
what it wants, but should it be part of the SPECS?   That would be dumb. It
doesn't make sense and like I said, traditional systems are NOT going to
change their existing and WORKING authorized transaction process.   It won't
be followed.

"Keep the eye of the prize"

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office




<Prev in Thread] Current Thread [Next in Thread>