Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Fri, 2014-05-02 at 22:25 -0700, Mark Sapiro wrote: > On 05/01/2014 11:29 PM, Lindsay Haisley wrote: > > > > There may be a problem with being _too_ wordy in explaining > > it. > > Yes, and I may have gone there ;) > Well I think you've pretty well covered the bases. It may take a bit of study

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 11:29 PM, Lindsay Haisley wrote: > > There may be a problem with being _too_ wordy in explaining > it. Yes, and I may have gone there ;) Here is the current entire thing. The changes are a few more words in the Munge From and Wrap Message descriptions; adding the "If first_strip_r

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 01 May 2014 at 22:52:27 -0700, Mark Sapiro wrote: > > Do you have a setting to change From: user@domain to From: > > user@domain.INVALID - that is the hack I would like to use. > > No, not currently. It is an interesting idea, but it may cause issues in > delivery of mail From: a non-exi

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

(Despite the subject line, this follows up a digression by correcting some mistaken information about an e-mail attack on AOL.) On 5/2/2014 12:33 AM, Stephen J. Turnbull wrote: BTW, that blog [] also says

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > On 05/01/2014 09:33 PM, Stephen J. Turnbull wrote: > > Mark Sapiro writes: > > > > > The transformations for anonymous_list are applied before any of these > > > actions, so if actions other than No are applied on an anonymous list, > > > they will apply to the anony

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Andrew Partan writes: > Do you have a setting to change From: user@domain to From: > user@domain.INVALID - that is the hack I would like to use. Seems reasonable, but for the reason Mark gave and because it makes personal replies a little bit harder, I *personally* would tend to avoid it, and I

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 2014-05-01 at 22:09 -0700, Mark Sapiro wrote: > So it seems clear to me that we're *adding* the From: address to > Reply-To: and the only question is how does first_strip_reply_to affect > this, and the answer is if it's Yes, the Reply-To: we're adding to was > stripped and is empty, and if

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:57 PM, Andrew Partan wrote: > > Do you have a setting to change From: user@domain to From: user@domain.INVALID > - that is the hack I would like to use. No, not currently. It is an interesting idea, but it may cause issues in delivery of mail From: a non-existent domain. -- Ma

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:33 PM, Stephen J. Turnbull wrote: > Mark Sapiro writes: > > > The transformations for anonymous_list are applied before any of these > > actions, so if actions other than No are applied on an anonymous list, > > they will apply to the anonymized message. > > This may be confus

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:26 PM, Lindsay Haisley wrote: > > If first_strip_reply_to = No there are two possible situations which > aren't covered in your (much improved!) self-doc. Either the original > poster included a Reply-To:, or not. If not, then I assume the original > From: address is put into th

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, May 01, 2014 at 08:29:30PM -0700, Mark Sapiro wrote: > Here's what I've got. I didn't change the name of the setting, but I > changed its description and all the detail. I now have Do you have a setting to change From: user@domain to From: user@domain.INVALID - that is the hack I would lik

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > dmarc_moderation_action is unreliable. If the DNS lookup times out, the > message is assumed unaffected by DMARC. Ouch. I suppose you could hard-code a list of miscreants, er, domains that have used p=reject and fall back on that (including a check for a change in policy

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > from_is_list (general): Replace the From: header address with the list's > posting address to mitigate issues stemming from the original From: > domain's DMARC or similar policies. That's good! [snip my suggestion :] > The following actions are applied to all list mess

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 2014-05-01 at 20:29 -0700, Mark Sapiro wrote: > first_strip_reply_to = Yes will remove all the incoming Reply-To: > addresses but will still add the poster's address to Reply-To: for all > three settings of reply_goes_to_list which respectively will result in > just the poster's address, th

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 11:58 PM, Stephen J. Turnbull wrote: > Why not just deprecate > list_is_from in favor of dmarc_moderation_action? > I don't think I can for two reasons. One is technical. dmarc_moderation_action is unreliable. If the DNS lookup times out, the message is assumed unaffected by DMARC

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Here's what I've got. I didn't change the name of the setting, but I changed its description and all the detail. I now have from_is_list (general): Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar polici

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > I'm not sure what to change at this point. I really don't want another > change in the attribute name, but maybe. Yeah, I know. On the other hand, now that it really matters, this is probably the last chance to make such a change. > I'm also not sure about alignment as

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Larry Stone writes: > Seems to me saying “Try to ensure that 'From:' is “aligned” with …” > does it. No. The problem is the author's email provider (ie, the mail domain of the person whose address is in the original From). For most lists, Mailman does *not* want "From" to be aligned with any

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 09:06 PM, Lindsay Haisley wrote: > On Wed, 2014-04-30 at 17:42 -0700, Mark Sapiro wrote: >> If this is set to Wrap Message, just wrap the message in an outer >> message From: the list with Content-Type: message/rfc822. >> > Since this is the _outer_ wrapper, shouldn't this be multipar

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 2014-05-01 at 11:57 +0900, Stephen J. Turnbull wrote: > from_alignment: Try to ensure that From is not "misaligned" with > the author's domain, to conform with protocols like DMARC. > [FIXME: I don't see how to avoid the double negative. Help?!] from_alignment: Try to en

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 07:57 PM, Stephen J. Turnbull wrote: > > May as well rewrite the doc ... here goes: > > from_alignment: Try to ensure that From is not "misaligned" with > the author's domain, to conform with protocols like DMARC. > [FIXME: I don't see how to avoid the double negative.

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Wed, 2014-04-30 at 17:42 -0700, Mark Sapiro wrote: > Note I also removed the bit about SPF and DKIM signing. They actually > may help with acceptance of your list mail by some ESPs, but not because > of DMARC, and the note could discourage people from using this when it > shouldn't. DKIM signin

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Wed, 2014-04-30 at 17:42 -0700, Mark Sapiro wrote: > If this is set to Wrap Message, just wrap the message in an outer > message From: the list with Content-Type: message/rfc822. > Since this is the _outer_ wrapper, shouldn't this be multipart/mixed? The inner _real_ list post is Content-Type:

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Apr 30, 2014, at 9:57 PM, Stephen J. Turnbull wrote: > May as well rewrite the doc ... here goes: > >from_alignment: Try to ensure that From is not "misaligned" with >the author's domain, to conform with protocols like DMARC. >[FIXME: I don't see how to avoid the double negative.

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > I changed it. In the 2.1.18 final it will say: > > - > from_is_list (general): Replace the sender with the list address to > conform with policies like DMARC. > > Replace the sender with the list address to

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Wed, 2014-04-30 at 15:18 -0700, Mark Sapiro wrote: > I hear you. It is badly explained and I need to fix it. Thanks for > raising this. > Mailman is open source software and I use it. It's my job :) -- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 03:18 PM, Mark Sapiro wrote: > On 04/30/2014 12:56 PM, Lindsay Haisley wrote: > >> I can probably figure this out, but it might be good to explain this a >> bit more completely in the Mailman internal docs. It's not really clear >> exactly how these options relate, and how the prece

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 12:56 PM, Lindsay Haisley wrote: > The internal documentation in the admin screens for 2.1.18 is a bit > confusing with regard to Reply-To munging. > > In the doc for the from_is_list option we have "It replaces the poster's > address in the From: header with the list address and add

[Mailman-Users] 2.1.18 internal documentation suggestions

The internal documentation in the admin screens for 2.1.18 is a bit confusing with regard to Reply-To munging. In the doc for the from_is_list option we have "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_l