We had a recent case where a large ISP was
being inundated with bogus messages. (I don't know if this was DOS attack or
merely spam.) The messages were coming from a variety of different
addresses on
a variety of different networks. But the one thing they all had in common
was
that they had the exact same domain listed as their EHLO argument. The ISP
actually went to the trouble of contacting the owner of this domain name and
was informed that the owner would under no circumstances actually use it as
an
argument to EHLO.
Of course a block in such a case will only work for as long as it takes the
people sending the messages to realize what's going on and work around it.
But
do you really think it is wrong to impose a temporary block of this one
argument value in this specific case?
no. and neither do I think that it's a good idea to categorically forbid
implementations from providing hooks to do that - because of that rare
specific case where it really is the right band-aid.
at the same time, we recognize that there's a lot of ignorance out there, and
some hooks are more easily misused than others.
Agreed. And this particular one is particularly easy to misuse.
so what is the best way to discourage misuse of such hooks, or more generally,
to discourage poorly-chosen filtering policies?
I think the current text actually does a pretty good job. It allows
verification but specifically prohibits using that particular result as a
filter. It says nothing that forbids filtering based on a specific string or
some other basis, however. I thought you were arguing for changing that, which
is why I spoke up.
I guess my position is that clarification of the text would be fine, but
changing what it says is allowed is not.
Ned