[Top] [All Lists]

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.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>