ietf-asrg
[Top] [All Lists]

[Asrg] Misconceptions about SPF (was: Unique innovations made to anti-spam system)

2006-01-24 23:30:19
Douglas Otis wrote:

I suppose this means any policy of '-all' would be in error
then?

Of course not, it's perfectly okay for a domain to say that
it's neither used as HELO FQDN nor in any MAIL FROM address.

In cases where the domain also cannot be used in an RCPT TO -
because it has no MX and no IPs, or at least no smtpd - '-all'
is a bit pointless from the POV of this domain.  But it could
still help others to reject spam claiming to be "from" this
domain without tricks like "call back verification".

Same idea as DKIM's 'o=.' SSP.  Or Mark's old "nullmx" draft.
I vaguely recall that there used to be a DNSBL with the same
effect.  Does CSV also offer a "never used as HELO" somehow ?
Yet another reason why SIQ could be a good idea.

There are at least two types of open-ended lists, '?all' and
'~all'.  It is rather common to see both.  The first would
be what is described as neutral, and the second would be
soft-fail.

The latter is mainly for testing purposes while a domain tries
to figure out where its out-going routes are.  If that turns
out to be too difficult they should pick '?all', and otherwise
they can go for '-all'.

DKIM also adopted this idea as 't=y' (testing).  In the case of
SPF receivers are free to help in the testing, or to treat the
SOFTFAIL like NEUTRAL.

As we know they are in practice also free to do anything they
wish not limited to handle a SOFTFAIL like a FAIL, or refuse to
evaluate SOFTFAIL policies, or try PRA to get fresh entropy for
/dev/random, but these options are not specified.

You still missed the point that SPF policies simply places each
and every IP into precisely one of the four sets +, ?, ~, -

There's nothing special with "all", it's just convenient to use
it for the largest of these four sets.  SPF records with "+all"
at the end are not only legal, they can also make sense if it's
an "included" policy:

      x.example. "v=spf1 -include:not.x.example tons=of-stuff"
  not.x.example. "v=spf1 -ip4:1.0.0.0/8 -ip4:2.0.0.0/8 +all"

That's a fast way to say that any IP not starting with 1.*.*.*
or 2.*.*.* is a FAIL (the "-" for the include) after it matched
the "+all" at the end of the not.x.example policy.

Nothing's "open-ended" in SPF policies.  You can get the effect
of "?all" without using it, e.g. "?include:not.x.example" would
result in NEUTRAL for any IP that's not 1.*.*.* or 2.*.*.*

It's no problem if you say that you don't _like_ policies with
a potential result NEUTRAL, nor do I:  A receiver wasted his
time if he wants either PASS or FAIL, and gets only NEUTRAL.

But as you pointed out there are situations where domains might
wish to say less than PASS for certain shared MTAs, but in that
case they can still offer PASS or FAIL for all other IPs.

And as you also pointed out some domains might not like to use
FAIL at all, but still offer a PASS for some IPs, to be used
in white-listing up to reputation.

So nothing's technically wrong with NEUTRAL, and DKIM SSP also
has a similar concept 'o=~' "some mails signed".  I'm too lazy
to dig if CSV also offers a kind of explicit DUNNO, does it ?

Sender-ID recommends that a "spf2.0/pra ?all" be used as an
"opt-out" of the PRA algorithm.

Hopefully this issue will be investigated by the IAB.  As far
as "sp2.0/pra" (no "?all" needed, it's the default) results in
a NEUTRAL for PRA it might be what domains publishing it want.

This would be one example where a "neutral" result is _not_
the same as no record.

I'd certainly like to see the results of investigations by some
other agencies and commissions about this "opt out" scheme.  In
practice it's probably moot.  SMTP folks know why MAIL FROM and
PRA can be different.  Therefore it's bogus to use algorithm B
for identity B with a policy for identity A (or vice versa).

Of course, there is no real means for the sender to control
how these records are used by the recipient.

ACK.  Receivers are free to check say v=spf1 policies against
Message-Ids if they get some kicks out of this braindead idea.
They could also claim that you can "opt-out" of this scheme by
simply not adding a Message-Id to your mail.

That cries for an experimental RfC for a new use of spf2.0/pra
policies, just use it with Message-Ids.  Unfortunately I'm not
sure that the IESG would reject this as net abuse and nonsense.

The SPF draft calls for a _minimum_ number of 112 lookups

| To prevent DoS attacks, more than 10 MX names MUST NOT be
| looked up during the evaluation of an "mx" mechanism
[... dito "ptr"  ...]
| SPF implementations MUST limit the number of mechanisms and
| modifiers that do DNS lookups to at most 10 per SPF check,
| including any lookups caused by the use of the "include"
| mechanism or the "redirect" modifier.

MUSTard _maximum_  1 SPF + 1 TXT + 10 MX + 10 A * 10 MX = 112.

How many years didn't you look into a SPF spec. ?  That's state
of the art for years after one Doug Otis whined about the vague
processing limits in early 2004 SPF drafts in MARID.

And all SPF implementations always had similar limits, the only
problem was that it wasn't precisely specified before MARID.

There are configuration unable to fit within 112 lookups,

Well, if they have more than 100 IPs for their 10 MXs they
should try something simple like ip4:111.222.33.0/24 (256 IPs)
that doesn't neeed any lookup.

The number of excessively complex policies was very small, and
it was always possible to simplify them drastically.  Using the
"mx" mechanism at all is often a bad idea to start with, an MX
is not necessarily related to the sending MTAs of an MON.

Without "mx" or "ptr" the MUSTard maximal DNS lookups are TEN:
Each "a", "include", or stuff within an included record counts.

Quite the contrary "drop FAIL" is extremely dangerous,
reject is always fine.

While drop fail is not good, rejection may still affect a
large number of users.

The biggest German ESP has a FAIL policy.  My ISP has a FAIL
policy.  All want FAIL to be rejected, because then it works
also with receivers screwing up and checking SPF behind their
border.  With "drop FAIL" receivers should be sure that their
setup is correct, otherwise they'd shoot into their own foot.

Are you saying a closed policy would be bad, but that only a
closed policy would offer benefits?

No, I like "my" and all simple 'either PASS or FAIL' policies.

And any policy where PASS or FAIL is a possible outcome offers
some benefits.  Only "all NEUTRAL" is useless, because it has
no effect - or at least no specified effect, receivers can of
course (ab)use it in some wild and wonderful unspecified ways.

Many individuals cherish the use of an email-address that
affiliates them with a school or society.

That's fine, but unrelated to the reasons why senders cherish
a FAIL policy.

It would seem that path registration has created the problem.

Yes, at first glance, but of course it fixes this bug in 1123,
and many forwarders have no problem to switch from 5.3.6(a) to
5.3.6(b).  Forwarders must take the responsibility for their
actions as it used to be in STD 10 (821).  If they don't like
this there's 551, the real thing or emulated by an SPF FAIL.

Receivers can also white list their more stubborn forwarders.

Last but not least it's perfectly okay if receivers just don't
want any SPF FAILs caused by their own forwarding arrangements:
An odd strategy, but its their mail, they do what they like.

Expecting large and complex domains to use CDIR notation for
outbound hosts ignores how these tools normally work and
invites error.

So far all managed.  The worst known sender policy ITW caused
up to 68 lookups, and IIRC it was possible to push that below
the mentioned TEN + two replacing all "mx" by "ip4".

The need for the 112 minimum lookup requirement also
suggests there is a fundamental problem with this approach.

That would be true if there is any minimum 112, but that's not
the case.  It's a _maximum_ involving 10 MXs each with 10 IPs.

                            Bye, Frank



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg