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'.
^^^^ ^^^^
Sorry, I wasn't sure what you meant and picked the "only -all"
case. But it's probably clear that I do like "-all" also if
it is at the end, from my POV that's the main purpose of SPF.
Others are much more interested in PASS and don't reject FAIL,
because they want the PASS for their own white-listing magic -
a prominent example is AOL.
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?
In many cases "just forward" without changing the Return-Path
is fine, just don't check SPF behind your border. SA wizards
might get it right later by looking at the timestamp lines,
but the spec. discourages such schemes.
The "change Return-Path" is only relevant for different "AUs",
the "251 user not local" cases. Even then it's not the only
way, "white list forwarder" is also good enough.
Only if both admins refuse to do anything, and the MX-admin of
the MRN rejects SPF FAIL, then the sender gets the "251 twisted
into 551 emulation", in other words a bounce message from the
forwarder. No pain, no harm, working as designed. But don't
try this with a "drop FAIL" instead of a "reject FAIL" setup.
[CSV variant of "never used as HELO"]
There is also the Port field where a value of 1 indicates
all clients within this domain must have a corresponding CSV
record.
Yes, I forgot John's "cut labels 6..2 left to right" algorithm,
if that finds something it's supposed to define a default, and
NEVER is then an obvious case.
[SPF NEUTRAL and SOFTFAIL]
These multiple methods of open-ending the authorization
however was the reason for using the more general terms of
open-ended or closed.
When I talk about PASS / FAIL vs. NONE / NEUTRAL / SOFTFAIL I
often simplify the latter results to "DUNNO". Receivers are
free to interpret any "DUNNO" as "inconclusive".
Maybe you could say that a conformance test is "open ended" if
some test cases end with an "inconclusive" result, but it could
be also cases of "n/a".
A PASS may mean many things
If it's from somebody you've white listed it means something
like "it's me, trust me". If it's from somebody you don't
know it still means "bounces or auto-replies won't hit innocent
bystanders".
We don't need to discuss that "trust me" is a very interesting
statement, and nothing forces you to start a PASS white-list.
a NEUTRAL could be treated as a PASS because there was a
record and it did not indicate a FAIL
Shaky idea, you could also argue that NEUTRAL could be treated
like FAIL because there was no PASS. Receivers can do stupid
things. But the spec. says "MUST be treated exactly like the
NONE result" (for no policy). That's a 2119-MUST, receivers
breaking it own the pieces.
there remains a fair amount of risk when reputations are
justified using these results.
Basing reputation on NEUTRAL results also violates this MUST,
Basing reputation on PASS is fine, "considered responsible for
sending the message" => problem of the domain owner to get it
right.
["v=spf1 ?include:not.x.example more=stuff"]
This would be an open-ended policy where perhaps any IP
address would still obtain the acceptable NEUTRAL result.
Yes, perhaps, and then it's overly complex. I only wanted it
clear that NEUTRAL results are not necessarily the effect of
an "?all" at the end, the ?" can be anywhere, like the other
three qualifiers (+ - ~).
[PASS / NEUTRAL policy without FAIL]
There would be some concern regarding whether this public
record becomes abused by other systems with access to a
shared server
Yes, as discussed, don't use PASS if you have reasons to be
paranoid (that might affect spamcast routes). Now you said
this in a context where you already decided that you don't
like FAIL, even harmless FAILs like -ip4:255.0.0.0/24 or for
all IPs on reliable DNSBLs (using SPF's "exists"-mechanism).
In that case, you want neither PASS nor FAIL, I'd recommend
plan B: forget SPF, it's not for your MAIL FROM domain.
Maybe you can use "v=spf1 a -all" for your HELO, because CSV
is probably not as widely supported as SPF at the moment.
Clearly, some have elected to treat no records with a lower
rating than the '?' qualifier.
Some elected to treat any AOL NEUTRAL as "highly suspicious".
<shrug /> See above, receivers are free to do strange things.
In a mathematical sense (for a scoring system) that might be
even correct.
that adjustment will likely represent an unfair reputation.
If receivers _want_ to violate a MUST in the spec. there's not
much you can do about it. They could also treat mails without
DKIM signature different from mails with an invalid signature,
AFAIK not covered by the spec. They can reject mails from IPs
without the digit "1" in dotted quad notation. That's not as
bad as it sounds, most IPs have a "1" (number theory), but it
is of course still stupid.
[maximum 112 = 1 + 1 + 10 + 10 * 10]
The maximum that should be found in a record, would also be
the minimum that should be examined before quiting.
Yes. Implementations MUST abort with result PermError for the
11-th name (A lookup) in MX records for "mx" mechanisms. They
MUST abort with result PermError for the 11-th mechanism with
a DNS lookup.
"v=spf1 a a a a a a a a a mx ptr -all" never reaches the FAIL.
1 2 3 4 5 6 7 8 9 10 11
In that stupid example you end up with at most 1 SPF + 1 TXT +
9 A + 1 MX + 10 A lookups, if there's an 11th name for the MX
you get a PermError for the MX. Otherwise you get a PermError
for the "ptr", it's the 11th mechanism causing a lookup.
Total worst case 22 lookups if you get no PASS for "a" or "mx".
The only way to get seriously more lookups than 12 is if you
have "mx" or "ptr". Just for fun my stupid example covered it
with it's 22 including 10 MXs for the domain, But in practice
domains have less MXs, worst I remember is t-online.de with 8,
an ISP with at least 10,000,000 customers. More MXs wouldn't
work well with UDP and q=mx, but I digress.
The concern is with respect to what is being asked of the
recipient, and less about what is being allowed the sender.
The recipient is asked to throw a PermError as soon as he sees
or hits the the magical 11. Just grep for "10" in the spec.
What you called minimum is a hard maximum, and while the spec.
(draft -02) doesn't say what you could do with this PermError
everybody knows (was in draft -00) that a 5xx reject is okay.
For the sender side that would be a clear "don't call again
until you have fixed your policy". The receiver could also
blacklist the offending domain for some time after PermError.
A maximum to publish is also the minimum to lookup when
needed.
My stupid example shows that you can get the PermError much
earlier (after 22 lookups), and without any "mx" or "ptr" the
PermError hits after 12 lookups.
Bye, Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg