Re: Input on identities

["Alan DeKok" <aland@xxxxxx>]

millenix@xxxxxxxxx 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.