-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Seth
Goodman
Sent: Friday, July 02, 2004 2:02 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Reputation Services and HELO/EHLO Checking
For Unified SPF
snip
Don't you think that rather than go through all this effort at creating a
distributed, fine-grained RHSBL with the explicit goal of protecting small
domain owners whose ISP's do not have adequate controls on their MTA's, it
might be easier to simply _require_ providers to support SMTP
AUTH _and_ to
limit the From: and Sender: addresses to the login address? We
can then go
back to regular old DNSBL's that we already have and everybody is
protected.
I understand that technology is cool, but we shouldn't necessarily do
something just because we can.
--
Seth Goodman
First, nothing that I said precludes use of regular old DNSBL's. I don't
know if RHSBL will ever catch on, but it's going to be a while before it
gets used much.
It might be easier to convert everyone to SMTP Auth and limited addresses.
It might not. Who is going to write and sponsor the RFC's that would
describe this new set of requirements? I think that the answer is no one.
There are options.
As currently constructed, SPF (of whatever flavor) and the notional RHSBL
process described on the SPF web site pretty much tell me that is I'm using
a shared MTA that doesn't have the kind of restrictions you describe, I
better put ?include: and not +include: in my SPF record. We can leave it
that way. If we do, there are going to be false positives and domains put
in RHSBL that shouldn't be there. This will give both RHSBL and SPF a bad
name among small domain users and they will either learn to publish
conservative records that don't help much with identifying forged e-mails or
they might abandon SPF all together.
We could do as you say and order shared MTAs to change how they are
operated. BTW, I have access to three SMTP hosts currently (Comcast,
Verizon, and my domain host) and none of them work this way. In the mean
time, you've got the risks of doing nothing that I've described above.
Rather than try to dictate operating procedures to the MTA operators, we can
craft an architecture for RHSBL creation that will place social and market
forces on the MTA operators to behave in the way you suggest. I think
that's what my proposal will do.
If you believe that RHSBL will never take off, then ignore all this, it
won't affect anyone if you're right. I'm trying to pay attention to it
because RHSBL is being suggested as one way that SPF will contribute to the
fight against spam. I'm for appropriate RHSBL generation to raise the
transaction costs for spammers. I want to do so in a way that minimizes the
risk that innocent bystanders will get burned.
Scott Kitterman