Send inn-workers mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."


Today's Topics:

   1. Re: Discussion about Cancel-Lock support (Julien ?LIE)
   2. Re: Discussion about Cancel-Lock support (Russ Allbery)


----------------------------------------------------------------------

Message: 1
Date: Thu, 6 Jan 2022 19:18:39 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Russ,

> It may be worth considering getting rid of verifycancels while
> we're at it to reduce some complexity, since the check it enables is
> essentially meaningless and RFC 5537 actively recommends against this.
> Cancel-Lock support is the correct approach to achieve the same ends
> (although of course most people don't generate Cancel-Lock headers).

Having a look at innd's code to implement Cancel-Lock verification, I 
came into that verifycancels stuff.
It verifies that at least one newsgroup in the cancel message is present 
in the article to be cancelled.  Isn't it a check that should be kept?
It is not done by default.

RFC 5537 indicates that:

    To best ensure that it will be relayed to the same news servers as
    the original message, a cancel control message SHOULD have the same
    Newsgroups header field as the message it is cancelling.

So maybe the change to do is to only do the check in nnrpd (at injection 
time) and not do it when relaying?
The verifycancels option would then apply only at injection time, and 
should be enabled by default.  (Another possibility is to force it in 
nnrpd without configurable option.)



What RFC 5537 actively recommends against is that From and Sender header 
fields match, which is a check that was removed in INN 2.5.1 from innd.

Incidentally, I suggest removing that check everywehre in INN (I see 
that inews still does it).

-- 
Julien ?LIE

??J'oubliais qu'Assurancetourix a une nouvelle corde ? sa harpe?!??
   (Ast?rix)


------------------------------

Message: 2
Date: Thu, 06 Jan 2022 11:48:40 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Julien ?LIE <[email protected]> writes:

> Having a look at innd's code to implement Cancel-Lock verification, I came
> into that verifycancels stuff.

> It verifies that at least one newsgroup in the cancel message is present
> in the article to be cancelled.  Isn't it a check that should be kept?
> It is not done by default.

> RFC 5537 indicates that:

>    To best ensure that it will be relayed to the same news servers as
>    the original message, a cancel control message SHOULD have the same
>    Newsgroups header field as the message it is cancelling.

> So maybe the change to do is to only do the check in nnrpd (at injection
> time) and not do it when relaying?

RFC 5537 is recommending that for agents that generate cancels, since
otherwise the cancel may not propagate to the same servers as the original
message.  The problem caused by not doing this is that the cancel doesn't
reach the right servers and thus the article isn't cancelled.

In other words, this is a client issue where, if the client doesn't follow
that advice, the cancel may not work.  It's not a security issue, and it's
not really a server issue.  Cancels issued to the wrong group don't cause
any *harm*; if they're authenticated, they're still authenticated and thus
legitimate, and if they're not authenticated, who knows.

So, basically, I wouldn't bother.  I think it would just be extra
complexity in INN to no real purpose.  The agent generating the cancel
should get this right, but I don't think nnrpd needs to try to enforce it.
(And in general it may not be possible to check anyway, since the cancel
may be issued for an article the local server doesn't have, and thus has
no idea what Newsgroups to which it was posted.)

-- 
Russ Allbery ([email protected])             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.


------------------------------

Subject: Digest Footer

_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers


------------------------------

End of inn-workers Digest, Vol 137, Issue 3
*******************************************

Reply via email to