Re: add "Auto-Submitted: auto-generated" to generated EMails?

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.*:%[email protected]: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)
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers