On Wed, 27 Oct 2004, Hannah Schroeter wrote:
Suppose A doesn't do neither SPF nor SRS, but B checks SPF.
Bingo.
If B checks SPF without giving you a way to configure forwarders first,
then B is broken. ISPs with broken email are not new, I've dealt
with way too many long before SPF.
I might be a simple customer (I am not in fact, but for the scenario).
I.e. I don't know about specifics of SPF and forwarding. So why should
I, in this scenario, worry about SPF and forwarding and SRS and
whatever? I'm just buying a few services from different providers.
The default for simple customers should be to *not* check SPF.
2) default to *not* reject SPF fail for users who have not configured
their forwarders (but still add the Received-SPF header).
Makes more sense. But then that amounts to interpret -all not much
differently than ~all.
No, the -all lets those who do check SPF with a proper configuration
reject a lot of forged mail.
When configuring a forwarder, all you need to know is whether the forwarder
supports SRS.
Yeah. But the plain customer might not know that.
Then they can't check SPF. Or, their ISP might have a database of
popular fowarders with the SRS status.
Ya mean things like
SRS0=(_dot_)(_dot_)(_dot_)(_dot_)=(_dot_)(_dot_)(_dot_)(_dot_)(_at_)spammer(_dot_)com
as envelope sender,
listing a fake address in the SRS part? But then spammer.com gets
the bounces first still, because if another site bounces, it doesn't
shortcut the SRS (because it can't check the timestamp/hash).
But if it doesn't bounce, you get the forged spam. (And SPF is
supposed to block forgeries.) Another option would be to accept
SRS from anywhere, but keep a domain blacklist of SRS abusers (and other
SPF compliant spammers). This is actually what I do now. The majority
of email with SPF pass my MTA gets is spam - but it is easy to filter
by domain name.
When you get down to it, that is all SPF does, convert an IP address filtering
problem to a domain name filtering problem. The advantage of domain names is
that they are more stable than IP addresses.
For blacklisting, if I block an IP address, the spammer will quickly abandon
it, and I could block legit mail from some poor soul who happens to inherit
their IP. If I block cheapbargains.com, and it is abandoned, I still don't
want mail from anyone that buys it again.
Using domain names instead of IPs is even more important for whitelisting.
For a legit company, their IP address set will change every time they
change ISPs, add a new branch office, or rearrange their servers. SPF
provides an automatic way to keep all their business partners up to date
on the changes.
I suppose that spammers will soon start buying legitimate sounding
throwawy domains, poisoning those names for legitimate companies.
When registering a domain, you'll have to kick the tires by checking
lots of blacklists to see if it has been previously abused by a spammer.
Sigh.
For ISPs, I hope it is clear that this configuration is PER USER.
The decision on whether to reject an SPF fail is delayed until after
RCPT TO, so that per user configuration can be consulted.
Would make sense. But will all sites keep to that kind of policy
in future too?
They can't reject SPF fails unless they properly account for forwarders
(without blocking a lot of legit mail). An intermediate solution is
to check SPF and add the Received-SPF header without blocking anything.
The MUA can then do what it wants with the info (e.g. applying the suggested
forwarder logic). The disadvantage is that the forged mail still gets
accepted and transfered.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.