John C Klensin wrote:
However, I hope that folks keep in mind that reality tends to
override working group consensus.
As long as we can agree on what the reality is, of course.
well, umm, err... yeah.
And that's all I am suggesting here, but by a minimizing
approach, rather than trying to create new language.
There isn't much "creating new language" implied in anything
I've seen and understood. There have been some suggestions
> about changing a MUST to a SHOULD, which is certainly not new
Strictly speaking, changing words means making new words, although of course
that's a quibble. In reality, I was too terse and too academic. Sorry.
I wanted to mark one end of a spectrum, and didn't make clear that I was
talking more broadly than the immediate MUST->SHOULD proposal.
That said I think that "SHOULD" entails risks on a par with retaining MUST:
Current reality is fuzzy and changing. A core email spec making *any*
statement in this arena is likely to find itself undermined relatively
quickly, and that assumes (as above) that folks can agree that true community
consensus -- at this moment -- is SHOULD.
Note also that removing text that provides very strong guidance
that a particular test is not especially useful is not, IMO, a
"minimizing approach", unless your definition of minimizing is
the trivial one of simply reducing the word count.
It takes the core spec out of any attempt to assert correct policy for this
particular issue. Rather than try to walk a line, be subtle or otherwise
finesse things, it simply treats the issue as out of scope.
Reducing scope certainly seems like a minimizing approach, to me.
In all that
has changed in the last several years, I've heard no suggestions
that the value of this test _as a criterion for rejecting a
message_ has significantly increased.
I wonder how much of the email anti-abuse community has polled on this issue?
The receiving server does a DNS lookup, type=A, on
"smtpout.example.com". It fails. Do you want to _reject_ this
message or encourage anyone to do so based on that information?
Or suppose it does do the type=AAAA lookup as well as the type=A
one. It gets back the IPv6 record but, because of the
packet-level address remapping gateway, that address is not the
same as the address of the TCP connection to the SMTP port. Do
you want to _reject_ the message on that basis?
I think you have, as usual, done an excellent job of showing an example that
underscores the complexities in this arena.
My point is that a core spec should try to avoid such complexities, if it can.
In this case, it can, merely by dropping the text.
It's not that the topic is not important. It is that it is messy, has become
poorly understood, is part of a significantly changing landscape of policy
formulations, and currently demonstrates a pretty wide range of community
operational preferences, from what I can tell.
Do you even want to mark it "suspicious" before delivering it?
Fortunately, 2821bis takes no position at all on that subject.
Again, that's the point: rejection vs. marking are points along a continuum
of choices and the core mail transport spec need not cover it, nevermind cover
it partially.
I think I agree with your principle, but not with the
application to this text, for the reasons above.
Well, heck, *that's* never happened before...
Two added comments:
Noted. Certainly a conciliatory effort. My own view is that the real issue
is with any normative text in this arena, but your text is a plausible fall-back.
d/
ps. We've explored our views pretty thoroughly. Absent any sort of emerging
view that my suggestion be pursued further -- and my observation is that the
emergence is most definitely absent -- I'll retreat back into my corner.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net