add "Auto-Submitted: auto-generated" to generated EMails?
Julien ÉLIE
julien at trigofacile.com
Tue Mar 14 11:41:34 UTC 2023
Hi Russ,
> Use of fake email addresses on Usenet is ubiquitous, and those who don't
> use them are often using providers with SPF or DMARC, so lifting the email
> address of the poster into the envelope sender is a recipe for various
> errors or straight-up rejection of messages due to DMARC rules or even
> basic deliverability checks. Instead, messages normally have the local
> newsmaster mailbox as the envelope sender, so that's where the bounces go.
> (I believe that's the only thing INN supports, although I haven't looked
> at it recently and maybe my memory is faulty.)
The default MTA line in inn.conf is:
mta: "@SENDMAIL@ -oi -oem %s"
-oi or -i
ignore dots alone on lines by themselves in incoming messages. If this
options is not specified, a line consisting of a single dot shall
terminate the input.
-oem or -em
mail errors back to the sender. (default)
nnrpd will just run sendmail -oi -oem <moderator-address> with the
following message:
To: <moderator-address>
<article headers & body>
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.)
Should something be improved there? (explicitly setting -f <newsmaster>
may astonish newsmasters who will receive bounces for which they cannot
do anything)
> Which brings us back to my point in the original discussion: we need some
> way to know which moderators are able to receive encapsulated messages and
> change how they're sent messages based on that configuration.
Couldn't a moderators.method file be published in ftp.isc.org (along
with active and newsgroups) to centralize that?
It would contain commented lines or "wildcard whitespace
method1,method2,..." lines to specify which method(s) can be used.
If the group is not listed, we suppose the legacy method is required
(proto-article sent as an email without any encapsulation). A final "*"
entry could also be explicitly set.
# All the moderated groups in comp.* accept the encapsulation defined
# in RFC 5537 with a Content-Type of application/news-transmission,
# as well as the legacy method.
comp.* news-transmission,mail
# Only the legacy method is accepted, though, for this group.
comp.compression.research mail
# Default.
* mail
The first matching wildmat is used.
We could also use ":" as a separator instead of whitespace. It would
then be consistent with the existing moderators file which defines the
address to send the mails.
Re-using the existing moderators file (adding for instance a third
field) sounds a bit disruptive, but could. It would mean lines like:
comp.*:%s at moderators.isc.org:news-transmission,mail
When several moderated groups are present in the Newsgroups header
field, the moderator of the leftmost moderated newsgroup (the one who
received the mail for approval) will have to ensure that he forwards the
message in a format that the next moderator can cope with. It may
indeed differ.
--
Julien ÉLIE
« C'est la goutte qui fait déborder l'amphore ! » (Assurancetourix)
More information about the inn-workers
mailing list