Alan DeKok wrote:
Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
Paragraph 2 is bluntly wrong. The intent of creating LMAP is that eventually
it WILL be used to reject mail, because it is assumed to be forged.
Absolutely not.
The intent is to publish information which lets the recipient MTA
make that decision. This is a very different statement of intent than
what you wrote.
I expect that *many* implementors of LMAP will choose to reject
non-compliant messages, but it would be inappropriate for anyone to
say that those MTA's are *required* to reject mail based on LMAP.
Perhaps I wasn't clear. I didn't mean that recipient MTAs *MUST* 55x
LMAP-violating mail, I meant that they would be explicitly *allowed* to,
which is contrary to the wording in the most recent draft.
I don't like how the comparison section phrases LMAP as a modification to
RFC 2821. I suspect that such wording will raise a lot of unnecessary
resistance to LMAP for no particular reason. I interpreted that part of RFC
2821 to mean that recipient MTAs should not reject mail on the basis of the
the HELO name not resolving to the connecting IP or the connecting IP not
reverse-resolving to the HELO name. Following this interpretation, LMAP
suggests neither, and thus is no modification to 2821, only an application
of the liberties of "local policy"-based rejections.
I agree. The text in the -00 draft tried to explain this
distinction.
The -01 document says: (2.2.5, page 7)
HELO/EHLO-based LMAP would
modify RFC2821 by allowing the server to reject mail based on
HELO/EHLO validation failure.
I disagree completely. The HELO/EHLO validation in RFC2821 is about
looking up the reverse IP of the originating MTA, and seeing if the
name returned is the same as the HELO/EHLO field. LMAP does something
completely different, it looks up in the domain of the HELO/EHLO
field, to see if the originating IP is permitted to claim association
with that domain.
Glad we're agreed on this point.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg