ietf-smtp
[Top] [All Lists]

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

2019-12-23 10:34:55
On 12/23/2019 9:48 AM, Peter J. Holzer wrote:
On 2019-12-20 16:14:01 -0500, Hector Santos wrote:

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.

I agreed and I have admitted I have a single rule for comparing the ip-literal with the connection IP. Mismatches are rejected. There are some cases (MUA behind the NAT) where there are a FP, resolved with authentication requirements. I believe this test is a correct technical SMTP check compared to a subjective, nondeterministic conclusion to block all ip-literals that technically violates SMTP.

That say, in the spirit of RFC2821, again, the CBV probe predated RFC5321 and I was the one who asked Klensin for some guidance and verbosity on the 2000s growth of new mail filters, including new EHLO filters. Section 7.9 was a result.

Keep in mind CBV and SPF were developed and implemented around the same time. SPF also has HELO/EHLO checking. A rejection was now possible for any filtering reason on HELO/EHLO. It was a black box now:

  result = CHECK_HELO(client.hostname, client.ip)

where CHECK_HELO() can consist of new considerations:

  - ip-literal test
  - SPF test

SPF needed a delay to see what reverse-path was provided. So it was not just about a CBV probe but EHLO [ip-literal] correctness for my SMTP receiver.

The EHLO [ip-literal] filter I implemented was based on original Modem Hosting Caller ID methods and logic that we offered in our 1980s Online BBS hosting package which many 3rd party developers implemented into create "New Sign up" add-on scripts. Today, while all that is legacy, Wildcat! still offers modem based hosting for federal, major enterprise, banking, inventory, payroll and billing private file/mail exchange networking.

So I believe the EHLO [ip-literal] test is a technically correct justified one that is not based on some "feeling" that all users should be lumped under the same category, in particular when it doesn't validate what it is enforcing MTA to do.

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.

ok, I wonder if I can do this:

EHLO ip-literal   ; no squared brackets

and see if the SDO site allows it. I suspect it will. I could just do the right thing and provide a valid FQDN, if available. But who are we really addressing when anyone can just make it a value known to skip & preempt some delayed check?

My philosophy is simple; where ever possible strong SMTP compliancy, without breaking it, can applied, in order to raise the bar to move the legacy MTA into current levels of SMTP compliancy, is a good thing. I don't believe bad guys complain, only good guys when it comes to impact. Bad guys will not bother with it. Smart ones will adapt - a good thing but bad for detecting bad content. Good guys will always adapt. But in this case, again, imo, it is based on a bad reason and it will cost developers time and money to changed their code -- painfully unnecessary but ....

If we want change, then go for the big bang. Naybe the real desire here is to completed eliminate the EHLO machine identifier idea and only use EHLO for what is really for -- to negotiate client/server capabilities.

I already whitelist the SDO. What I hope is that others do not follow the SDO lead here. If they do, then I will forced to consider change code and we will have no choice to update the specs. I can just set it now and forget about it. I would have to test to see what impact it will have, short residence times vs longer residence time due to PTR lookups but I can't manually set a host name because everyone is different. The more I can make it plug and play, the better it is, one less item to configure, the less support issues I have, and all that is a lesser cost of development and adds to a lesser TCO. This is a legit mail engineering consideration.

Thanks

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