On Sun, Sep 22, 2013 at 2:12 PM, Barry Warsaw ba...@list.org wrote:
End users just care about how the email looks in their mail readers. I'm
concerned that this will be a nice, RFC-compliant feature that makes things
easy and workable for all the automated systems involved, but will look
Murray S. Kucherawy writes:
I wonder how long we can hold out before we start trying to drag
[the MUA developers] into our conversations, which might be the
only way to solve these pain points long term. It seems to me that
Gmail, Yahoo Mail, Thunderbird, etc., must have either a team or
On Sep 18, 2013, at 05:04 PM, Stephen J. Turnbull wrote:
I don't read German, but I don't see anything that looks like data,
nor is there room for analysis. Nor does the blog by Patrick
Koettner referenced therein. (The Google translations confirm that.)
Please show us something that looks like
On 09/22/2013 02:12 PM, Barry Warsaw wrote:
OTOH, maybe we won't know for sure until it gets *a lot* more testing. But I
think it's a mistake to say well, we just have to force MUA developers to
catch up. As we've seen with something presumably as simple as
reply-to-list, it (almost) never
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
On Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
Franck Martin writes:
I think, it is risky to code this encapsulation method directly and
now, it requires a branch some testing and then merging back into
the main branch.
First, the risk is zero, except to volunteers, as long as it's not
default.
Second, it's been tested for decades. A
On 09/17/2013 06:21 PM, Mark Sapiro wrote:
I could actually implement this approach for the 2.1.16 release, but
that would negate the i18n work that's already been done as the
descriptive string on General Options would change, so I'm more inclined
to label this feature as experimental and
Mark Sapiro writes:
I have had another thought. I will look at provisionally making
ALLOW_AUTHOR_IS_LIST a 3 way switch for 2.1.16 with 0 or False (No)
meaning current (2.1.15) behavior, 1 or True (Yes) meaning the 2.1.16rc1
behavior and 2 meaning the encapsulated message behavior.
If
On Sep 14, 2013, at 04:49 AM, Stephen J. Turnbull wrote:
I have no idea what MUAs would do with that, though. :-(
Me neither, but experience indicates it wouldn't be pretty. :/
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
On Sep 15, 2013, at 08:24 AM, Mark Sapiro wrote:
Because the issue remains controversial, I will soon release 2.1.16
final with the feature disabled by default, and will consider the
message encapsulation approach or other possibilities based on
experience with 2.1.16 for a 2.1.17 release perhaps
On 09/17/2013 05:28 PM, Barry Warsaw wrote:
On Sep 15, 2013, at 08:24 AM, Mark Sapiro wrote:
Because the issue remains controversial, I will soon release 2.1.16
final with the feature disabled by default, and will consider the
message encapsulation approach or other possibilities based on
On Sep 17, 2013, at 6:21 PM, Mark Sapiro m...@msapiro.net wrote:
On 09/17/2013 05:28 PM, Barry Warsaw wrote:
On Sep 15, 2013, at 08:24 AM, Mark Sapiro wrote:
Because the issue remains controversial, I will soon release 2.1.16
final with the feature disabled by default, and will consider
On 09/17/2013 10:04 PM, Franck Martin wrote:
1) If you keep the From: header as it is then, we will still have the same
problems
Perhaps I wasn't clear. The From: of the outer message would contain the
list address. The From: of its message/rfc822 payload would be unchanged
from that of the
On Sep 17, 2013, at 10:36 PM, Mark Sapiro m...@msapiro.net wrote:
On 09/17/2013 10:04 PM, Franck Martin wrote:
1) If you keep the From: header as it is then, we will still have the same
problems
Perhaps I wasn't clear. The From: of the outer message would contain the
list address.
On Sep 14, 2013, at 5:16 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Franck Martin writes:
Unfortunately z= and especially l= are not used practically by
senders because they create a risk. One could add an attachment
containing malware to the message for instance.
Indeed, we have
When a list goes bad, usually the members are not blamed but the list admin,
therefore making the list the system responsible of the writing of the message.
Anyhow, it does not matter, this is a religious discussion. Please feel free to
code and test your solution of encapsulating the message
Franck Martin writes:
When a list goes bad, usually the members are not blamed but the
list admin, therefore making the list the system responsible of the
writing of the message.
Please stop being evasive. The RFC's use of responsible is intended
to point to the person who wanted the
Franck Martin writes:
I'm not sure if DKIM was ever meant to be exposed to the end user,
but the current trend is to try to protect the end user as much as
possible and this is done best by MTAs than MUAs.
I disagree fundamentally. It's best done by *both* MTAs and MUAs.
Not all threats
On 09/14/2013 11:18 PM, Franck Martin wrote:
this is a religious discussion.
Religious or not, it is controversial, and this discussion has raised
valid points.
Because the issue remains controversial, I will soon release 2.1.16
final with the feature disabled by default, and will consider
Franck Martin writes:
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.
Nonsense. Here's what RFC 5322 says:
The From: field specifies the author(s) of the message, that is,
the mailbox(es) of the
On Sep 13, 2013, at 7:48 PM, Mark Sapiro m...@msapiro.net wrote:
On 09/13/2013 12:18 PM, Franck Martin wrote:
Mailman breaks DKIM as soon as you add a footer or tag in the subject line,
which a lot of lists do (including this one).
Not necessarily. It depends on the DKIM signature and
Franck Martin writes:
Unfortunately z= and especially l= are not used practically by
senders because they create a risk. One could add an attachment
containing malware to the message for instance.
Indeed, we have to assume that the MUAs are broken in this respect.
See Daniel Gillmor's
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:
On Sep 12, 2013, at 11:30 PM, SM s...@resistor.net wrote:
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
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
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
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
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.
- Original Message -
From: Mark Sapiro m...@msapiro.net
To: mailman-developers@python.org
Sent: Friday, September 13, 2013 11:31:44 AM
Subject: Re: [Mailman-Developers] Author_is_list option in upcoming mailman
2.1.16
On 09/13/2013 08:06 AM, Barry Warsaw wrote:
I will leave
Franck Martin writes:
we (the people using DMARC) have the opportunity to build
adoption. Just trying to reduce adoption friction ;)
The direction you're heading will *create* adoption friction. The
only way you're going to be able to sell this to admins like me is to
wait until our users
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
On 09/13/2013 12:18 PM, Franck Martin wrote:
Mailman breaks DKIM as soon as you add a footer or tag in the subject line,
which a lot of lists do (including this one).
Not necessarily. It depends on the DKIM signature and how much of the
body is signed. Granted, you are correct in most
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
34 matches
Mail list logo
