On Fri, 2004-07-02 at 12:28, spf(_at_)kitterman(_dot_)com wrote:
2. The spam also gets accepted by automated spamtraps.
3a. If HELO/EHLO is a FQDN, the spamtraps add the HELO/EHLO domain to the
blacklist (the MTA is the actual source of the spam and so must be guilty in
some manner).
I actually don't care that they're supposedly guilty of hosting spammers
if they're merely connecting to me to send me a known-legitimate message
from a reputable domain--That is, I have no need to block incoming
messages from a supposedly guilty MTA for the specific cases for which
the reprehensibleness of their actions doesn't affect me.
Even if that MTA unquestionably hosts known spammers, as long as the
message I get from them both passes SPF tests and the RHS meets my
reputation criteria, I don't see why I should be interested in blocking
that mail.
If the MTA allows for forgeries, then the legitimate domains who
continue to use that MTA will suffer for it. But if the MTA sends mail
for spammers and non-spammers alike and doesn't allow any forgeries to
occur between the two, then I don't see why I'd want to reject mail from
legitimate, reputable senders who've published SPF records and use that
MTA.
We've had to do IP-based blacklisting in the past because that was the
finest-grain control we had--if we were going to blocklist incoming spam
sources, that was the only choice. But now that we have/will-have a
way, for specific incoming messages, of knowing if the message is
authentic and is from a reputable domain, then there's no need to block
list based on the spaminess of the source IP if we already trust the
message itself. (For messages for which we can't determine the trust
level, then sure--I have no problem blocking based on the IP.)
Right now people who host outgoing mail service have to spend a lot of
time and money worrying about their customers who may or may not be
spammers. If they end up hosting spammers, then *they* are also
considered to be an irresponsible party, because recipients can only
reliably block at the IP level, and it's the mail owner who's most
associated with that IP and the only one you can really do anything
about the problem.
But for spf-PASSing mails, you don't have to worry about what IP it came
from to figure out whether you're going to accept the message.
As spf becomes popular, and if at some point most everyone uses it, then
I'm hoping that there'll be hardly any need for the MTA hosts to worry
about whether their customers are spammers. (And as a side note, that
would mean that it will become cheaper for people to host outgoing mail
for other domains--their other customers won't get domain-based
blocklisted along with the spammers.)
(To take this argument to extremes--were we to also have a
domainkeys-type mechanism in a later spf version, you technically
wouldn't even need to block spf-passing messages from reputable domains
sent via open relays! How's that for shocking!)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com