Frank Ellermann wrote:
Hector Santos wrote:
I hope it's 100% clear
that I do NOT support to move 2821bis more or less "as is" to DS.
I do NOT support its underlying "first priority is try to deliver"
assumption at the border MX,
I understand that is a generalize statement, so without the details I
would not know why you have that position. Every server's first
priority is to deliver the mail. Otherwise how would you expect the
system to work? (thats a rhetorical question). But that doesn't mean
there isn't any checking or rather neglects for the prerequisites before
reaching a state for delivery consideration.
But on that firm ground it's IMO a good idea to fix known errors
in 2821bis, and the "one dot" rule fascinates me since I've found
it. You might consider it as irelevant nonsense, but things get
more interesting if implementors try to understand what RFC 4408
chapter 4.8 <http://tools.ietf.org/html/rfc4408#section-4.8> or
the <path-identity> in chapter 3.1.5 of the NetNews RFC actually
mean.
I don't consider it irrelevant. Just seems a lot of time wasted with
arguments going around which seems to predicate itself on what you seem
to illustrate, I think, are broken documents. Don't know, 99% of the
time I get lost in your web of documents analysis emails. :-)
We've already established that there are no "trailing dots" in
(2)822 up to 2822upd-00. OTOH (2)822 in theory supports TLDs.
If you're not interested in that issue just ignore it, obviously
John is trying to get it right. I vaguely recall an I-D where
TLD operators complained about bogus queries, and I think that
could be related to HELO checks for crap like "HELO oemcomputer".
And at that point it might also interest you, AFAIK you support
strict syntax checks in ESMTP, including but not limited to EHLO.
Sure. I think it is important if we are going to make any headways in
the "fight" against the exploitations of the system.
But I also think there are "exceptions to the rule" as well. It could be
a matter of recognizing your peers.
Case in point, The Thunderbird MUA violates the EHLO [literal] when the
client is residing on a private address behind a NAT. TBird attempts to
get the FQDN and if not available, it uses the domain literal for the
client machine. If a server is checking for strict IP correctness, it
might fail this transaction.
I spent time working with the Mozilla folks to get this corrected late
last year for their next v2.0 version, which will include an user option
to define the NAT machine IP address. Also among the fixes is a lack of
a support for 55x responses (it just continued to the next command) and
the lack of a QUIT during certain errors.
Our solution for current clients was to offer a local policy option to
relax EHLO domain literal checking for SUBMIT (port 587) transactions
because there is an inherent expectation and requirement for a pending
ESMTP AUTH login. Otherwise under a port 25 connection, the invalid
domain literal IP will be rejected (by default).
--
+HLS