Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version
2019-12-20 11:08:14
On 12/20/2019 9:11 AM, Peter J. Holzer wrote:
You are aware that you are directly violating a MUST NOT constraint in
the RFC by doing this, while there is no such constraint against
rejecting all IP literals (or just IP addresses equal to 7 modulo 13,
FWIW). I don't think you can argue with protocol compliance on this.
Hi Peter,
I believe I have explained this. Maybe not.
I admitted the EHLO/HELO [ip-literal] match test against the technical
requirement it must represent the connecting IP address, was, in fact,
a violation of the MUST NOT reject when enforced. There is ambiguity
whether it just applied to FQDN validity checking due to strong
history of configuration problems with FQDN. But in principle, the
MUST NOT reject HELO/EHLO regardless of input is well respected.
This was why I asked Kkensin during RFC2821bis to consider the pending
era of new "deterinistic" protocol methods because some may begin
conflict with the spirit of SMTP always accept mail methodology. These
were on their way.
- Enforcement pure 100% SMTP compliancy
- CBV checking the return path
- SPF checking the return path domain policy
- ADSP checking the author domain policy
The difference with "deterministic" concepts as oppose to
"nondeterministic" or "subjective' concepts where it is more about
"reputation," these are not immediate, but learned.
I am very unclear on what you understand to be "deterministic".
From google: Deterministic functions always return the same result
any time they are called with a specific set of input values and given
the same state of the database.
Nondeterministic is basically when the function need more help beyond
the basic protocol.
From google: In computer science, a nondeterministic algorithm is an
algorithm that, even for the same input, can exhibit different
behaviors on different runs, as opposed to a deterministic algorithm.
There are several ways an algorithm may behave differently from run to
run.
Nondeterministic systems contain fuzziness in results. The key is
that, your results MAY be different from mine. Not so with
deterministic functions, protocols and methods.
DKIM POLICY model is deterministic
DKIM TRUST model is nondeterministic
Every wonder why we can't get a DKIM TRUST going as a standard?
Because it suffered as a "Battery Required" protocol. It doesn't work
without a 3rd party trusty party service.
DKIM Policy got traction with its 1st party only deterministic rules.
The reason why we had such a terrible problem with DKIM+ADSP and now
DKIM+DMARC is because we can't resolve the subjective,
nondeterministic "Batteries Required" 3rd party signer authorization
problem. Its going on almost 15+ years, Peter. :( And because we
can't resolve it, we now begin break RFC5322 protocol and long time
mail engineering with strong persistent Author fields by rewriting
5322.From.
Go figure.
You seem to be making assumptions on what a "good operator" should do,
use statistics to verify that applying these assumptions as rules have a
sufficiently high true positive and false negative rate and then call
them "deterministic".
Wow, really, is that how you read my text? It conflicts with my
philosophy.
Sorry, no. In fact, deterministic concepts really do not need the
operator to be involved to make a decision. He just enabled it or not.
It is the protocol negotiation violation that is 100% repeatable,
everywhere, that makes it popular and workable.
With domain policy protocols, like SPF, we are fundamentally accepting
the domain is telling us what to expect with no fuzziness. A SPF
domain may use a softfail or neutral result, and we are asked not
reject on that. So we don't. But SPF says to reject on a hardfail,
so we do. Of course, a local policy can do what it wants. But does
not change the deterministic nature of protocol.
If other people do the same (but with assumptions that don't match
yours) you call it "subjective".
Yes, when you have different yields, yes, its nondeterministic, and I
would say subjective and also presents a security problem.
Every site that implements SPF, and they honor the domain policy, it
is expected that all sites will have exact yields.
With this SDO being the only site I am aware of that flat out rejects
ip-literal usage regardless of validity, right not, it is subjective
rule on that part only. You will not find that to be that case with
99.99% if the sites.
When everyone begin to do it, and we decide to clarify it in
RFC5321bis that ip-literal are obsolete and we loosen the MUST NOT,
then it becomes part of the protocol and that point, i would consider
it to be deterministic and no longer subjective, even thought the
decision to do this, probably with an extremely rough WG concensus
(BAD) was subjective decision.
By far, CBV is the highest payoff filter right now, today,
bar none, than any other known method.
There are some people (not me) who consider CBV abuse.
I get it. That is why I would never attempted to recommend it to be
IETF standard or seek IETF approval. But it works extremely well. Its
a black box to me:
result = CBV(reverse-path)
Today, CBV is a fast small footprint, single function SMTP client (see
below). Tomorrow, maybe the function can be replaced using advanced
'reverse-path' ESMTP extension. I remember trying VRFY and I don't
think many sites have opened themselves to VRFY despite it is a low
usage SMTP command MUST requirement.
Finally along those lines, once upon a time, a set of IETF cogs
vehemently preached against GreyListing, SPF and ADSP for the same
basic reasons and today, they are on board, completely or partially.
With ADSP, the same folks who had it erroneously abandoned, brought it
back as DMARC without resolving the same problems ADSP was abandoned
for -- 3rd party authorization concepts.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, (continued)
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version,
Hector Santos <=
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Jeremy Harris
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version, Keith Moore
|
|
|