Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 08:47 PM, Grant Taylor via Mailman-Users wrote:
> I am talking about modifying the From: header such that the message no
> longer had any conflict with the original published DMARC records.


Consider this:

If I create a novel called _The Hexadecimal Kid and His Faithful Dog
ASCII_ [1] and submit the manuscript to a publisher and the publisher
type sets it, prints thousands of bound copies with a title page with
added information about the publisher and maybe adds a subtitle and some
info on a dust jacket, and delivers those printed books to book sellers,
has the publisher now become the author of the book or am I still the
author?

RFC 5322 is clear

   The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.

I.e. the mailbox(es) in the From: header are those of the author. It
doesn't matter if the author is in a comment or display name, if the
mailbox is that of the list, you are claiming the list is the author of
the post.

I'm not saying it is not expedient or even possibly necessary to Munge
the From: in this way. I'm only saying it is a violation of RFC 5322
unless you believe the publisher is author of my book.

[1] Bonus points for anyone who gets the reference.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:41 PM, John Levine wrote:
Quite right.  Beyond the standards theology, there is the practical 
problem that where the message list in your inbox used to tell you who 
wrote the list messages, now it all seems to come from the list alias.


That's where the human friendly portion of the From: header comes into play.

I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

This can show up in the index of a mailbox.

Or the two lines that I'm suggesting prefixing the body with.

 Grant Taylor  wrote the following:

Granted, that doesn't show up in the index of a mailbox.

Both methods tell you who wrote the message content.

Do you have any doubt about who wrote the first four lines of this 
message?  Does the fact that the From: header has my name (via 
Mailman-Users) cause you to believe that I wrote "Quite right.  … list 
alias."?


Or does the fact that there is quoting "> " change that?

In my world, some people's contributions are a lot more interesting 
than others,


Agreed.


and losing the info about who wrote what makes all lists less useful.


I'm not suggesting losing information about who wrote what.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:11 PM, Richard Damon wrote:

Do you understand how DMARC works?


Yes, I do believe that I do understand how DMARC works.

I have yet to have someone show me something (else) about DMARC that I'm 
not aware of.


Yahoo.com has an entry in their DNS that says they want DMARC protection, 
and if you can’t verify that the message came from them unmodified to 
reject it.


Yep.

I'm doing exactly that.

Unless the mailing list claims authorship of the message by changing the 
From: of the message (and thus making it hard to tell who really said the 
words), the list relaying the message with the slightest modification 
of the Subject or Body will cause it to fail DMARC, as DMARC says that 
the From: header is the king for verification.


I am talking about modifying the From: header such that the message no 
longer had any conflict with the original published DMARC records.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

Thus removing any conflict with any DMARC records published by 
tnetconsulting.net


Since the message is now from the Mailman-Users mailing list, it's 
perfectly possible to insert a line at the start of the message like the 
following:


 Grant Taylor  wrote the following:

Only if you think that mailman-users is the author of your message here, 
and that your mailing list is the proper author of every message that 
goes through your mailing list.


I believe that the Mailman-Users mailing list is the entity responsible 
for sending the message to each and every subscriber.  I believe the 
content that the Mailman-Users mailing list is sending is strongly based 
on content provided by someone that sent a message to said mailing list.


I know that the mailing list did not generate the content.  I also know 
that it is sending content heavily based on content from someone else.


Base SPF isn’t an issue. All messages leaving my mailing list pass 
SPF because I publish a SPF record, and the message have an envelope 
From of my mailing list.


What is (was) your (original) motivation for munging the envelope to be 
from the mailing list?  Are (were) you (originally) doing it because you 
want to take advantage of V.E.R.P.?  Or are (were) you (originally) 
doing it to avoid SPF issues?


I know a number of people that only started munging the envelope from 
address because of SPF issues.


You may also run into issues with SPF alignment with DMARC if you don't 
also modify the From: header.


(I can't tell what domain you are referring to.  I don't see SPF / TXT 
records for damon-family.org and I don't know if you are referring to 
some other domain.)


Again, I can verify the DMARC of the incoming message, but unless I want 
to claim authorship by changing the From, I can not send it and have it 
pass DMARC.


Which, IMHO, is what DMARC is supposed to be able to enforce.

Only if you consider the mailing list the Author of every message relayed 
by it.


I do consider the MLM as being the author / creator / submitter of the 
SMTP message.


I view the person that sent the message as being the author / creator / 
submitter of the body content in said SMTP message.


The MLM DOES change the Envelope from, it really wants to so it gets the 
bounces back so it can process it. That means the outgoing message can 
pass SPF as SPF is written. What it doesn’t pass is the modification 
to SPF that DMARC specifies that says that the only domain to validate 
in the inside From: Header, the Envelope doesn’t count.


Yep, VERP.

So you REALY want to see your view of the mailing list as EVERY message 
is ‘From’ Mailman-users, with no indication of who wrote really 
wrote the message? Thus you lose the ability to easily block


Not quite.

I would much rather have the human friendly portion of the address 
remain what was originally sent.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

I would also be interested in something like the following.

 From: Grant Taylor gtaylor at tnetconsulting dot net via 
Mailman-Users 


I believe that retains the attribution that I believe you (and many 
others) want to retain.


Seeing as how the new outgoing message is completely new, it's perfectly 
possible to add something like the following as the first two lines of 
the message:


 Grant Taylor  wrote the following:

So you don’t think mailing list should do any modifications to the 
message, or they need to claim authorship.


"DMARC says that if you get a message from me, it MUST have come 
straight from me"


The key being "it MUST have come straight from me".

Thus messages that pass through a mailing list (or forwarded in any way) 
fail the "come straight from me" portion.



So you see this thread as the mailing list arguing with itself?


I see this thread as a friendly / academic discussion from many 
different mailing list subscribers who send messages to and receive 
messages from said mailing list.

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <88902b3b-7cb3-7991-15c4-4dbc10762...@msapiro.net> you write:
>In that sense, many of us think that the person who wrote the post is
>still the author even if the list made a few simple changes that didn't
>alter the basic text of the original message while the list is a Sender:
>
>That's why we believe that Munge From is non-compliant. ...

Quite right.  Beyond the standards theology, there is the practical
problem that where the message list in your inbox used to tell you who
wrote the list messages, now it all seems to come from the list alias.
In my world, some people's contributions are a lot more interesting
than others, and losing the info about who wrote what makes all lists
less useful.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 07:11 PM, Richard Damon wrote:
> 
> 
>> On Jul 24, 2018, at 9:43 PM, Grant Taylor via Mailman-Users 
>>  wrote:
>>
>> If you view the message to am MLM as as separate end-to-end delivery process 
>> from the message from an MLM to the subscriber, DMARC can and does work with 
>> MLMs.
> 
> Only if you consider the mailing list the Author of every message relayed by 
> it.


To elaborate a bit. RFC 5322 says

   The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.

In that sense, many of us think that the person who wrote the post is
still the author even if the list made a few simple changes that didn't
alter the basic text of the original message while the list is a Sender:

That's why we believe that Munge From is non-compliant. You may think
that the list is in fact "the person(s) or system(s) responsible for the
writing of the message", but many people don't agree.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

> On Jul 24, 2018, at 9:43 PM, Grant Taylor via Mailman-Users 
>  wrote:
> 
>> On 07/24/2018 06:59 PM, Richard Damon wrote:
>> You CAN’T strip DMARC.
> 
> I can most certainly strip any DKIM related headers from messages that are 
> coming into my server on their way to my mailing list.
> 
> I'm not talking about altering other people's view of DNS.  (That's a 
> completely different topic.)

Do you understand how DMARC works? Yahoo.com has an entry in their DNS that 
says they want DMARC protection, and if you can’t verify that the message came 
from them unmodified to reject it. 
> 
>> If a domain has activated DMARC for itself (via its DNS record) then it is 
>> telling all other domains in the world that any mail that says it is from 
>> this domain MUST pass the DMARC test.  This means that either it must be 
>> validly signed BY THEM or come from a server THEY have indicated is them. A 
>> setting of reject (which is what AOL and YAHOO use) indicates that other 
>> people are not to accept messages that appear to be from them that fail 
>> these tests.
> 
> Agreed.
> 
> I'm saying that the email server hosting the mailing list should strip DKIM 
> (related) headers from messages before they go into the mailing list software.

Which doesn’t help with DMARC.

> 
> I'm also saying that said email server should apply all the enforcement 
> checks that you aptly described.
> 
> 
>> See above, a re-mailer that changes a message fails DMARC.
> 
> I believe the SMTP path between the originating sender and the mailing list 
> is distinct and completely different from the separate SMTP path between the 
> mailing list and subscribers servers.
> 
> I'm free to make any and all changes to the message as it passes through the 
> mailing list as long as I do the following:
> 
> 1)  Remove any and all security headers from messages going into the mailing 
> list.
> 2)  I (re)add appropriate security headers to messages exiting from the 
> mailing list.  Note:  These headers should reflect the mailing list and NOT 
> the original sender.

Unless the mailing list claims authorship of the message by changing the From: 
of the message (and thus making it hard to tell who really said the words), the 
list relaying the message with the slightest modification of the Subject or 
Body will cause it to fail DMARC, as DMARC says that the From: header is the 
king for verification.

> 
>> See above
> 
> Hypothetical scenario:
> 
> Message from subscri...@aol.com comes into my email server hosting a Mailman 
> mailing list.
> 
> 1)  Apply all applicable filters (reverse DNS, SPF, DKIM, DMARC, Spam, Virus, 
> etc) as early in the SMTP process as possible.  Reject (as appropriate) 
> anything that fails respective tests.
> 2)  Strip all applicable security headers between the MTA and the MLM.
> 3)  Mailing list manager does it's thing, including munging the From: as it 
> generates new messages that go out through the local MTA.
> 4)  Local MTA adds appropriate new security headers to the messages.
> 
> Note:  #4 absolutely MUST use data that reflects the local domain / sending 
> server.
> 
> I still see nothing that prevents the MLM of doing anything and everything 
> that it wants to do to the messages that pass through it.
> 
> Note:  There is ZERO association between the inbound message and the many 
> outbound messages, save for body content being based on the original incoming 
> message.

Only if you think that mailman-users is the author of your message here, and 
that your mailing list is the proper author of every message that goes through 
your mailing list.
> 
>> So you don’t see the problem with AOL and YAHOO changing there settings so 
>> that 99% of the discussion mailing list (guesings at percentage) are unable 
>> to deliver mail from subscribers who are AOL or YAHOO users, and if they 
>> try, they get back delivery errors that make the list software think that 
>> those users have bad email addresses and get unsubscribed for delivery 
>> errors.
> 
> I think your percentage is high.  I just don't know how high.  But that 
> nuance doesn't really matter.
> 
> I see what was being done before (and some still do now) as a problem. A 
> problem that pre-existed AOL and Yahoo or their use of DMARC.  They just 
> happened to be early adopters that did a cannon ball into the otherwise 
> relatively calm pool.
> 
> I believe that similar problems happened when people started using -all in 
> their SPF records too.  Granted, VERP, which had been adopted by many mailing 
> lists, altered that somewhat.
> 
> I view the equations as being the same, just with significantly different 
> values in the variables.

Base SPF isn’t an issue. All messages leaving my mailing list pass SPF because 
I publish a SPF record, and the message have an envelope From of my mailing 
list.
> 
>> Those other systems now have a very tough choice, don’t honor the DMARC 
>> setting, and thus allow forgeries from banks and such to go through, o

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:59 PM, Richard Damon wrote:

You CAN’T strip DMARC.


I can most certainly strip any DKIM related headers from messages that 
are coming into my server on their way to my mailing list.


I'm not talking about altering other people's view of DNS.  (That's a 
completely different topic.)


If a domain has activated DMARC for itself (via its DNS record) then it 
is telling all other domains in the world that any mail that says it is 
from this domain MUST pass the DMARC test.  This means that either it 
must be validly signed BY THEM or come from a server THEY have indicated 
is them. A setting of reject (which is what AOL and YAHOO use) indicates 
that other people are not to accept messages that appear to be from them 
that fail these tests.


Agreed.

I'm saying that the email server hosting the mailing list should strip 
DKIM (related) headers from messages before they go into the mailing 
list software.


I'm also saying that said email server should apply all the enforcement 
checks that you aptly described.




See above, a re-mailer that changes a message fails DMARC.


I believe the SMTP path between the originating sender and the mailing 
list is distinct and completely different from the separate SMTP path 
between the mailing list and subscribers servers.


I'm free to make any and all changes to the message as it passes through 
the mailing list as long as I do the following:


1)  Remove any and all security headers from messages going into the 
mailing list.
2)  I (re)add appropriate security headers to messages exiting from the 
mailing list.  Note:  These headers should reflect the mailing list and 
NOT the original sender.



See above


Hypothetical scenario:

Message from subscri...@aol.com comes into my email server hosting a 
Mailman mailing list.


1)  Apply all applicable filters (reverse DNS, SPF, DKIM, DMARC, Spam, 
Virus, etc) as early in the SMTP process as possible.  Reject (as 
appropriate) anything that fails respective tests.

2)  Strip all applicable security headers between the MTA and the MLM.
3)  Mailing list manager does it's thing, including munging the From: as 
it generates new messages that go out through the local MTA.

4)  Local MTA adds appropriate new security headers to the messages.

Note:  #4 absolutely MUST use data that reflects the local domain / 
sending server.


I still see nothing that prevents the MLM of doing anything and 
everything that it wants to do to the messages that pass through it.


Note:  There is ZERO association between the inbound message and the 
many outbound messages, save for body content being based on the 
original incoming message.


So you don’t see the problem with AOL and YAHOO changing there settings 
so that 99% of the discussion mailing list (guesings at percentage) are 
unable to deliver mail from subscribers who are AOL or YAHOO users, and 
if they try, they get back delivery errors that make the list software 
think that those users have bad email addresses and get unsubscribed 
for delivery errors.


I think your percentage is high.  I just don't know how high.  But that 
nuance doesn't really matter.


I see what was being done before (and some still do now) as a problem. 
A problem that pre-existed AOL and Yahoo or their use of DMARC.  They 
just happened to be early adopters that did a cannon ball into the 
otherwise relatively calm pool.


I believe that similar problems happened when people started using -all 
in their SPF records too.  Granted, VERP, which had been adopted by many 
mailing lists, altered that somewhat.


I view the equations as being the same, just with significantly 
different values in the variables.


Those other systems now have a very tough choice, don’t honor the DMARC 
setting, and thus allow forgeries from banks and such to go through, 
or honor it to the detriment of their customers trying to use mailing 
lists.


I believe that mailing lists (or their hosting MTAs) SHOULD do DMARC 
(and DKIM and SPF) filtering in as strict a manner as the purported 
sending domain desires.


Thus blocking the undesirable messages that you refer to.

When they first did this and the problems started, one solution that 
was being proposed was to just kick all AOL and YAHOO users off all 
mailing lists.


I do not believe that the problem started then.  It may very well be 
that it became well enough known as enough people were effected that 
people that didn't know about it before suddenly learned about it.


I believe the problem was known about before AOL and Yahoo implemented 
DMARC.


I feel like kicking AOL and Yahoo users off of mailing lists is an 
unnecessary Draconian knee jerk reaction.  Something that should be 
avoided at all costs.



The problem with DMARC is that it DOES attempt to protect end-to-end.


I obviously disagree.  Particularly on what the receiving "end" is.

If you view the message to am MLM as as separate end-to-end delivery 
process from the message from an MLM 

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:51 PM, Mark Sapiro wrote:
The stolen address books were used to send phishing emails purportedly 
from the owner of the address book the the addresses in the book.


I.e., a message From: a_known_fri...@yahoo.com saying things look at 
this great thing I found and a URL to evilsite.com.


Trivial to harvest addresses, but not trivial to know a known associate 
to send the mail From:.


I hadn't thought about the association of the metadata.  Thank you for 
clarifying.


I do question how much more spam was sent by stealing address books from 
large providers compared to viruses / malware doing the same with 
address books on infected machines.


In this context, the innocents are subscribers to mailing lists who 
find themselves unsubscribed by bounce processing because their ISPs 
reject list posts From: other_us...@yahoo.com and the operators of those 
mailing lists.


Indeed, unfortunately "friendly fire".  :-/

Of course, you seem to feel that these lists were wrong from the beginning 
for not claiming authorship of the posts by replacing the From: header,


Yes, that's in line with my current view.


but at the time, this wasn't even an option for most lists.


Lack of an option does not preclude the need for it.

Similarly, ignorance of an option does not preclude the need for it.

Admittedly, I've long struggled with how I thought discussion mailing 
lists should behave.  Originally I hadn't given any thought to munging 
the From: like is suggested for DMARC.  That being said, I did want to 
direct replies back to the discussion list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

>> On Jul 24, 2018, at 3:20 PM, Grant Taylor via Mailman-Users 
>>  wrote:
>> 
>> On 07/22/2018 04:25 PM, Richard Damon wrote:
>> What actions do you think mailing lists are doing improperly?
> 
> I personally believe that mailing lists are their own end entity, just like 
> our individual mailboxes.  (Particularly discussion mailing lists.)  I also 
> believe that SPF, DKIM, and DMARC are meant to protect between said 
> endpoints; message submitter and terminal mailbox.
> 
> Thus I think that DKIM and DMARC should be stripped from messages prior to 
> entering the mailing list.  The mailing list does it's thing.  Then DKIM and 
> DMARC are applied anew to the messages as they leave the server hosting the 
> mailing list.

You CAN’T strip DMARC. If a domain has activated DMARC for itself (via its DNS 
record) then it is telling all other domains in the world that any mail that 
says it is from this domain MUST pass the DMARC test. This means that either it 
must be validly signed BY THEM or come from a server THEY have indicated is 
them. A setting of reject (which is what AOL and YAHOO use) indicates that 
other people are not to accept messages that appear to be from them that fail 
these tests.
> 
>> Note, the subject modification is a long standing feature of mailing list, 
>> which is one thing that breaks DMARC, though I might be willing to give that 
>> up.
> 
> Mailing lists, as I view them, are free to mung messages to their hearts 
> content in the paradigm that I use.

See above, a re-mailer that changes a message fails DMARC.
> 
>> The modification of the message body to add a header or footer is also 
>> common, and in some places effectively required by law.
> 
> Agreed.
> 
> Such is perfectly compatible with my paradigm.

See above
> 
>> If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t have 
>> been quite as bad. But they ABUSED DMARC by their settings.
> 
> I still don't grok what you are considering "abuse" in this context?
> 
> Rather than speculating, please clarify what the abusive activity was.
> 
>> By the design of DMARC, AOL and Yahoo should have informed their users that 
>> they were changing the Terms of Service of their email systems, and now all 
>> their users are effectively prohibited to use any form of re-mailing 
>> systems, including most forms of (external) mailing lists. Instead they just 
>> told the world, we aren’t going to follow the normal rules, you deal with it.
> 
> I have a different interpretation.
> 
> My understanding is that AOL and Yahoo leveraged DMARC to expressly identify 
> messages that originated from AOL and Yahoo.  Or said another way, they 
> leveraged DMARC to make it easy for receiving servers to identify messages 
> that are not being sent from AOL or Yahoo servers /during/ that current SMTP 
> transaction.
> 
> I feel the need to insert a nod towards the fact that postmasters are free to 
> run their infrastructure the way that they see fit.
> 
> I also do not feel like the terms of service between AOL or Yahoo and their 
> end users changed.
> 
> AOL and Yahoo simply published information to make it easier for the world to 
> identify if messages in the scope of an SMTP session are coming from AOL or 
> Yahoo servers.  They also published their desire for receiving servers to 
> reject messages that don't pass said published information.
> 
> Did they do so knowing that there would likely be a problem with traditional 
> .forward(ing) and mailing lists?  Quite likely.  Was an internal business 
> decision made that publishing such information and dealing with the 
> ramifications of .forward(ing) and mailing lists more important than allowing 
> bad actors to continue pretending to be AOL or Yahoo?  Extremely likely.
> 
> IMHO AOL and Yahoo made a business decision.  Would you make the same 
> business decision?  Maybe, maybe not.
> 
> Note:  Both AOL's and Yahoo's business decision works perfectly fine in my 
> paradigm.
> 

So you don’t see the problem with AOL and YAHOO changing there settings so that 
99% of the discussion mailing list (guesings at percentage) are unable to 
deliver mail from subscribers who are AOL or YAHOO users, and if they try, they 
get back delivery errors that make the list software think that those users 
have bad email addresses and get unsubscribed for delivery errors. Those other 
systems now have a very tough choice, don’t honor the DMARC setting, and thus 
allow forgeries from banks and such to go through, or honor it to the detriment 
of their customers trying to use mailing lists. When they first did this and 
the problems started, one solution that was being proposed was to just kick all 
AOL and YAHOO users off all mailing lists. 

>> Yes, there is a fundamental issue with email that it is easy to spoof. 
>> Fixing it is going to be a significant issue, and possible a complete 
>> recreation of the system.
> 
> I don't see a specific need to recreate the system.
> 
>> The issue i

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 05:20 PM, Grant Taylor via Mailman-Users wrote:
> On 07/24/2018 03:16 PM, John Levine wrote:
>> Turning it on for aol.com, yahoo.com, and other domains with user
>> mailboxes,
> 
> So, are you stating that DMARC should NOT be used on domains that
> (predominantly) contain end user mailboxes?


Many of us believe that DMARC was developed for domains such as
financial institutions and others in order to combat phishing attacks.
The developers of the DMARC standard never intended it to be used by
domains that provide email addresses for personal use.


>> to outsource the pain of the spam they were getting
> 
> I'm not completely following you.  Are you referring to filtering of
> inbound email that AOL / Yahoo / etc. were having to do?  If so, I don't
> see how publishing DMARC effects that.  (I assume that they did not need
> to publish records to enhance filtering email from themselves.)  Or are
> you referring to "the pain" as being the push back / flack from the rest
> of the email industry for spoofed messages purporting to be from AOL /
> Yahoo / etc?


The stolen address books were used to send phishing emails purportedly
from the owner of the address book the the addresses in the book.

I.e., a message From: a_known_fri...@yahoo.com saying things look at
this great thing I found and a URL to evilsite.com.


> IMHO it has been trivial to harvest email addresses for a LONG time.  As
> such, I think that address books are simply a convenient list and not
> strictly related.  Please correct me if I'm wrong.


Trivial to harvest addresses, but not trivial to know a known associate
to send the mail From:.


> Please elaborate on what "the cost" is and entails.  Are you referring
> to anything more than the fallout of not being able to (easily) forward
> email in a DMARC compliant manner?
> 
> I suspect "imposed on innocent bystanders" and "not their problem" can
> also be used to describe requiring reverse DNS, SPF, and DKIM.


In this context, the innocents are subscribers to mailing lists who find
themselves unsubscribed by bounce processing because their ISPs reject
list posts From: other_us...@yahoo.com and the operators of those
mailing lists.

Of course, you seem to feel that these lists were wrong from the
beginning for not claiming authorship of the posts by replacing the
From: header, but at the time, this wasn't even an option for most lists.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 03:16 PM, John Levine wrote:
Turning it on for aol.com, yahoo.com, and other domains with user 
mailboxes,


So, are you stating that DMARC should NOT be used on domains that 
(predominantly) contain end user mailboxes?



to outsource the pain of the spam they were getting


I'm not completely following you.  Are you referring to filtering of 
inbound email that AOL / Yahoo / etc. were having to do?  If so, I don't 
see how publishing DMARC effects that.  (I assume that they did not need 
to publish records to enhance filtering email from themselves.)  Or are 
you referring to "the pain" as being the push back / flack from the rest 
of the email industry for spoofed messages purporting to be from AOL / 
Yahoo / etc?



due to letting user address books be stolen.


I don't know about AOL's security posture, but I do have a little idea 
about how bad Yahoo's was.  -  I still don't know that I would say that 
they allowed it, as in welcomed it.


IMHO it has been trivial to harvest email addresses for a LONG time.  As 
such, I think that address books are simply a convenient list and not 
strictly related.  Please correct me if I'm wrong.


Right, thereby causing a great deal of entirely legitimate mail that 
DMARC cannot describe to go missing, along with a certain amount of spam.


"legitimate mail that DMARC cannot describe"  That sounds distinctly 
like a problem with the DMARC specification, /not/ with use there of.


Aside:  The (relatively?) recent conversion from analog TV to digital TV 
broadcasting in the US comes to mind.


I feel like DMARC requires a paradigm shift in how email is forwarded 
and handled by mailing lists.  (I'm sure there are some other uses that 
I'm forgetting.)  Much like the aforementioned conversion from analog TV 
to digital TV.


Or similarly the requirement for reverse DNS for mail servers.  Personal 
opinions aside, it seems as if the email industry has decided that 
requiring reverse DNS is a mostly good thing.  Or that the good 
(slightly) outweighs the bad.



We've been cleaning up their mess ever since.


I question if the mess is /really/ AOL's or Yahoo's doing, or if instead 
the problem was really related to (what I'm going to describe as) a 
questionable way of operating that we now must change to play well with 
DMARC.


Yes, they explicitly decided that the costs they imposed on innocent 
bystanders were Not Their Problem.


Please elaborate on what "the cost" is and entails.  Are you referring 
to anything more than the fallout of not being able to (easily) forward 
email in a DMARC compliant manner?


I suspect "imposed on innocent bystanders" and "not their problem" can 
also be used to describe requiring reverse DNS, SPF, and DKIM.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Mailman 2.1.29 Release

[Mark Sapiro]

I am not so pleased to announce the release of Mailman 2.1.29.

It turned out there was a bug in the security fix in 2.1.28 that broke
the web admin and listinfo overview pages. This is fixed in Mailman
2.1.29. The patch referred to below has been corrected to fix this bug.
There is also a patch attached to
 which applies to
2.1.28 to fix this issue.

Python 2.6 is the minimum supported, but Python 2.7 is strongly recommended.

Mailman 2.1.28 was a minor security fix release. It also has some i18n
updates and a couple of bug fixes and adds the ability to edit list
specific templates through the web admin UI in a supported language
other than the list's default. See the attached README.txt for details.

For details of the security issue, see the report at
 which also includes a
patch for those who want to fix this issue without upgrading.

Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, please see our web site at one of:

http://www.list.org
https://www.gnu.org/software/mailman
http://mailman.sourceforge.net/
https://mirror.list.org/

Mailman 2.1.29 can be downloaded from

https://launchpad.net/mailman/2.1/
https://ftp.gnu.org/gnu/mailman/
https://sourceforge.net/projects/mailman/

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
2.1.29 (24-Jul-2018)

  Bug Fixes

- Fixed the listinfo and admin overview pages that were broken by
  LP: #1780874.  (LP: #1783417)

2.1.28 (23-Jul-2018)

  Security
 
- A content spoofing vulnerability with invalid list name messages in
  the web UI has been fixed.  CVE-2018-13796  (LP: #1780874)

  New Features

- It is now possible to edit HTML and text templates via the web admin
  UI in a supported language other than the list's preferred_language.
  Thanks to Yasuhito FUTATSUKI.

  i18n

- The Japanese translation has been updated by Yasuhito FUTATSUKI.

- The German translation has been updated by Ralf Hildebrandt.

- The Esperanto translation has been updated by Rubén Fernández Asensio.

  Bug fixes and other patches

- The BLOCK_SPAMHAUS_LISTED_DBL_SUBSCRIBE feature added in 2.1.27 was
  not working.  This is fixed.  (LP: #1779774)

- Escaping of HTML entities for the web UI is now done more selectively.
  (LP: #1779445)

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Mailman 2.x to 3.1.x Migration

[Mark Sapiro]

On 07/24/2018 06:32 AM, Andrew Hodgson wrote:
> 
> Once done you can see the results by navigating to your Mailman instance and 
> you can see the data about the list such as the creation date, number of 
> posts and the members.  For some reason on my instance the last post date is 
> still the last post from Mailman2, even though it has been running on 
> Mailman3 for a month or so.


This is , fixed in
Mailman 3.2.


> Import archives:
> Use the command python manage.py hyperkitty_import to get the private mbox 
> into your list.  I ran into 2 issues:
> 
> - If you have posts in the new archive on Mailman3 then you need to specify 
> the earliest date you want to import into the archive as the command won't 
> import anything older than the earliest date in the new archive.  If you run 
> the command with the help option you can see the format required;


Yes. I've thought about adding a --all option to import the entire mbox
regardless of date, but for now I just specify --since='1990-01-01'.


> - There were older messages in the mbox without message-ids in the archive 
> that failed to import.  I took the easy way out on this one and didn't import 
> them.  In an archive with around 120,000 messages it rejected around 30 
> messages in all.


This is , fixed in
HyperKitty 1.2.0.

There are other issues that haven't yet been fixed other than by my own,
unmerged patches. See 
and .

It really helps to have the import mbox as clean as possible before
starting. If it's a MM 2.1 mbox from a list created on MM 2.1.x, it's
probably pretty good, but if it's from a list created in MM 2.0 days, it
probably has issues. In any case, you need to check it for unescaped
'From ' lines with MM 2.1's bin/cleanarch. Even this isn't perfect, but
it helps.

Also, after you import archives, the Haystack search index will not
index those messages because they are not seen as new. Older versions of
hyperkitty_import would say that the Django minutely update_index job
would do it, but it won't. You can run

python manage.py update_index

to index those imported messages, but if you have a large installation
with multiple tens of thousands of archived messages, this can take
several hours. To help with this, there is now

python manage.py update_index_one_list

to do just a specified list. This too can take a long time (run it in
the background) if the imported archive was large, but it's often
preferable to doing the entire installation.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <78baab65-f7d3-ce56-bc36-a16a15118...@spamtrap.tnetconsulting.net> 
you write:
>> If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t 
>> have been quite as bad. But they ABUSED DMARC by their settings.
>
>I still don't grok what you are considering "abuse" in this context?
>
>Rather than speculating, please clarify what the abusive activity was.

Turning it on for aol.com, yahoo.com, and other domains with user
mailboxes, to outsource the pain of the spam they were getting due
to letting user address books be stolen.

>My understanding is that AOL and Yahoo leveraged DMARC to expressly 
>identify messages that originated from AOL and Yahoo.  Or said another 
>way, they leveraged DMARC to make it easy for receiving servers to 
>identify messages that are not being sent from AOL or Yahoo servers 
>/during/ that current SMTP transaction.

Right, thereby causing a great deal of entirely legitimate mail that
DMARC cannot describe to go missing, along with a certain amount of
spam.  We've been cleaning up their mess ever since.

R's,
John

PS:

>Did they do so knowing that there would likely be a problem with 
>traditional .forward(ing) and mailing lists?  Quite likely.  Was an 
>internal business decision made that publishing such information and 
>dealing with the ramifications of .forward(ing) and mailing lists more 
>important than allowing bad actors to continue pretending to be AOL or 
>Yahoo?  Extremely likely.

Yes, they explicitly decided that the costs they imposed on
innocent bystanders were Not Their Problem.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 04:25 PM, Richard Damon wrote:

What actions do you think mailing lists are doing improperly?


I personally believe that mailing lists are their own end entity, just 
like our individual mailboxes.  (Particularly discussion mailing lists.) 
 I also believe that SPF, DKIM, and DMARC are meant to protect between 
said endpoints; message submitter and terminal mailbox.


Thus I think that DKIM and DMARC should be stripped from messages prior 
to entering the mailing list.  The mailing list does it's thing.  Then 
DKIM and DMARC are applied anew to the messages as they leave the server 
hosting the mailing list.


Note, the subject modification is a long standing feature of mailing 
list, which is one thing that breaks DMARC, though I might be willing 
to give that up.


Mailing lists, as I view them, are free to mung messages to their hearts 
content in the paradigm that I use.


The modification of the message body to add a header or footer is also 
common, and in some places effectively required by law.


Agreed.

Such is perfectly compatible with my paradigm.

If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t 
have been quite as bad. But they ABUSED DMARC by their settings.


I still don't grok what you are considering "abuse" in this context?

Rather than speculating, please clarify what the abusive activity was.

By the design of DMARC, AOL and Yahoo should have informed their users 
that they were changing the Terms of Service of their email systems, 
and now all their users are effectively prohibited to use any form 
of re-mailing systems, including most forms of (external) mailing 
lists. Instead they just told the world, we aren’t going to follow 
the normal rules, you deal with it.


I have a different interpretation.

My understanding is that AOL and Yahoo leveraged DMARC to expressly 
identify messages that originated from AOL and Yahoo.  Or said another 
way, they leveraged DMARC to make it easy for receiving servers to 
identify messages that are not being sent from AOL or Yahoo servers 
/during/ that current SMTP transaction.


I feel the need to insert a nod towards the fact that postmasters are 
free to run their infrastructure the way that they see fit.


I also do not feel like the terms of service between AOL or Yahoo and 
their end users changed.


AOL and Yahoo simply published information to make it easier for the 
world to identify if messages in the scope of an SMTP session are coming 
from AOL or Yahoo servers.  They also published their desire for 
receiving servers to reject messages that don't pass said published 
information.


Did they do so knowing that there would likely be a problem with 
traditional .forward(ing) and mailing lists?  Quite likely.  Was an 
internal business decision made that publishing such information and 
dealing with the ramifications of .forward(ing) and mailing lists more 
important than allowing bad actors to continue pretending to be AOL or 
Yahoo?  Extremely likely.


IMHO AOL and Yahoo made a business decision.  Would you make the same 
business decision?  Maybe, maybe not.


Note:  Both AOL's and Yahoo's business decision works perfectly fine in 
my paradigm.


Yes, there is a fundamental issue with email that it is easy to 
spoof. Fixing it is going to be a significant issue, and possible a 
complete recreation of the system.


I don't see a specific need to recreate the system.

The issue is that to create such a new system is a major job. Such a 
redesign would need to look at ALL current uses and either decide that 
such uses were no longer valid or to accommodate them.


I am interested to see what others would propose that offers the same 
good points of our existing system (SMTP) without any (or at least 
fewer) bad points.


DMARC somewhat intentionally did not consider mailing list, because they 
didn’t have a good solution to handle them, and their intended usage, 
the protection of ‘valuable’ mail somewhat excluded the use of such 
services.


I think you and I have a fundamentally different view of what is being 
protected and not.


In my view, SPF, DKIM, and DMARC do a perfectly fine job of protecting 
messages between the sender and the mail recipient that they specify.


In your view (as I understand it), SPF, DKIM, and DMARC do a 
questionable job protecting messages between the sender and the ultimate 
mail recipient through an unknown number of intermediaries that may 
forward and / or expand to one or more other, different, recipients than 
the sender stated.


IMHO, much like STARTTLS protects a segment of the over all 
communications path between the sender and the ultimate recipient(s), 
SPF, DKIM, and DMARC only protect one portion.  And I happen to think 
that they do it well.


It basically required that any service that wanted to use DMARC needed to 
separate valuable protected mail from less valuable mail with different 
domains. AOL and YAHOO just decided to ignore that in their use

[Mailman-Users] Mailman Migration 2.1.X to 3.2

[Ryan McClung]

Hey All,

Looking to migrate 2.1.15 to 3.2. Right now we have a lot of lists and
pretty big archives. Is there a best practices for the migration or can
anyone offer scripts that have worked for them?

Info:

1 -- Mailman 2 server
1 -- Mailman 3 server

Both are on the same network.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] ARC, was non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 11:02 PM, Stephen J. Turnbull wrote:
You're misunderstanding.  The ARC community doesn't discourage 
whitelisting other sites.  The work to do whitelisting does.


Thank you for clarifying Stephen.  I was afraid that you were somehow 
implying that there was some sort of guideline on what sits should and 
should not implement ARC.  I didn't think that was what you were meaning 
to imply, but the doubt was there, hence the questioning.


Mailing lists are *known* to *frequently* (almost always) break DKIM 
signatures in a way amenable to repair by ARC.[1]


ACK

The other main pain points for DMARC are third-party services that 
are authorized by the owner of a mailbox to send mail "on behalf of", 
without participation of the adminstrator of the mailbox's domain. 
An example is invoicing services.  These do not benefit from ARC *at all* 
because they have a valid DKIM signature from the originating domain, 
who can be trusted for that service, but don't get such a signature from 
the mailbox's domain as required for DMARC From validation.


I hear and acknowledge what you're saying.

I would think / hope / expect that such services would be from a 
different (sub)domain of the client that they are sending email on 
behalf of.  I would also expect the from address to reflect the 
sub-contractor's (sub)domain with a Reply-To: directing replies to 
proper main (parent) domain.  (Or some mailbox associated there in.)  I 
would also expect to see some sort of verbiage stating that "This 
message was sent on the behalf of $Parent by $3rdPartyContractor."


I would also hope / expect to see some sort of linking text / 
acknowledgement from the parent that they have (sub)contracted some 
services to a 3rd party.


But, I learn more and more every day that I have different expectations 
than most people.


The other *possible* use case for ARC would be non-mailing list 
forwarding.  But these almost never break the DKIM signature of the 
originator.


They may not break DKIM.  But depending on how they operate, they may 
break SPF directly (re-sending with the original SMTP envelope From: 
thus violating SPF) -or- indirectly (re-sending with something like SRS) 
thus breaking DMARC alignment.


My understanding is that DMARC can be configured to require both SPF and 
DKIM alignment.  Maybe it's only for reporting and not for pass / fail 
tests.  I'd have to go back and re-read the specifics about DMARC again.


The point being that simple .forward(ing) may still break things.

I maintain that detecting such is one of the functional purposes of 
DMARC.  This is independent of is such benign or malicious.


I guess large services like GMail can eventually add a feature where a 
user can configure GMail to recognize and whitelist specific sites where 
they have mailboxes set to forward to GMail.  But I doubt this will 
ever be a standard feature of MDAs.  It will be complex and fragile to 
implement, and almost never used.


Agreed to both aspects.


Footnotes:
[1]  Note that I disagree somewhat with John.  I suspect that humongous 
providers like GMail, Yahoo!, and Microsoft will automatically accept 
ARC in the presence of a RFC 2369 List-* header, and blacklist on bad 
behavior, as they do now.  That's not perfect from a list admin's point 
of view---it requires a lot of resources to do that well, so small sites 
probably won't---but it's not too bad.


I question the wisdom of making processing of ARC conditional on RFC 
2369 List-* headers.  I mainly say this because there is nothing that 
prevents malicious actors from inserting (possibly bogus) List-* 
headers.  (Or lots of tiny lists of single recipients.)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Mailman 2.x to 3.1.x Migration

[Andrew Hodgson]

Hi,

This isn't a step by step guide or anything but just my experiences.

It is a 2 stage process:

- Import the list configuration (subscribers, list options etc);
- Import list archives.

Import list configuration using the command mailman import21.  This expects a 
.pck file to import and the list to which you want to import into.

Once done you can see the results by navigating to your Mailman instance and 
you can see the data about the list such as the creation date, number of posts 
and the members.  For some reason on my instance the last post date is still 
the last post from Mailman2, even though it has been running on Mailman3 for a 
month or so.

Import archives:
Use the command python manage.py hyperkitty_import to get the private mbox into 
your list.  I ran into 2 issues:

- If you have posts in the new archive on Mailman3 then you need to specify the 
earliest date you want to import into the archive as the command won't import 
anything older than the earliest date in the new archive.  If you run the 
command with the help option you can see the format required;
- There were older messages in the mbox without message-ids in the archive that 
failed to import.  I took the easy way out on this one and didn't import them.  
In an archive with around 120,000 messages it rejected around 30 messages in 
all.

Hope this points you in the right direction,
Andrew.


From: Mailman-Users [mailman-users-bounces+andrew=hodgson...@python.org] on 
behalf of Ryan McClung [rmccl...@afilias.info]
Sent: 23 July 2018 15:43
To: Mailman-Users@python.org
Subject: [Mailman-Users] Mailman 2.x to 3.1.x Migration

Hey All,

I haven't read anything on gitlab about whether or not this has been
finalized. Is there a migration process available?

I also read about scripting it but unfortunately I can't find any resources
on a way to do so. Can anyone provide me with a best-practices on how to
migrate?

Ryan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/andrew%40hodgson.io
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Mailman 2.x to 3.1.x Migration

[Sebastian Hagedorn]

--On 23. Juli 2018 um 10:43:52 -0400 Ryan McClung  
wrote:



I haven't read anything on gitlab about whether or not this has been
finalized. Is there a migration process available?

I also read about scripting it but unfortunately I can't find any
resources on a way to do so. Can anyone provide me with a best-practices
on how to migrate?


I have only migrated a few lists for testing purposes, but at least with 
Mailman 3.2 you just copy the .pck file and import it like this:


$ mailman import21 listname@domain /tmp/config.pck

This does not take care of list archives.
--
   .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:.
  .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Mailman 2.x to 3.1.x Migration

[Ryan McClung]

Hey All,

I haven't read anything on gitlab about whether or not this has been
finalized. Is there a migration process available?

I also read about scripting it but unfortunately I can't find any resources
on a way to do so. Can anyone provide me with a best-practices on how to
migrate?

Ryan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org