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: add "Auto-Submitted: auto-generated" to generated EMails?
(Julien ?LIE)
2. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Julien ?LIE)
3. INN 2.7.1 release candidate (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Mar 2023 19:38:02 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Grant,
>> Yes, indeed.? Although I do suspect that would result in better
>> deliverability of moderated group submissions.
>
> If we're tweaking how things are being sent, perhaps also explore some
> ESMTP options like setting notify or what's returned (headers vs full
> message).
Is this something we can do at the level of INN?
I am under the impression it is a configuration of the MTA, and we
cannot do much within INN.
Should we just add a sentence in the description of the mta parameter in
the inn.conf manual page?
Something like "If you want to monitor the deliverability of mails sent
by INN programs (notably to moderators, gateways or TOP1000 project),
you should tweak the configuration of your local MTA, for instance by
enabling bounce in the notify_classes parameter of Postfix."
Beware that if we say something in the documentation, we will surely
receive questions about it (how to configure it, etc.).
I'm not expert on mails, so maybe that's not the right thing to do. As
the envelope sender is not set (-f not used in the sendmail command),
bounces may not work?
Should we also recommend to add "-f <newsmasteraddress>" at the end of
the mta line (whose defaults to "/usr/sbin/sendmail -oi -oem %s") to
better monitor the deliverability of mails?
Any other thing?
>> Some sort of centralized database like that is presumably the
>> solution, though, whether at ISC or on GitHub or somewhere else like
>> that. Not eyrie.org, though; there's too much Usenet stuff that
>> depends on me personally already.? :)
>
> Is there a way to distribute this so that's it's not centralized?? The
> first thing that comes to mind is DNS.
Which domains should have their DNS updated? It seems that
moderators.isc.org should list all the configuration, and also possible
other sites mentioned in the moderators file (fido7.org,
nl.news-admin.org, etc.). It's still somewhat centralized.
--
Julien ?LIE
??Tous les champignons sont comestibles. Certains, une fois seulement.??
------------------------------
Message: 2
Date: Wed, 22 Mar 2023 19:38:12 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> We're not using the -f option to explicitly set an envelope sender
>> address. It seems that sendmail uses the contents of the From header
>> field by default. The envelope sender may then be invalid for articles
>> posted with an invalid From header field, and bounces won't then be routed
>> anywhere.
>
>> (innmail does not use -f either.)
>
> Oh, huh! That actually surprises me quite a bit, and makes me rethink
> parts of this discussion, since apparently we've been sending mail to
> moderated groups this way for a while.
I've just checked what Diablo does, and it doesn't set the envelope
sender either.
As a side note, I see Diablo removes To, Cc, Bcc and Path header fields
before sending a message to a moderator.
/*
* MailToModerator() - send mail to the moderator.
*
* Note: we have to unescape the posted article and we cannot pass
* certain headers. We cannot pass Path: because the moderator may
* forward it, causing the posting news machine to miss the approved
* posting made by the moderator (because it will have locked itself
* out due to the Path: ). We also do not pass To:, Cc:, or Bcc:
* headers for two reasons: First, because the news client is
* supposed to handle those fields and we don't parse them for
* non-moderated postings, and second, for security reasons.
*/
INN does not do that. The mailed message still contains these fields.
And if a To header field is present, the moderator mail is prepended to it.
However, the mail is *not* sent to these extra addresses as INN
explicitly calls sendmail with an argument specifying the unique
recipient (the moderator mail address).
Should we remove these fields too? (To, Cc, Bcc and Path)
As far as I see, there's no indication for that in RFC 5537.
>> Couldn't a moderators.method file be published in ftp.isc.org (along
>> with active and newsgroups) to centralize that?
>
> I guess... I'm not sure I really want to volunteer Todd and I for more
> work on that front, but at the same time it probably wouldn't be too much
> work.
Would it be at least possible to ask the current moderators whether the
tools they're using for the moderation process can cope with the
encapsulated application/news-transmission format?
And if not, whether they see any benefit from it and eventually plan on
updating their tools to support that format?
It would be a good start, and necessary to initialize the first list for
the "moderators.method" file (which may end up empty...).
Afterwards, when an update to a moderator address is asked, or a new
moderated newsgroup is created, the question about how to submit
messages should be asked.
> Some sort of centralized database like that is presumably the solution,
> though, whether at ISC or on GitHub or somewhere else like that. Not
> eyrie.org, though; there's too much Usenet stuff that depends on me
> personally already. :)
Let's first see the contents of the "moderators.method" file, and decide
afterwards where to store it.
At least we would need one for INN so we can begin by just having it in
the samples directory of the INN GitHub repository.
If other news servers also implement the new method, they may just grab
the file from here, or eventually ask to put it elsewhere (we'll see at
that moment).
>> comp.*:%[email protected]:news-transmission,mail
>
> I think you want to keep the submission wildcard address independent of
> the transmission method since I don't think those two things will be very
> correlated, which means you'll just end up with a combinatorical
> explosion.
Agreed then for a format like:
comp.specific.group news-transmission,mail
* mail
--
Julien ?LIE
??Sois sage, ? ma douleur, et tiens-toi plus tranquille.?? (Charles
Baudelaire)
------------------------------
Message: 3
Date: Wed, 22 Mar 2023 21:53:22 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: INN 2.7.1 release candidate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
A release candidate for INN 2.7.1 can be downloaded at:
https://github.com/InterNetNews/inn/releases/tag/2.7.1rc1
The tarball is attached as an asset at the end of the page.
Now we're using GitHub, we can modernize a bit our release process.
Russ and I propose that we no longer use the "testing" repository on
ftp.isc.org, nor provide checksums (we provided 4 checksums for a final
release! -- md5, sha1, sha256 and sha512), nor provide a diff from the
previous release.
These elements correspond to what can be found here for this rc1:
https://ftp.isc.org/isc/inn/testing/
(Note that the rc1 testing tarball in ftp.isc.org is 3 days older than
the one in GitHub I generated a few minutes ago because I needed a
dedicated Git tag to generate a "prerelease" in GitHub, and therefore
regenerated the tarball.)
It will be the last time we use the "testing" directory, which will be
removed when doing the final 2.7.1 release.
Naturally, final releases will still also be made available in ftp.isc.org:
https://ftp.isc.org/isc/inn/
but with only the PGP signature of the tarball.
In the GitHub release page, you'll find all that stuff (and even more).
You can obtain a diff from the previous release or from any other Git
tag, you can check that the signed release tag is "verified", you can
read the release announcement, and you can download the tarball. (For a
final release, the PGP-signed tarball will also be attached as an asset.)
Any worries about that change proposal in the release process?
The final release is scheduled next month (mid April) if there aren't
any reported issues.
Feel free to test this release candidate and report any issue you may
encounter.
Changes from 2.6.5 to 2.7.0
* Added a new *groupexactcount* parameter in readers.conf to force
nnrpd
to report the exact number of still existing articles in newsgroups
instead of an estimated count. When the estimated number of articles
is strictly below *groupexactcount* (set to 5 by default), nnrpd now
recounts them and reports the actual value (articles that have been
cancelled or overwritten in self-expiring CNFS buffers may otherwise
still be counted in the estimate). News clients will then be
directly
aware of empty newsgroups; they would otherwise have tried to
retrieve
possible articles, to finally not show anything to the user.
* Programs sending mails now include, when appropriate, an
Auto-Submitted header field in the message headers (either set to
"auto-generated" or "auto-replied", following the recommendation in
RFC 3834). Thanks to Harald Dunkel for this suggestion which
will for
instance help to avoid unnecessary vacation replies.
* Added a new -a option to innmail to specify additional header fields
to add in the headers of messages. This is notably used to
internally
support the addition of the Auto-Submitted header field in outgoing
mails.
* Added new ovsqlite-util program to perform some basic consistency
checks and dump operations on an overview database using the ovsqlite
method. More checks and features will be added in future releases.
You'll need the "DBI" Perl module with the "DBD::SQLite" driver
installed on your system to use this program.
* Added TLS support in pullnews for connections to upstream servers
configured in pullnews.marks, and to the downstream server in the
existing -s flag. A port can now also be specified for
connections to
upstream servers (it was already possible for the downstream server
only).
* Added a new -L option to pullnews to specify the largest wanted
article size in bytes. Articles whose size exceeds that value
will no
longer be downloaded by pullnews.
* pullnews now detects a socket timeout while downloading articles from
a remote peer. The download gracefully stops, and another
attempt can
be automatically made according to the setting given with the -t
flag.
Thanks to Jesse Rehmer for the bug report.
* Fixed the generation and the handling of storage tokens on wrapped
CNFS buffers, thanks to bug reports from Kamil Jonca:
* Duplicate entries were returned by makehistory on fully wrapped
cyclic buffers (the first article of the cyclic buffer appeared
twice in the output).
* The first article of a fully wrapped cyclic buffer was removed too
soon from history (expire wrongly thought its storage token was no
longer existing after a wrap).
* The first article of the previous cycle number of a cyclic buffer
containing articles from two different cycle numbers was wrongly
considered by makehistory to belong to the current cycle number.
* innd no longer dies when a newsfeeds entry has an unexpected trailing
whitespace.
* The size of duplicated articles was counted twice in totals, average
article sizes and graphs by innreport, when parsing innd
checkpoints.
Thanks to Hauke Lampe for the patch to count it only once.
* Customizing the domain part of Message-IDs generated by nnrpd and the
server name indicated in Injection-Info header fields is now easier:
the *domain* parameter in the access blocks of readers.conf can be
directly used (without needing to set *virtualhost* as it was
previously the case).
* If the *domain* parameter is set in inn.conf or in a readers.conf
access block, and has invalid characters, or if the fully qualified
domain name (FQDN) of the news server has invalid characters when
*domain* is unset, a fatal error is now reported at startup. It is a
basic configuration error which otherwise leads to the generation of
invalid article Message-IDs.
* Improved the speed of article searches with HDR, LAST, NEXT, and XPAT
commands when there is a (huge) gap in article numbers. On
newsgroups
with several millions of consecutive missing articles (which is a
rare
situation), these commands could take several seconds to run.
* Incoming articles in newsgroups that have exceeded the maximum number
of articles they can contain (2^31-1) are now correctly rejected.
INN
was otherwise happily accepting them but either numbers returned in
NNTP responses were not right, or some news clients choked when
receiving unexpected large article numbers. (The current version of
the NNTP protocol only allows article numbers up to 2^31-1.)
* Fixed the renumbering of reported low water marks for empty
newsgroups
in active after overview expiration, when using the ovsqlite method.
They were set to 1 for empty newsgroups whereas they were not
supposed
to decrease. (These reported low water marks regained their expected
values during the next overview expiration, provided that the
newsgroup was no longer empty.)
* The reported high water mark of empty newsgroups is now correctly set
to one less than the reported low water mark in overview data.
(Previously, the reported low water mark was set to one more than the
reported high water mark.)
* Fixed the output of the "ctlinnd feedinfo ''" command that was
returning information only for the first site, and the output of the
"ctlinnd name channel" command that was returning partial information
for the requested channel.
* The build of external programs which include inn/storage.h was
failing
because of the unexpected inclusion of config.h in one of the
included
headers. Also, a few Autoconf results were not correctly made
available to external programs. This is now fixed.
* Fixed the build on systems whose default shell does not completely
meet the Posix standard. A few build scripts were run with the
default shell instead of the one found by Autoconf and afterwards
used
for INN.
* Use standard daemon(3) C function, when available, to daemonize innd,
nnrpd, ovdb_server and ovsqlite-server instead of an INN-specific
function.
--
Julien ?LIE
??Ta remise sur pied lui a fait perdre la t?te?!?? (Ast?rix)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 148, Issue 9
*******************************************
