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

[Mark Sapiro]

On 07/25/2018 05:24 PM, Richard Damon wrote:
>>
>> Perhaps the wrapper message would look like today's munged ML messages -
>> From: Real Person  / Reply-To: Real Person
>>  - but a list-aware MUA would largely hide that.
>>
>> Of course there are a million details and getting adoption would be hard.
> Yes, one set of solutions would involve defining standards of how to
> compose composite messages, with standards on how to display them. A
> major part of the current issue is that for anything more than a single
> part plain text you can't be sure how it will be handled.


First, the MLM side of this proposal is exactly what the Mailman "Wrap
Message" action does. It wraps the original message, unchanged except
for content filtering as a message/rfc822 part in an outer message. List
headers and footers if any are added as separate parts in the outer
message and all subject prefixing, From: header munging addition of
List-* headers etc is done to the outer message.

This action is almost universally ignored in favor of Munge From because
of MUA deficiencies. There are MUAs that will render such a message in a
highly readable manner, but there are others, particularly mobile device
clients, that make it difficult to impossible to view the wrapped message.

If Thunderbird can do a reasonable job of rendering such a message, and
it does, there's little if any excuse for other MUAs to not do so. Even
Yahoo web mail, which I just tried, does OK after I click "Show original
message".

But, when this was initially implemented, I tried using Wrap Message on
my bicycling club's lists, and I received many complaints so I went to
Munge From.

-- 
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 <885f93f0-36ec-d74f-7c5f-52b42f2d6...@jordan.maileater.net> you 
write:
>Hmm.  It would take MUA changes to be fully effective, but a possibility
>that comes to mind is to have mailing lists leave the original message
>absolutely unmodified, but wrap it in a message that comes "from" the
>mailing list.  That way everything about the message is verifiably true.

Yeah, we've tried that.  It would in effect make each message a
one-message digest.  Let me just say that it would take a LOT of
changes to a lot of MUAs to make that work acceptably.

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"

[Richard Damon]

On 7/25/18 1:48 PM, Jordan Brown wrote:
> Hmm.  It would take MUA changes to be fully effective, but a possibility
> that comes to mind is to have mailing lists leave the original message
> absolutely unmodified, but wrap it in a message that comes "from" the
> mailing list.  That way everything about the message is verifiably true.
>
> A list-aware MUA could more or less transparently unwrap such a
> message.  It would probably display some indication that the message
> came through the ML - the name of the list, unsubscribe mechanism,
> archive pointers, ML header or footer text, et cetera, and maybe
> activate alternative "reply" options[*]  - but would largely present the
> message as "from" the original author, *via* the mailing list.
>
> Perhaps the wrapper message would look like today's munged ML messages -
> From: Real Person  / Reply-To: Real Person
>  - but a list-aware MUA would largely hide that.
>
> Of course there are a million details and getting adoption would be hard.
Yes, one set of solutions would involve defining standards of how to
compose composite messages, with standards on how to display them. A
major part of the current issue is that for anything more than a single
part plain text you can't be sure how it will be handled.

Yes, you can't be absolutely positive that every MUA will work right,
you at least have the defense that you did your best to be clear within
the standard, and perhaps the standard could even be worked that
existing non-conforming implementations are so bad that it is clear that
the user needs a new MUA.

-- 
Richard Damon

--
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 Migrate 3.0 (beta) to 3.2

[Mark Sapiro]

On 07/25/2018 06:55 AM, Ryan McClung wrote:
> The mailman 3.0 install is on the same box as 3.2. Is there a quick and
> dirty way to flip over?


Other than updating your MTA and web server to point at the 3.2 install,
you need to ensure that 3.2 accesses the old 3.0 database(s) and after
doing so, run the django management 'migrate' command. The core's
migrations should be done automatically by alembic.

Note questions like this will reach a deeper pool of knowledgeable
people if asked on the mailman-us...@mailman3.org list


-- 
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] ARC, was non-subscribers getting through--email address in "Real Name"

[John R Levine]

> As I said a few messages ago, if lists did more stringent tests on
> incoming mail, a lot of this complexity could be avoided,

I don't understand this.  If lists got a pass, every spam would grow
RFC 2369 header fields.  No?


Large mail systems already know where all the mailing lists are.  It's 
obvious from the tags in the DMARC reports I get from Gmail.  The reason 
we have kludgy ARC rather than just whitelist list servers is that lists 
don't filter inbound spam, so ARC gives the recipient systems clues to do 
filtering retroactively.


If lists filtered better, e.g., by doing DMARC checks on INBOUND mail, 
that's checking INBOUND mail as it ARRIVES at list servers*, there'd be 
much less leakage and no need for retroactive filtering.


Nobody's going to whitelist on List-ID, they'll do it with IP addresses.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

* - PS to Stephen, I know you understand the difference but a lot of other 
people reading this clearly don't.

--
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] Argh. Postfix/Mailman compatibility on Gentoo

[Mark Sapiro]

On 07/25/2018 11:43 AM, Phil Stracchino wrote:
> 
> The easy solution:
> 
> 1.  In /etc/postfix/main.cf:
> mail_owner= postfix
> default_privs = mailman
> 
> 2.  Restart Postfix

Or

sudo chown mailman /path/to/mailman/data/aliases.db

which doesn't even require restart/reload of Postfix. See the "DELIVERY
RIGHTS" section in 'man 8 local'

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

[Mailman-Users] Mailman Migrate 3.0 (beta) to 3.2

[Ryan McClung]

The mailman 3.0 install is on the same box as 3.2. Is there a quick and
dirty way to flip over?

-- 

Ryan McClung
Systems Administrator @ Afilias Canada
A.  204-4141 Yonge Street, Toronto, ON, Canada, M2P 2A8

W. www.afilias.info
T.  +1.416.646.3304 x4186
--
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] Argh. Postfix/Mailman compatibility on Gentoo

[Phil Stracchino]

: Command died with status 2:
"/usr/lib64/mailman/mail/mailman post caerllewys". Command output: Group
mismatch error.  Mailman expected the mail wrapper script to be
executed as
group "mailman", but the system's mail server executed the mail
script as
group "nobody".  Try tweaking the mail server to run the script as group
"mailman", or re-run configure,  providing the command line option
`--with-mail-gid=nobody'.



I'd swear I fixed that *AT LEAST* once..


The easy solution:

1.  In /etc/postfix/main.cf:
mail_owner= postfix
default_privs = mailman

2.  Restart Postfix

Done.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
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/25/2018 02:54 AM, Andrew Hodgson wrote:
> 
> Thanks for this; I am on the Docker version which is not updated yet.  once 
> it gets updated and I migrate to it, will I be able to re-import those 
> missing messages by running a complete import again or will this cause more 
> trouble now?


You can re-run the import with the complete mbox as long as you specify
--since= with a date older than any of the messages in the mbox. Without
that, it won't import anything because the messages will all be 'too old'.

Running with the full mbox will be OK as those messages with Message-ID:
headers will be detected as duplicates and won't be added a second time,
but if the mbox is large, it would be faster to run with just the
messages without Message-ID: headers, but possibly not faster overall
considering the effort to extract those messages.


> I did run cleanarch on the mbox before doing any of this import work and 
> didn't get any issues.  The lists all came from Mailman 2.1 (starting from 
> around 2.1.5).


That's expected. Since even somewhat before Mailman 2.1.5, archive
mboxes have been good. It's normally only those started on Mailman 2.0.x
(or older?) or mboxes imported from elsewhere that have significant issues.

-- 
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] ARC

[Jordan Brown]

On 7/25/2018 2:53 AM, Stephen J. Turnbull wrote:
> Note that if I were intuit.com's CISO, I would fight tooth and nail
> against the system you suggest, because it implies that I have DKIM
> private keys for all those subdomains owned by clients.  Every spammer
> in the world would be trying to hack the server that has those keys.
> I could probably keep them out, but Lordy, the liability involved!

Well, yeah, but to provide such a service in a way that has any
resemblance to being secure, Intuit *must* have some secret that allows
it to send mail "from" those subdomains.  If Intuit doesn't need such a
secret, then anybody could send mail like that.

The price of the privilege of sending mail  on behalf of your clients is
that you must protect that ability so that villains cannot hijack it.

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

[Grant Taylor via Mailman-Users]

On 07/25/2018 03:53 AM, Stephen J. Turnbull wrote:
That's not how "on behalf of" worked in practice.  What happened in April 
2014, was that a home business owner (HBO) would send a pile of completed 
order notices to intuit.com, and intuit.com would send an invoice to each 
customer on behalf of h...@yahoo.com, from h...@yahoo.com.


Will you please clarify what the SMTP envelope from and the From: header 
were in the example(s) that you're talking about?


I'm going to assume (for the sake of discussion or until corrected) that 
both the SMTP envelope from and the From: header were h...@yahoo.com.


HBO, of course, doesn't have a vanity domain, just a Wordpress or 
SquareSite (or even Facebook) home page.


~twitch~

Tens of thousands of invoices worth millions of dollars bounced off of 
personal accounts and tiny business owner accounts at Yahoo! and other 
receivers who take p=reject as a command.


I assume "bounced off of" means that the messages were rejected by 
receiving MTAs that honored Yahoo's (et al) p=reject DMARC configuration.


I'll argue that DMARC is designed to 1) detect such spoofed email 
forgeries and 2) enable Yahoo (et al) to publish what they would like to 
be done with such spoofed email forgeries.


Granted, all the rejected / bounced invoices are contrary to the 
behavior that many individuals wanted.


But this also enabled DMARC enabled receiving MTAs to detect and reject 
other less white hat spoofed email forgeries.


I assume that this detection and rejection of any email claiming to be 
from Yahoo that didn't actually originate from Yahoo is exactly what 
Yahoo wanted to happen.


I feel like this is saying "We want something to detect the bad guys and 
block them, but still allow the good guys to do the exact same thing as 
the bad guys."  That has never worked very well.


Note that if I were intuit.com's CISO, I would fight tooth and nail 
against the system you suggest, because it implies that I have DKIM 
private keys for all those subdomains owned by clients.


What would you want to see done, as Intuit's CISO, instead of what I 
propose?


My purpose of the sub-domain of the client's domain is to transition 
(some of) the trust of the client's domain to Intuit's sub-domain 
therein.  I.e. I trust ietf.org, therefor I'll also trust intuit.ietf.org.


It is possible for Intuit to use a completely separate domain, 
intuit-ietf.org.  But there is not the same implicit relationship 
between intuit-ietf.org as there is intuit.ietf.org.


The intuit.ietf.org sub-domain is a completely different DNS zone that 
has been delegated from ietf.org to Intuit for them to manage / 
administer / operate for the purpose of hosting requisite services for 
IETF to be a client of Intuit.


What would you rather see done?  Does it also convey trust the same way 
that intuit.ietf.org does?


Every spammer in the world would be trying to hack the server that has 
those keys.


Why does that need to be one server?  What if it's a separate VM per 
client?  (I'd personally like that and pay more for such separation as 
Intuit's client.)


Assume for a moment that they are separate VMs.  How does the security 
of Intuit running X number of VMs differ from X number of clients 
running a VM?


I would think that it would actually worsen security posture because I 
would assume that Intuit would have a better understanding because of, 
and more data from, the larger population of VMs to administer.


Who knows more about securing things:  The thousand different entities 
that run one (or few) instances of something, or the one (or few) 
entities that run many instances of said thing?



I could probably keep them out, but Lordy, the liability involved!


I would certainly hope that the company that I'm outsourcing financial 
transactions to could secure the systems that process money.  I'd really 
hope that they could also secure systems that only process email.  With 
the security of the former systems exceeding the security need of the 
latter systems.  One stringent security policy protects both sets of 
systems.


Less financially painful are the services that newspapers and tourist 
destinations provided (note past tense, they're mostly dead now) where you 
could sit at a terminal and send a "postcard" recommending an article or 
with a picture of the attraction to family and friends "from" yourself, 
including your email address, simply by typing name and address in. 
Not a huge loss, I guess, but 


I think that all of those systems were behaving badly.  I think that 
they SHOULD have been sending with something like this:


 From:  Uncle Sam (via My Picture Kiosk) 
 To:  Cousin Larry 
 Reply-To:  Uncle Sam 

 Hi Cousin Larry,

 Check out this cool picture!!!

 --
 Uncle Sam sent you this picture from the LAX airport.

I think anything that spoofs or otherwise pretends to send as someone 
they are not is a form of abuse.


I also believe this form of 

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

[Jordan Brown]

Hmm.  It would take MUA changes to be fully effective, but a possibility
that comes to mind is to have mailing lists leave the original message
absolutely unmodified, but wrap it in a message that comes "from" the
mailing list.  That way everything about the message is verifiably true.

A list-aware MUA could more or less transparently unwrap such a
message.  It would probably display some indication that the message
came through the ML - the name of the list, unsubscribe mechanism,
archive pointers, ML header or footer text, et cetera, and maybe
activate alternative "reply" options[*]  - but would largely present the
message as "from" the original author, *via* the mailing list.

Perhaps the wrapper message would look like today's munged ML messages -
From: Real Person  / Reply-To: Real Person
 - but a list-aware MUA would largely hide that.

Of course there are a million details and getting adoption would be hard.

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

[Joseph Brennan]

On Tue, Jul 24, 2018 at 8:20 PM Grant Taylor via Mailman-Users <
mailman-users@python.org> wrote:

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


Well it is. The problem is that DMARC's notion of "alignment" contradicts
RFC 822, 2822, 5322, namely '''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.''' and contradicts RFC 821,
2821, 5321 that describes the MAIL FROM address as the address used "to
report errors". Mailing lists fully comply with the standard by keeping the
writer's address in the Header From and by putting the address to report
errors in the MAIL FROM. Nothing in email standards stated or even implied
that the two addresses need to be the same.

Of course a system can reject any email message for any reason or no
reason, so all I can do is point out that lack of "alignment" is a silly
reason for rejecting list mail. For transactional mail from sources like
financial institutions, where the sender can state that the two addresses
should "align", then it makes a lot more sense.

Joseph Brennan
--
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"

[Stephen J. Turnbull]

John Levine writes:

 > As I said a few messages ago, if lists did more stringent tests on
 > incoming mail, a lot of this complexity could be avoided,

I don't understand this.  If lists got a pass, every spam would grow
RFC 2369 header fields.  No?  So ISTM the received chain needs to be
authenticated for the recipient to trust any last-hop sender, list or
not.

 > but they don't so it can't.

Origin checks are generally very useful and effective in my
experience.  But I don't see how authentication can be avoided.
--
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"

[Stephen J. Turnbull]

Grant Taylor via Mailman-Users writes:
 > 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?

Let's be careful to distinguish between "DMARC" and the "p=reject" and
"p=quarantine" policies.

(1) DMARC's reporting features *can* and *should* be used on all
domains that send email, with very few exceptions.

(2) "p=reject" should never be used on domains that contain any
non-transactional mailboxes (ie, mailboxes used as the From which
might be reinjected into the mail system with changes).  This
recommendation was actually in some early unofficial drafts or
author discussions of RFC 7489, but doesn't appear to be in the
Internet-Draft prepublication series, and it's definitely not in
the published RFC.  (I believe that keeping such verbiage out of
the RFC is why the RFC is informational rather than normative.)

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

Hey, did you really want to write that?  There's about a millennium of
mail-RFC-writing and/or large site admin experience on the DMARC-WG.

So, there's fundamental misunderstanding here somewhere.  DMARC
depends on DKIM and SPF.  Neither can ensure that the *purported
author domain* of an email can be authenticated when passed through a
mailing list.  *The whole purpose of DMARC From alignment is to
authenticate the author domain in the context of her message!*  This is
simply impossible, unless the signed portions of the message arrive at
the destination *unchanged*, or the list is an authorized mail source
of the author domain for SPF.  Much legitimate email *does* change them,
however, and few lists cater exclusively to subscribers of the same
administrative domain.  (Of course getting list host IPs authorized as
mail sources for all potential SPF-using posters would be a nightmare!)

You propose that mailing list should munge From (and in fact you've
proposed that it should do so independent of DMARC, IIRC).  AFAICS,
this has three nasty effects (at least).

(1) It ensures that validation of From alignment of the actual author
will *fail*, because the From header *must* be signed in DMARC.
(SPF is pretty useless in the context of mailing lists.)

(2) It breaks all the quoting mechanisms in every existing MUA, which
now instead of, e.g.,

> Grant Taylor writes:

will insert

> Grant Taylor  via Mailman-Users writes:

Some styles would look a little better, some worse.  All, gag me.
This is imposing work on a lot of MUA authors, and it will be
ongoing as mailing lists keep changing their munging styles.

(3) Users may start to accept

From: "Grant Taylor  via
  All-Passwords-Yours-Now-Ours ML" 

(or whatever their MUA displays) as indicating authentic email
from you, because a lot of authentic mail indeed looks like that
in your scheme.  (This is a controversial point: a lot of security
pundits believe that most users will click on anything anyway.)

 > I feel like DMARC requires a paradigm shift in how email is forwarded 
 > and handled by mailing lists.

Three points for your consideration here:

(1) There's a fundamental problem, though: the *only* paradigm shift
compatible with DMARC's goal of authenticating the author's domain
is to *pass the message through with all signed portions
unchanged.*  (SPF doesn't have this problem: SPF can't authenticate
author domains of mailing list posts *at all*, unless the list is
hosted by the author's domain or its host's IP is listed as a valid
mail source by the author's domain!)

(2) DMARC is a *private protocol*.  RFC 7489 is *Informational*, it
has *no normative implications* for the rest of us.  We would be
perfectly conformant to all normative RFCs if we decided that mail
from sites that have a p=reject policy is undeliverable and
dangerous, and rejected it.  We're not going to do that, nor even
offer it as an option, but I'll leave that here for consideration.

(3) ARC, if the mailing list is accepted as trustworthy by recipients,
requires *no* change to mailing list behavior (aside from
participation in the ARC protocol, of course).  If not trusted,
we're back in the world of (1) and (2).

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

No, it can't, not in the same way.

(1) All of the above can be implemented in the MTA without any change
in end user or Mediator behavior.  These upgrades were frequently
transparent to admins of virtual domains (except that their mail
started working to sites it used to fail at).  Not so, DMARC.
Most 

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

[Andrew Hodgson]

Mark Sapiro wrote:

>On 07/24/2018 06:32 AM, Andrew Hodgson wrote:

[...]

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

Thanks for this; I am on the Docker version which is not updated yet.  once it 
gets updated and I migrate to it, will I be able to re-import those missing 
messages by running a complete import again or will this cause more trouble now?

I did run cleanarch on the mbox before doing any of this import work and didn't 
get any issues.  The lists all came from Mailman 2.1 (starting from around 
2.1.5).

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

[Stephen J. Turnbull]

Grant Taylor via Mailman-Users writes:

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

That's not how "on behalf of" worked in practice.  What happened in
April 2014, was that a home business owner (HBO) would send a pile of
completed order notices to intuit.com, and intuit.com would send an
invoice to each customer on behalf of h...@yahoo.com, from
h...@yahoo.com.  HBO, of course, doesn't have a vanity domain, just a
Wordpress or SquareSite (or even Facebook) home page.  Tens of
thousands of invoices worth millions of dollars bounced off of
personal accounts and tiny business owner accounts at Yahoo! and other
receivers who take p=reject as a command.

Note that if I were intuit.com's CISO, I would fight tooth and nail
against the system you suggest, because it implies that I have DKIM
private keys for all those subdomains owned by clients.  Every spammer
in the world would be trying to hack the server that has those keys.
I could probably keep them out, but Lordy, the liability involved!

Less financially painful are the services that newspapers and tourist
destinations provided (note past tense, they're mostly dead now) where
you could sit at a terminal and send a "postcard" recommending an
article or with a picture of the attraction to family and friends
"from" yourself, including your email address, simply by typing name
and address in.  Not a huge loss, I guess, but 

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

I've never seen SRS in the wild, except in the headers of some of the
crazier denizens of IETF mailing lists.  YMMV, of course.

 > thus breaking DMARC alignment.

Simple .forwarding breaks SPF of the author domain, period, unless
entirely within one administrative domain, and that domain is
well-configured so that all the forwarding is internal, and the SPF
checks are all done at the boundary.

I guess in the case where forwarding takes place entirely within an
administrative domain, DMARC From alignment could be broken without
breaking SPF itself because From alignment is validated on a different
host from SPF, but that sounds like a case of "evolution in action".

 > My understanding is that DMARC can be configured to require both SPF and 
 > DKIM alignment.

That's non-conforming to RFC 7489.  Section 4.2:

A message satisfies the DMARC checks if AT LEAST ONE of the supported
authentication mechanisms:

1.  produces a "pass" result, and

2.  produces that result based on an identifier that is in alignment,
as defined in Section 3.

[Emphasis mine.]

 > The point being that simple .forward(ing) may still break things.
 > 
 > I maintain that detecting such is one of the functional purposes of 
 > DMARC.

Of course.  That's why it's not "DMAC" (although either would be a
great street name for a hip-hop DJ!)

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

I'm afraid I failed to make the concept explicit again.  Remember,
authenticating mail origin doesn't prevent anyone from sending
malicious mail, or even from having it delivered.  So while I suggest
that ARC processing results be taken seriously in the presence of
(List-* headers) for DMARC alignment purposes, delivery is also
conditional on (not malicious).  If a site wants to be conservative
and assume some degree of malice until it's seen "enough" benign
traffic, that's consistent with what I intended.

Also, sites like GMail and Yahoo! might very well be willing to
specially handle From addresses at sites known to have leaked a
billion address books.  Similarly, they could "throttle" on floods of
ARC email via purported mailing lists that have never been seen
before.  I acknowledge that sites managed by single admins would
likely be unwilling, and perhaps even unable, to come up with such
systems.

N.B. By "intended," I mean to admit that my wording in the previous
post strongly suggested that they would start with the assumption that
mail is benign until proven otherwise.  I can't fault you for taking
my words literally. :-)

Steve
--
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: