[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-20 12:55:30
On 2019-12-20 12:07:58 -0500, Hector Santos wrote:
On 12/20/2019 9:11 AM, Peter J. Holzer wrote:
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.

So how is 

    if re.match(r'^\[\d+\.\d+\.\d+\.\d+\]$', ehlo_string):
        return REJECT

non-deterministic? This depends on only a single input parameter which
is completely under the control of the client. Send the same EHLO
command and you get the same response - always.

OTOH, you suggested "checking the remote IP address of the connection
against the address literal in the EHLO command" and "checking whether a
PTR record exists" as deterministic rules.

These not only have more input parameters (the remote ip address and the
result of a DNS query respectively), those are subject to temporary
changes: The IP address may change because of routing changes and NAT
gateways, DNS responses may be lost or outdated. So while the algorithm
itself may be deterministic, the result is not, because some input
parameters are prone to random fluctuations.

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

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.

Well, enabling a specific check or not is a decision. Nobody expects a
human to be directly in the loop during an SMTP transaction.

It is the protocol negotiation violation that is 100% repeatable,
everywhere, that makes it popular and workable.

There is no protocol violation. There is your (the developer's) personal
opinion on how a sending MTA on the public internet should be
configured. I may personally agree with them, and you might even do a
survey and find that "97 out of 100 experts agree", but it's still a
personal opinion, not part of SMTP as specified in RFC 5321.

You apparently keep stats and check them periodically, which is good and
- as Keith so forcefully pointed out - is more than many ESPs do. I
don't say that what you are doing is wrong - in fact it seems like a
quite sensible thing to do - but it certainly doesn't match your claims.

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.

You seem to have missed my point. My point is that whether you call
something "deterministic" or "subjective" seems to depend on whether you
came up with the idea or someone else instead of any actual determinism
of the rule. (See example above).

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

Just as subjective as your rule that the peer address must match the IP
literal, or your suggestion that an IP literal must onlybe used if there
is no PTR record. Both may be good practice, but they are not mandated
by the RFC.

And even for outright syntax errors you might choose to tolerate them.
For example, the RFC is quite clear that there is no space between ":"
and "<" in "MAIL FROM:<foo(_at_)example(_dot_)com>". Yet enforcing that rejects
quite a lot of legitimate mail (or did, when I last tried it). So there
is an assessment of the pros and cons of being conservative or liberal


   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp(_at_)hjp(_dot_)at         |    -- Charles Stross, "Creative writing
__/   | |       challenge!"

Attachment: signature.asc
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>