[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Stephen J. Turnbull]

Franck Martin writes:

 > In the upcoming mailman 2.1.16 there has been the introduction of
 > the optional feature author_is_list
 >
 > "Replace the sender

Before you release, s/sender/author/, please.  When discussing
Internet email, sender != author.  The name of the feature, "author is
list", is an obvious falsehood: lists don't write posts, they relay
them.  These policies do not conform to the email RFCs.  (Given the
semantics of "From" set out in RFC 5322, they may even constitute
copyright infringement in the absence of a license from posters
permitting From-munging.  But that's not the topic here.)

AFAICS there's an easy way for Mailman to adapt to DKIM without
violating RFC 5322: wrap every message in a MIME message/rfc822 part
(ie, every message is a one-post "digest").  The wrapper message
obviously can conform to DMARC ("From: LIST at DOMAIN" with appropriate
DKIM signature), and Mailman can DTRT with the wrapped message.

 > with the list address to conform with policies like ADSP and DMARC.
 > It replaces the poster's address in the From: header with the list
 > address and adds the poster to the Reply-To: header,

Another RFC violation. :-(  What if the poster already set Reply-To
because she *doesn't* want mail at the From address?  What if the
list's address *isn't* in Reply-to, but the author expects wide
replies to go to the list?

 > but the anonymous_list

This is probably OK.

 > and Reply-To: header munging settings below take priority.

Does this make sense?  See above.

 > If setting this to Yes, it is advised to set the MTA to DKIM sign
 > all emails. "

Please change this to "This setting is useful when your host signs
outgoing mail according using DKIM."  As written, the advice is
inaccurate anyway.  DKIM requires more than just MTA settings.  There
must be cooperation from the nameserver.

 > Usage of this feature on lists have indicated no adverse issue for
 > the members,

s/no adverse issue/only minor annoyance/ (I disagree with "minor", but
sure, Outlook users probably won't notice).

You should remember that "Reply-To munging" works as expected for
almost all subscribers almost all the time on most lists, and for that
reason is widely used despite its ex post obvious deficiencies.  When
it fails, though, it's at minimum a minor pain in the ass and at
maximum an inadvertant privacy violation.

Please go slowly on screwing with From, which (unlike Reply-To) is a
required field and so appears in *every* email and has well-defined
semantics *with which this feature is in deliberate non-conformance*.

 > provided proper communication is done when the feature is enabled
 > (as to allow inbox rules to be changed if needed).

Isn't this a lie?  If the From header is corrupt, then there is no
reliable indication of who the author is.  If you're lucky you can
fish it out of the body or .signature.  Reply-To won't do: not only
are its semantics such that there's no guarantee that it's an alias
for author, but it complicates the rules significantly because you
need different rules for From-corrupting lists and other lists and
non-list mail.

 > In the 2.1.16 Release Candidate the feature author_is_list is
 > controlled by the following switches in the mm_cfg.py
 > 
 > ALLOW_AUTHOR_IS_LIST = No
 > DEFAULT_AUTHOR_IS_LIST = No
 > 
 > The first one will enable the GUI to present an option to the list
 > admin to enable the author_is_list feature, the second controls if
 > new lists or upgraded lists should have the author_is_list feature
 > set to yes

"Upgraded" lists?  If upgrading to Mailman 2.1.16 causes all my lists
to be corrupted by this feature, I will not be pleased.  An option
called DEFAULT should only apply to new lists.

If you insist on making this a fallback if the list doesn't have an
explicit setting, call the option AUTHOR_IS_LIST.

 > While it is better for the MTA to DKIM sign emails if
 > author_is_list is enabled, this is not a requirement and the list
 > will work fine without DKIM.

But why would anybody want to do this in the absence of DKIM?  Mailman
already has the RFC 2369 and 2919 fields to tell MUAs that it's a list
post, and a plethora of ways (Subject, header, footer) to tell users
that it's a list post.  Anonymous list is already an option for
obscuring the author if that's desirable, and for an announce list
there's no problem, as the list (or an officer of the host) is already
the author.  I think you should just delete that sentence.

 > While DEFAULT_AUTHOR_IS_LIST is important to avoid new lists and
 > upgraded lists change behavior, setting ALLOW_AUTHOR_IS_LIST to Yes
 > does not change how any list is handled (author_is_list in the GUI
 > is No by default). it only provides an option to the list admin to
 > change the list behavior.
 > 
 > Unfortunately some list admins cannot edit mm_cfg.py (like CPANEL
 > type install), therefore it would be nice to remove
 > ALLOW_AUTHOR_IS_LIST or set it to Yes by default to let the list
 > admin decide how he/she wants the list to behave. Otherwise the
 > list admin needs to contact the mailman admin to enable this
 > config.

I'm reluctantly willing to accept a factory default that allows list
owners to decide to systematically violate RFC 5322 (as well as all
predecessors) only if the factory default of DEFAULT_AUTHOR_IS_LIST=No.

 > Please indicates if you are ok to set ALLOW_AUTHOR_IS_LIST to Yes
 > or remove this option from mm_cfg.py

I don't see any obvious loss from removing it, but in keeping with the
general "go slow" attitude toward implementing RFC-violating features,
I think we should keep it for now, but set it to Yes.

In fact, we SHOULD remove DEFAULT_AUTHOR_IS_LIST.  List owners should
make an informed decision to violate RFC 5322, not be defaulted into
doing so.  If site owners want to enforce it, let them hack code.