Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
We also ask that participants consider and list the following
ramifications regarding deployment issues:
I quite agree with Dave Crocker that we need to discuss semantics
of information to be stored to intelligently decide "identities".
Yakov has specified simple semantics which are an excellent start:
"
" 1. HELO - expect all mail that uses my domain name in the HELO parameter
" to come from these IP addresses.
This is good semantics, even if HELO is not usually checked. I
see no reason why HELO need be forged.
" 2. MAIL FROM - expect all mail that uses my domain in MAIL FROM to come
" from these IP addresses.
This is lacking a little: What does the domain-owner want you to do
with MAIL-From that isn't from one of those IP addresses? And, horror
of horrors, need you look through the RFC2822 headers to satisfy the
question?
IMHO, we need several sets:
- known-good IPs -- these are fully authenticated;
- believed trustworthy -- OK if a known-good is in the Receved headers;
- believed-bad IPs -- recommend discarding.
(note, this is semantics only: whether we whitelist, blacklist, or some
combination is an implementation detail.)
And, there is the possibility that some domain owners will want to
have different rules for different clue-levels of users: at the least,
there should be room for expansion to these.
" 3. in-addr-arpa - expect all email from a given IP to be legit or
" nonlegit, or perhaps tied to a domain.
No opinion.
" 4. RFC2822 - expect all email from my domain to have non-forged "From"
" headers.
This is good, if restated a bit: "we enforce a rule against
misleading RFC2822-From addresses in our MTAs at these IP addresses;
please email <abuse(_at_)domain> if you observe any violations.
(BTW, the same could be said for any other RFC2822 headers.)
====
I need to be off to a dinner engagement -- I encourage discussion
of these semantics, and adding _semantic_ details if needed.
More to follow...
--
John Leslie <john(_at_)jlc(_dot_)net>