[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]

2007-03-26 02:04:03

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 <> or
the <path-identity> in chapter 3.1.5 of the NetNews RFC actually

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