Proposed death of verifycancels

[Bill Davidsen]

On 8 Jun 2000, Russ Allbery wrote:

> Does anyone use and want to keep the verifycancels inn.conf option?  If
> so, speak up now; I'm proposing removing it from the CURRENT tree.  The
> current USEFOR standard says not to verify cancels in that fashion and I
> don't think it serves any useful purpose these days.
> 
> For those not familiar with it, the current verifycancels option checks
> the From/Sender of the message against the From/Sender of the cancel and
> only allows the cancel if they match.  Of course, the canceller can just
> forge the From/Sender (and most of them know to do this), plus the check
> isn't and can't be performed if the cancel arrives before the original
> message.

  Turn that around... the existing code does not catch any valid cancels,
but it does catch some poor forgeries. So... does some good, does no harm.
Unless someone can make a point that it actually blocks a legitimate
cancel, I would leave it in until the "new cancel" logic has been out for
a while and some clients are actually using it.

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.