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. Updating Path header fields with path diagnostics (Julien ?LIE)
2. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Julien ?LIE)
3. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Jan 2023 19:20:17 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Updating Path header fields with path diagnostics
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
I'm having a look at implementing path diagnostics "!", "!.MISMATCH."
and "!.SEEN." in innd.
(For those who do not know, they are described in Section 3.2 of RFC 5537.)
Ticket #33 contains a patch against INN 2.2 which needs rewriting and
discussing.
It adds a "pathmatch" parameter in incoming.conf, expecting a wildmat
pattern and defaulting to the label of the peer. If the first path
identity of an incoming article from a peer matches the pattern value of
that parameter, then a double "!!" will be prepended to the Path header
field to show it has been successfully verified.
If the first path identity does not match the pattern, "!.MISMATCH." is
prepended along with the peer IP (from inet_ntoa), and a notice log is
written to say there's a path mismatch (the log is written only once per
connection from the peer).
"!!" for articles coming from a Unix domain socket.
"!.SEEN." with the peer IP for all other cases, without any notice log.
I would propose:
- no default value for "pathmatch";
- "!!" if the first path identity matches "pathmatch" when set, or if
unset, equals the label of the peer;
- "!.MISMATCH." with the peer IP if the first path identity does not
match "pathmatch" when set, and a notice log once per connection;
- "!.SEEN.localhost" for articles coming from a Unix domain socket
(except of course when the path identity corresponds to nnrpd's
"!.POSTED" - we do not add a path diagnostic in that case);
- "!.SEEN." with the peer IP for all other cases, without any notice log.
This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. Otherwise, if the
path identity is not the label, a mismatch will automatically occur.
I'm also unsure we should prepend "!!" to all the articles received from
a Unix domain socket (like posts through rnews). The path identity may
be different than the one of the remote peer. That's why I suggest
"!.SEEN.localhost".
Any thoughts about that, or other suggestions?
Does it sound good to you to unconditionally update the Path header
field this way? (It is a SHOULD in RFC 5537.)
Or should we provide a way to disable it globally, per peer and also for
local sockets in incoming.conf?
--
Julien ?LIE
??Quand on demande aux gens d'observer le silence, au lieu de l'observer
comme on observe une ?clipse de lune, ils l'?coutent?!?? (Raymond
Devos)
------------------------------
Message: 2
Date: Sat, 21 Jan 2023 23:40:54 +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,
>> This "Auto-Submitted: auto-generated" header field could then be used in:
>> - Daily Usenet reports (news.daily);
>> - newgroup/rmgroup/checkgroups reports (controlchan);
>> - top1000 reports (sendinpaths);
>> - failure or warning reports from various programs (mailpost,
>> expirerm, rc.news, innwatch, writelog);
>> - our internal wrapper to sendmail or like (innmail, with a new option
>> that will add it, as some use cases may include manually generated
>> mails -- most of the above programs use it).
>
> I really like what you're thinking.
With your details about "auto-replied", mails from controlchan seem to
belong to the auto-replied category instead of auto-generated. As a
matter of fact, the reports (actions taken or that should be taken) are
sent when receiving a control message.
I would then use "Auto-Submitted: auto-replied" for controlchan.
Same thing for failure reports when treating a message, as mailpost
does. It is an auto-replied mail, not an auto-generated one; and RFC
3834 even has a note about it (for non-delivery reports):
Some widely-deployed SMTP implementations
currently use "auto-generated" to label non-delivery reports.
These should be changed to use "auto-replied" instead.
So you're right that we should consider any actions triggered by the
reception of a message as an auto-reply, and not an auto-generation.
>> Are we OK that the following 2 use cases should *not* have that header
>> field?
>> - mails generated for the news -> mail gatewaying process;
>> - mails generated for the moderating process (posts to a moderated
>> newsgroup without an Approved header field).
>
> I think that these can have a different value -- from memory* --
> auto-replied.? These types of things are mechanical / automatically
> generated messages "that are in direct response to other messages or
> manually generated messages". >
> But if you don't agree with the auto-replied, them I'm perfectly fine
> not having the auto-submitted: header in this small subset of messages.
I agree that these two processes (gatewaying and moderation) fall in the
auto-replied category.
My worry is that we'll end up injecting articles with an Auto-Submitted
header field into Netnews.
The moderation software will receive an article encapsulated into a
mail, with an Auto-Submitted header field. I guess it does not know
that header field, and keep it when posting the approved article. And
we'll have Auto-Submitted header fields in most of the articles posted
to moderated newsgroups...
Same thing for the resulting mail or article when gatewaying.
That's why I am still not inclined to add that header field for these 2
cases. I don't want to generate possible unforeseen problems.
I'm otherwise OK with all the reports mentioned at the beginning of this
mail.
> N.B. I'm now 15 hours into a server outage recovery that started about
> the time I was going to go to bed.? I've not slept yet.
I hope the problem is now solved and have recovered from your lost sleep
hours :-)
--
Julien ?LIE
??Quand on demande aux gens d'observer le silence, au lieu de l'observer
comme on observe une ?clipse de lune, ils l'?coutent?!?? (Raymond
Devos)
------------------------------
Message: 3
Date: Sun, 22 Jan 2023 09:28:37 +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
In addition to my previous message:
>>> This "Auto-Submitted: auto-generated" header field could then be used in:
>>> - Daily Usenet reports (news.daily);
Correctly received one this night with that header field :-)
> I agree that these two processes (gatewaying and moderation) fall in the
> auto-replied category.
> My worry is that we'll end up injecting articles with an Auto-Submitted
> header field into Netnews.
> The moderation software will receive an article encapsulated into a
> mail, with an Auto-Submitted header field.? I guess it does not know
> that header field, and keep it when posting the approved article.? And
> we'll have Auto-Submitted header fields in most of the articles posted
> to moderated newsgroups...
> Same thing for the resulting mail or article when gatewaying.
On second thoughts, gatewaying and moderation should already be robust
to any kind of additional header fields added during the mail
transmission (SMTP relays, scoring, etc.) so it shouldn't normally do
any harm to add Auto-Submitted.
(When using INN's mailpost, this header field will be converted to
X-Auto-Submitted.)
--
Julien ?LIE
??Dans toute statistique, l'inexactitude du nombre est compens?e par la
pr?cision des d?cimales.?? (Alfred Sauvy)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 146, Issue 5
*******************************************
