[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Franck Martin]

One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly.

In an ideal world, lists should only forward the email, preserving the DKIM signature, but few lists are doing that except the notable exception of apache.org lists.

When spam is received from a list (which is rare), the onus is on the list administrator to maintain his/her list content and membership.

This option is off by default and at no time it is proposed to change the behavior of any list being in place or upgraded or imported without the list admin consent and action.


On Sep 13, 2013, at 12:13 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> 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.
> 
>