ietf-smtp
[Top] [All Lists]

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

2019-12-23 08:48:12
On 2019-12-20 16:14:01 -0500, Hector Santos wrote:
So Peter, I don't know if we are not agreeing, in my opinion, this specific
issue is much different that any other.

This is where we very much disagree. For me, what the filter deployed by
the IETF admin and the one you are using are morally exactly equivalent
(obviously they are not quantitatively equivalent, since on affects a
strict subset of the other): Both are heuristics which are based on a
characteristic which is relatively common in spam and very rare in
legitimate mail. As such, both must be exclusively evaluated on their
true positive and false positive rates and the context in which they are
deployed. Neither of you can claim the moral high ground.

It actually forces changes in MTA code to make sure it no longer uses
ip literals.

It seems to me that your CBV agent violates at least one MUST
constraint, so that might not be a bad idea.

IMO, that promotes changing the specs.

Not at all. The admin of one specific MTA implemented a heuristic which
happened to block one specific CBV probe which caused some mails to be
rejected. Such stuff happens. Changing the configuration of one or both
systems can fix the problem. No spec change necessary.

The discussion did however strengthen my belief that the paragraph from
section 4.1.4:

|   An SMTP server MAY verify that the domain name argument in the EHLO
|   command actually corresponds to the IP address of the client.
|   However, if the verification fails, the server MUST NOT refuse to
|   accept a message on that basis.  Information captured in the
|   verification attempt is for logging and tracing purposes.  Note that
|   this prohibition applies to the matching of the parameter to its IP
|   address only; see Section 7.9 for a more extensive discussion of
|   rejecting incoming connections or mail messages.

ought to be deleted. Not to legalize what the IETF admin did - that's
already fine - but what you did. Because you are directly violating this
MUST NOT and one might read that paragraph as having priority over
section 7.9. So that would mean that the more specific test is
prohibited but the wider test is allowed - which I find perverse.

Finally, I am not a regex guru,

The code snippet I posted was just pseudo-code which rejected any
sequence of 4 decimal numbers separated by dots enclosed in square
brackets. I have no idea whether this is the actual test used by the
ietf server (probably not). It was just intended to show that the
observed effect can be achieved by an entirely deterministic (and very
simple) algorithm.

        hp

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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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>