Author_is_list option in upcoming mailman 2.1.16
In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list
"Replace the sender 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, but the anonymous_list and Reply-To: header munging settings below take priority. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. "
Usage of this feature on lists have indicated no adverse issue for the members, provided proper communication is done when the feature is enabled (as to allow inbox rules to be changed if needed).
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
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.
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.
Please indicates if you are ok to set ALLOW_AUTHOR_IS_LIST to Yes or remove this option from mm_cfg.py
Note: a few organizations have indicated they will provide the necessary translation of this feature in the GUI for the most common languages.
Hi Franck, At 22:44 12-09-2013, Franck Martin wrote:
In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list
"Replace the sender 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, but the anonymous_list and Reply-To: header munging settings below take priority. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. "
There is an effort (not mailman-related) to mark ADSP as not recommended.
Regards, -sm
On Sep 12, 2013, at 10:44 PM, Franck Martin wrote:
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.
Please indicates if you are ok to set ALLOW_AUTHOR_IS_LIST to Yes or remove this option from mm_cfg.py
I will leave it to Mark for final decision on this, but my own opinion is that the mm_cfg.py option should stay. cPanel already customizes their Mailman installation, so I think they should set it to Yes when they upgrade their systems to 2.1.16.
-Barry
On 09/13/2013 08:06 AM, Barry Warsaw wrote:
I will leave it to Mark for final decision on this, but my own opinion is that the mm_cfg.py option should stay. cPanel already customizes their Mailman installation, so I think they should set it to Yes when they upgrade their systems to 2.1.16.
I don't feel strongly about this either way except for the general principle of least surprise. Enabling this by default has three downsides that I see. It can render a fully i18n translated General Options page a bit ugly with one relatively large English paragraph; it gives list owners yet another bullet with which to shoot themselves in the foot, and it complicates list configuration by adding yet another decision.
None of these is a deal breaker. I researched the i18n issue, and it turns out only 4 languages currently have a fully translated General Options page. One of these has already been updated and the other 3 are being addressed. Most languages already have between 1 and 3 untranslated strings on this page from prior changes so it could be argued that one more is not important.
The other two considerations are relatively minor, but I still lean towards requiring overt action by the site admin to enable the feature.
I wanted this brought to mailman-developers in the hope that whatever discussion ensued would lead to some consensus.
I confess, I'm not at all up to speed on DMARC. Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, but it seems to me that enabling author_is_list will almost guarantee that any incoming DKIM signatures will be broken (the From: is almost certainly included in the signed headers) which will cause problems if the outgoing mail is not signed with a valid DKIM signature.
Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it.
All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default.
Please help me understand if I'm wrong.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail,
That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by "useful".
The whole point of this option is to allow lists to do what we've come to expect them to do (discard or quarantine attachments, add header and footer text, munge Subject) while still presenting a valid DKIM signature to the receiver.
Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it.
Too late. The reason we should consider adding this feature at all is that the big email providers are heading in the direction of imposing that responsibility whether list owners want it or not.
The only real alternative to DKIM signingby Mailman or its MTA is to pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted.
There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like
multipart/mixed
text/plain ; Mailman list header
message/rfc822
text/plain ; Mailman list footerI have no idea what MUAs would do with that, though. :-(
All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default.
If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code.
See my reply to Franck for more detailed comments on the actual proposed changes.
Steve
On Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by "useful".
I'm familiar with RFC 822 and up, but can you specify what exactly is being violated? I'm not saying I disagree, I just want to go to the reference/rule you have in mind.
If the concern is with replacing the From: field on a relayed message, then one could argue Mailman is issuing a new message anyway, so it's free to replace or rewrite anything it chooses. Again referring to RFC 5598, it's a Mediator, not a Relay, though it could also be configured to act as a Relay. But if it were doing that, DKIM signatures would almost always survive.
If it's something else, I'd like to understand.
The only real alternative to DKIM signingby Mailman or its MTA is to
pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted.
Relay vs. Mediator mode, basically.
There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like
multipart/mixed text/plain ; Mailman list header message/rfc822 text/plain ; Mailman list footer
Right, that's an option.
I have no idea what MUAs would do with that, though. :-(
Me either.
All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default.
If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code.
I definitely agree that it should be off by default as it violates the Principle of Least Astonishment.
-MSK
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@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.
I really wish I could keep up with all the lists where interesting stuff is going on.
We produced an RFC a few years ago that tries to tackle the names and definitions of all the various roles (RFC 5598). That document deliberately avoided defining what a Sender is because that word has become so overloaded as to be hyper-ambiguous. Thus:
On Fri, Sep 13, 2013 at 12:13 PM, Stephen J. Turnbull <stephen@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.)
I disagree. Formally, Mailman is creating a new message using (likely) a large portion of the original message. Unless the output is completely identical, Mailman is an Author. So I think the name is right, unless you want to tie the name of the feature to the list's configuration, and I'm sure you don't want to do that.
This isn't absolute of course. There are mushy topics like "Did the Message-Id change?" (One could argue that if the Author changes, a new Message-Id should be generated.) "Should a new Message-Id have been generated?" (Yes, if there was any meaningful content change whatsoever.)
Either way, I think the name is right as-is.
-MSK
participants (6)
-
Barry Warsaw -
Franck Martin -
Mark Sapiro -
Murray S. Kucherawy -
SM -
Stephen J. Turnbull