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: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Julien ?LIE)
3. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Fri, 7 Jan 2022 13:57:05 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> 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?
>
> 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.
OK, it's true that it's up to the posting agent to ensure it properly
sets the Newsgroups header field. No harm done if that's not the case.
> So, basically, I wouldn't bother. I think it would just be extra
> complexity in INN to no real purpose.
Let's remove this parameter; we already have enough :-)
Contrary to syntax checks and other nits that could cause
interoperability issues, this one is not necessary to verify at
injection time by nnrpd, indeed.
--
Julien ?LIE
??Boire du caf? emp?che de dormir. Par contre, dormir emp?che de boire
du caf?.?? (Philippe Geluck)
------------------------------
Message: 2
Date: Fri, 7 Jan 2022 13:59:31 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Grant,
[about retiring "innd -C"]
>> I think it shouldn't be a no-op; it should either work to override the
>> config setting or we should remove it so that it will cause an error
>> and people will have to update their configuration.? Otherwise, I
>> think we risk silent and surprising behavior change.
>
> I too am against the no-op.
>
> I'd much rather see it be a warning for one (or more) versions and
> eventually be tantamount to a syntax error to fail hard / fast.
That sounds great for a soft transition period. I'll put a warning in
2.7.0 and really remove it in 2.8.0.
--
Julien ?LIE
??Boire du caf? emp?che de dormir. Par contre, dormir emp?che de boire
du caf?.?? (Philippe Geluck)
------------------------------
Message: 3
Date: Fri, 7 Jan 2022 08:39:17 -0700
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 1/7/22 5:59 AM, Julien ?LIE wrote:
> Hi Grant,
Hi Julien,
> That sounds great for a soft transition period.? I'll put a warning in
> 2.7.0 and really remove it in 2.8.0.
<ASCII thumbs up>
The only other thing that I might ask is that you include the exact
error message(s) in release notes / FAQ / what have you. That way if
(read: when) people hit the error and search for it (a la. fgrep -ir
"...") they will have a nugget of information to find.
Aside: Is doing the same in the source going too far? As in "Use the
Source Luke!". ;-)
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20220107/3d7bc71a/attachment-0001.bin>
------------------------------
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 4
*******************************************
