On Fri, 2004-06-25 at 15:59, spf(_at_)kitterman(_dot_)com wrote:
If we stick with NEUTRAL and don't add another prefix, then the
documentation ought to explain in big bold letters somewhere that if your
MTA is a shared resource, you probably ought not to be using PASS, you ought
to use NEUTRAL. Otherwise there are going to be false positives.
Whether someone uses a shared outgoing mail server is unrelated to
whether that person can trust it.
(Rude side note: You are using an outgoing mail server that you don't
trust. This is a problem that you need to correct.)
The effect of this will be (as SPF becomes more widely adopted) lots of
NEUTRAL results. As SPF gets beyond the early adopters and into more
general use, a larger fraction of the SPF publishers will be users of shared
MTAs. Over time then, more and more results will come back NEUTRAL.
A larger fraction of the SPF publishers will be including NEUTRAL
results perhaps, but you're looking at the less important fraction.
The more relevant fraction to look at is the fraction of
incoming-mail-domains that either include a neutral result or have no
spf record--and that percentage should continue to fall over time.
It started at 100% and is only dropping.
And as far as the_great_masses being unable to publish ways to get PASS
results because they're using an untrustworthy outgoing mail server,
well where there's a choice between ISPs, ISPs that offer a trustable
mailserver will start to have a slight advantage, and where there's no
choice or the sender is stuck because of contract reasons or some such,
I suppose folks who offer trustable outgoing mail service will start
getting more business.
This all looks like a good thing. I don't see the problem.
(And they *still* have a big advantage in being able to publish
something that ends with "-all", even if they have to have "?"'s in
there for a while.)
Now back to the receiver side of the question. Are MTA admins going to
start questioning putting the time and computing resources into SPF when a
significant fraction of the time it is going to come back saying, carry on
as if there was no SPF.
Of course, because if they started in a no-spf-records-published world,
then they'd have originally gotten that answer 100% of the time, and
then over time have gotten the answer less than 100% of the time.
In terms of receiver policy, I'd expect most
recievers to assume a SOFTPASS/PERMITTED result was not a forgery unless it
came from a spammish MTA.
That's the same thing I'd halfway assume about messages with NEUTRAL and
SOFTFAIL results too.
In other words, I'd treat PERMITTED and NEUTRAL and SOFTPASS equally.
So what's the rational advantage of a sender being able to specify a
difference betwen the three from a recipient's point of view?
SOFTPASS/PERMITTED will be very useful for
the receiver once we get into that regime.
No, it's horrible once we get into that regime. At best, it just adds
an unnecessary and useless complication that most receivers will, I
expect, ignore.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com