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