Doing so directly
sanctions the sort of behaviour that has created the need for this
document to begin with.
that's a silly statement. it's one thing to insist that mail responders
minimize potential harm, quite another to insist that they use one
particular mechanism which is known to not work adequately in practice.
Why doesn't it work? Because people have caved in to those who violate
the standard. If those people (the violators) will let their ignorance
turn <> into something useless, how could you possibly think they
won't do the same to any other facility we come up with?
<> is less useful than it should be because people hate spam so much
that they'll try anything to stop it, including blocking mail from <>.
yes, this is ignorant. but there's a lot of ignorance out there.
however, I don't imagine that there will be nearly as much pressure
to abuse the mechanisms we define for mail autoresponders.
This isn't a silly issue, it's a practical one.
Indeed. Under current circumstances it's impractical to insist that
autoresponders use <> for a return-path.
And it's symptomatic of the
prevailing attitude that has led us to be in the situation we are in
today.
on the contrary, people are refusing mail from <> despite what the
standards say, not because the standards permit this.
Now you can write the most wonderful ID imaginable, but if we
chose to not enforce it in the way we've not enforced other aspects of
the protocol, we'll simply be having this conversation all over again
in a couple of years.
no, "we" won't be having this conversation, because I won't consider
it worth my time. standards are only valuable if they make useful
recommendations that work in practice. if you think we can "enforce"
anything, you're seriously deluded.
I don't see any need to debate this subject further.
Keith