On Wed, 2006-01-25 at 07:11 +0100, Frank Ellermann wrote:
Douglas Otis wrote:
I suppose this means any policy of '-all' would be in error
then?
This was about unintended failures being due to a policy that ends with
'-all'. This depends upon how changes are made for forwarding to
accommodate path registration. When there is no local mailbox, what
change to the return-path is made?
Does CSV also offer a "never used as HELO" somehow ?
The Priority field is always 1 for version. The Weight field of the
_smtp._client.<ehlo> SRV RR can be either 1 no target, or 2 authorized
and target defined. There is also the Port field where a value of 1
indicates all clients within this domain must have a corresponding CSV
record.
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'.
These multiple methods of open-ending the authorization however was the
reason for using the more general terms of open-ended or closed.
You still missed the point that SPF policies simply places each
and every IP into precisely one of the four sets +, ?, ~, -
Nevertheless, these four sets do not provide clarity what the qualifier
means to the sender or the recipient. A PASS may mean many things, and
a NEUTRAL could be treated as a PASS because there was a record and it
did not indicate a FAIL. Even assuming everything is interpreted
correctly by the recipient, there remains a fair amount of risk when
reputations are justified using these results.
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.
Indeed include is a mechanism, it terminates (matches) on a PASS, which
with a '-' qualifier, upon finding a PASS within the include, would
terminate processing and then result in FAIL. The include would ignore
the -ip: mechanisms and only see the +all (a mechanism that always
matches.) The default of no match is '?'. I understand how this works.
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.*.*.*
But a NEUTRAL or PASS policy both expect the message to be accepted.
This would be an open-ended policy where perhaps any IP address would
still obtain the acceptable NEUTRAL result.
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.
There would be some concern regarding whether this public record becomes
abused by other systems with access to a shared server, or whether the
accrual of behavior only assesses PASS results. Clearly, some have
elected to treat no records with a lower rating than the '?' qualifier.
Offering any value for just having a record means there must be some
method to adjust for abuse, and that adjustment will likely represent an
unfair 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 ?
Things are rather cut an dry with CSV. There are modes that have been
defined, but I doubt if they would ever be used. These were defined
assuming someone may develop a new way to authenticate, but still would
want the authorization mechanism.
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).
Agreed.
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.
The maximum that should be found in a record, would also be the minimum
that should be examined before quiting. The concern is with respect to
what is being asked of the recipient, and less about what is being
allowed the sender. A lookup may represent many queries. From this
perspective, the SPF draft demands a minimum of more than one hundred
lookups by the recipient if needed. Of course, there may be less needed.
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 need any lookup.
A provider has better control of their address space in many cases.
The problem presents itself when there is a diverse configuration of
MTAs, perhaps as a kiosks sending information in the mail to friends and
family from diverse addresses, then combined with corporate and other
related MTAs, all attempting to utilize the same email-address domain.
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.
A maximum to publish is also the minimum to lookup when needed.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg