ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-10 13:00:23

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.

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.

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.

  Alan DeKok.


<Prev in Thread] Current Thread [Next in Thread>