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

[Julien ÉLIE]

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.*:%s at moderators.isc.org: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)