Adjust the headers in announcement emails to make inappropriate replies less likely

[ietf-svn-bot]

resolution_fixed type_enhancement | by rjsparks@nostrum.com

---

See
http://www.ietf.org/mail-archive/web/codesprints/current/msg00288.html

---

Issue migrated from trac:811 at 2022-03-04 02:30:17 +0000

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

There is also a suggestion to use a To line like:
To: IETF Announce:;

with some concern that this would interact badly with homegrown or older filters.
Engage Pete Resnick and Barry Leiba while considering it.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From Pete and Barry:

1. Last-call announcements, and other messages for which we just want
   discussion to go to the IETF list:

   From: IESG Announcements <iesg-no-reply@ietf.org>
   To: IETF Announce:;
   Reply-To: IETF Discussion List <ietf@ietf.org>
   Cc: Working Group...
   Sender: <iesg-secretary@ietf.org>
   

   The From address will have some sort of bit-bucketed address -- if
   "iesg-no-reply" (or "ietf-no-reply", or whatever) actually gets
   included somewhere and receives mail, it'll just be silently
   discarded. We're not the happiest with that, and we considered
   something like "From: IESG Announcements ietf@ietf.org", but we're
   worried that such a thing might cause people to get bogus address-book
   entries that match up "IETF Announcements" with the address
   "ietf@ietf.org".

2. Messages sent by an entity that wants the replies; we could use
   this for WG Review messages, for example:

   From: The IESG <iesg@ietf.org>
   To: IETF Announce:;
   Reply-To: IETF Discussion List <ietf@ietf.org>, The IESG <iesg@ietf.org>
   Sender: <iesg-secretary@ietf.org>
   

   The Reply-To might or might not be there, depending upon how we'd like
   normal replies to be sent. There'll have to be a way for the sender
   to say whether s/he wants replies to include ietf@ietf.org, and
   whether the Reply-To should include what's in the From, or something
   else. For instance, we might want the From to be "IETF Chair
   chair@ietf.org" and the Reply-To to be "The IESG iesg@ietf.org",
   or whatever. The people making those sorts of choices will likely be
   ones who know what they're doing.

   The From could also be one of these (or others):

   From: The IESG <iesg-secretary@ietf.org>  (for cases where we want tickets)
   From: IETF Chair <chair@ietf.org>
   From: IETF Administrative Director <iad@ietf.org>
   From: The IAB <iab@iab.org>
   From: IAB Chair <iab-chair@iab.org>
   From: RFC Editor <rfc-editor@rfc-editor.org>
   

   The SMTP RCPT TO will still be ietf-announce@ietf.org. The SMTP
   MAIL FROM should be an address that we want bounce messages to go to,
   which should be one that does automated bounce processing. That's
   probably fine however it is now, and needn't change.

[ietf-svn-bot]

@henrik@levkowetz.com changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@rjsparks@nostrum.com changed priority from major to medium

[ietf-svn-bot]

@rjsparks@nostrum.com edited the issue description

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

Some notes based on v4.43:

There are many places that send mail, and a wide variety of setting From: using strings in code, templates, and variable retrieved from settings. Reply-To is sometimes, but not usually set explicitly.

The Liaison tools use DEFAULT_LIAISON_FROM consistently.
The draft submission tools use a suite of variables from settings consistently.

For the rest of the codebase:

Places that use DEFAULT_FROM_EMAIL from settings:

• community tracker, confirming subscribing and unsubscribing for notifications
• impending id expiration notification (idrfc/expire)
• creating and confirming new accounts (ietfauth/forms)
• wgtracker updates to tags, states, or streams (ietfworkflows/utils)
• sync discrepancy reports (sync/mails)
• sync draft update messages to the secretariat (sync/rfceditor)
• iesg state changes (idrfc/mails)
• stream changes (idrfc/mails)
• pull from rfc-editor queue notification (idrfc/mails)
• mail to draft authors (idrfc/mails)
• charter approval announcements (wgcharter/views)
• issuing charter ballots (wgcharter/views)

Places that have literal values coded into function calls:

• actual id expiration notice (idrfc/expire): I-D Expiring System ietf-secretariat-reply@ietf.org
• new IPR submissions (ipr/new): IPR Submitter App ietf-ipr@ietf.org
• notification of IPR to ADS/groups (secr/ipradmin/views): IETF Secretariat ietf-ipr@ietf.org
• notification of scheduled WG sessions (secr/meeting/views): IETF Secretariat agenda@ietf.org
• notifications of receipt of original or updated requests for a schedule slot (secr/seqr/views): IETF Meeting Session Request Tool session_request_developers@ietf.org
• general notifications to the AD responsible for a draft (idrfc/mails): DraftTracker Mail System iesg-secretary@ietf.org
• last call request from IESG to secretariat (idrfc/mails): DraftTracker Mail System" iesg-secretary@ietf.org
• completion of draft resurrection (idrfc/mails): I-D Administrator internet-drafts-reply@ietf.org
• ballot deferral (idrfc/mails): DraftTracker Mail System iesg-secretary@ietf.org
• notification of last call expiration (idrfc/mails): DraftTracker Mail System iesg-secretary@ietf.org

Places that have literal values coded into templates:

• conflict review evaluation message: iesg-secretary@ietf.org (doc/conflict_review/eval_email.txt)
• conflict review approval message: iesg-secretary@ietf.org (doc/conflict_review/approval_text.txt)
• issued ballots: (idrfc/issue_ballot_mailREDESIGN.txt) IESG Secretary iesg-secretary@ietf.org
• IETF stream document approval: (idrfc/approval_mail.txt) The IESG iesg-secretary@ietf.org
• Other stream approval (idrfc/approval_mail_rfc_editor.txt) The IESG iesg-secretary@ietf.org
  -- (I don't think this is used anymore)
• IETF last calls: (idrfc/last_call_announcement.txt): The IESG iesg-secretary@ietf.org

wgchairs/forms.py is special - it wraps util/mails with its own utility that explicitly sets from to DEFAULT_FROM_EMAIL from settings (rather than passing a None to util/mails), and then sends to many places.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

From e96cf00:

Reverted a change from 19dcf10, reinstating the explicit To: field for
last-call announcements, because removing it caused the copies of the
announcements destined for email lists to be held by Mailman for
moderation because of implicit destination. Relates to issue #811.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From c500184:

Script to run from cron to send daily messages to IETF Announce showing the email header field change.
This should be run from Jan 6 to Jan 20, after which point we need to deploy analagous changes to the code that constructs last call announcements.

This is related to bug #811

Commit ready for merge.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

From fa10754:

Merged c500184 from rjsparks@nostrum.com:
Script to run from cron to send daily messages to IETF Announce showing the email header field change.
This should be run from Jan 6 to Jan 20, after which point we need to deploy analagous changes to the code that constructs last call announcements.

This is related to bug #811

Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com changed keywords from sprint to ``

[ietf-svn-bot]

@rjsparks@nostrum.com changed status from new to closed

[ietf-svn-bot]

@rjsparks@nostrum.com changed resolution from `` to fixed

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

I think this was done at the time, but the ticket wasn't appropriately closed.