--Alan DeKok <aland(_at_)ox(_dot_)org> wrote:
millenix(_at_)zemos(_dot_)net wrote:
I interpreted that to mean that an EHLO cannot be rejected on the basis
of the EHLO argument not resolving to the peer IP address.
So the argument is a name in DNS (which allegedly resolves to an IP
address), but doesn't have to exist in DNS. Weird.
This is where I think rfc2821 is a bit inconsistent. It *should* be a
fqdn, but we may not reject it if it isn't.
I think implicit in that text is ...
This is where I get confused. Anything which isn't explicit in a
standard is implementation defined. MTA's are doing all sorts of
things with the argument to EHLO, but I'm not sure something which has
"implicit" or "implementation-defined" meaning will mean the same
thing to everyone.
Agreed.
That's how I'm looking at it. There are flaws in RFC 2821 that prevent
accountability and allow harmful forgery of various protocol fields.
We're here to fix that.
I agree. But I haven't seen much discussion as to *what* those
flaws are, or *why* we're fixing them. I'd like to have explicit
statements of the flaws, before we get in-depth into solutions.
One thing I mentioned would be that I would like to declare "we may not
reject invalid HELO arguments" part of 2821 as deprecated. Maybe I take
FQDN for granted, in this day and age... but I think it's time for the "may
not reject invalid helo" clause to be phased out.
(However, I stand by my initial statement that I MAIL FROM and
From:/Sender: checking is more important to *me* than HELO checking...)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>