[Mailman-Developers] Re: GDPR disclaimers and redaction in mailman 2

In article <20180726083240.horde.yz7mtoof32nssryse90t...@andreasschulze.de> you write: > >John Levine: > >> Another is to provide different views of what lists exist depending on >> what IP address you're connecting from, so internal lists are only >> visible

[Mailman-Developers] GDPR disclaimers and redaction in mailman 2

Someone has asked me about some adjustments mailman 2 related to what they think they have to do for GDPR compliance. One is to add some checkbox stuff to agree at subscription time that you understand what info you're providing. I expect this could be spliced in the same way CAPTCHAs are. Anoth

Re: [Mailman-Developers] Use of the public suffix list

In article you write: >Hi all, >* The specs say that "DMARC should be amended to use [a method better than PSL] >as soon as it is generally available" [1]. I believe that sentence refers to >RDAP, which was released more or less at the same time (March 2015) [2]. Sorry, that is wrong. It was re

Re: [Mailman-Developers] GDPR

In article <01qj5jk26gxi000...@encompasserve.org> you write: >| tl;dr > >Too long: The regulation and articles are even longer. > >Didn't Read: But you replied none-the-less ;-) Having been talking to some actual lawyers about GDPR compliance, I find this analysis absurd. Specifically about the r

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

In article you write: >On 05/10/2017 12:18 PM, John Levine wrote: >> In article <20170510133609.61fba...@subdivisions.wooz.org> you write: >>> I probably need more convincing that it would actually be used out in the >>> field, ... >> >> Gmail's

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

In article <20170510133609.61fba...@subdivisions.wooz.org> you write: >I probably need more convincing that it would actually be used out in the >field, ... Gmail's already implemented it. I'm pretty sure Yahoo is also planning to. > But OTOH, if it's of some utility it doesn't look >like it wo

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

In article <20170510120723.xgg3apmj65cmv...@sys4.de> you write: >Greetings, > >I'm not sure if anyone has followed development of RFC 8058 "Signaling >One-Click Functionality for List Email Headers" located at > and brought this topic up on this >list. > >Is

[Mailman-Developers] New DMARC workaround hack

Take a look at these: https://tools.ietf.org/html/draft-andersen-arc-00 https://tools.ietf.org/html/draft-jones-arc-usage-00 These add new headers based on DKIM that document a chain of custody for mail. It would let mail providers accept list mail that DMARC would otherwise reject. The drafts

Re: [Mailman-Developers] SUBMIT and OpenID, was Two more DMARC mitigations

>Thinking about it this way, I'm not really sure what's being considered for >DMARC, ... Nothing specifically for DMARC. The idea is that SASL, the layer you use to log into pop, imap, and submit servers, now includes oauth as an authentication scheme and OpenID as the common way to get the token

Re: [Mailman-Developers] SUBMIT and OpenID, was Two more DMARC mitigations

>>> At least one of the large providers has told me they plan to do OAUTH >>> submission, presumably with long lived tokens, which would greatly >>> mitigate the security issues. > >I'm trying to track down what's actually going on here. It's SUBMIT >either way, so everything in the code except t

Re: [Mailman-Developers] GnuPG support

>Yes, except we don't want to use the mailing list maintainer keys, or >make him manually decrypt/encrypt every message. >This should be done automatically by Mailman, and we want to use the >mailing list keypair. Sympa does something like this with S/MIME. Incoming list messages are encrypted to

Re: [Mailman-Developers] Two more DMARC mitigations

>>* Forwarding signature >> >>The IETF DMARC list is discussing a mutant weak DKIM signature from a >>sending system (e.g. Yahoo and AOL) that would survive forwarding, but >>contains a list of forwarding target domains. It's only considered >>valid if it's with a signature from the forwarding dom

Re: [Mailman-Developers] Two more DMARC mitigations

>>Honestly, Tough Noogies. Let list managers make their own security >>decisions. AOL and Yahoo want all mail from their users to be authenticated. >>Well, OK, this will do it. > >This is a really bad idea. In MM3, we've already eliminated the need for >keeping clear text passwords, and almost g

[Mailman-Developers] Two more DMARC mitigations

* Forwarding signature The IETF DMARC list is discussing a mutant weak DKIM signature from a sending system (e.g. Yahoo and AOL) that would survive forwarding, but contains a list of forwarding target domains. It's only considered valid if it's with a signature from the forwarding domain, i.e., t

Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge

>> How do you limit it to just addresses with DMARC problems? There's no >> benefit to doing it to everyone. >> >Because a DMARC record is published in DNS, Mailman must use a Python >module capable of querying DNS. MM 2.1.18 uses the dnspython > package for this. I b

Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge

>Exactly how to patch this depends on what Mailman version you're >starting with, but you basically want some code like this. > >name, addrs = parseaddr(msg.get('from')) >addrs += '.invalid' >del msg['from'] >msg['From'] = formataddr((name, addrs)) > >If you put it in Mailman/Handle

Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge

In article <1856298671.144791.1400292991012.javamail.zim...@peachymango.org> you write: >The trouble with .invalid is that it is a domain that do not accept emails. >Therefore why should you accept emails from a domain >that does not allow you to reply to it? > >It is bound in the future to creat

Re: [Mailman-Developers] Anyone tried the DMARC mail address translucent forwarder hack?

>>> that points to a server that rewrites the address and remails it, e.g. >>> mme...@yahoo.com.remail.lists.org -> mme...@yahoo.com. >I'm not very expert in this area, but it seems at least with the above, >you'd need DNS entries for yahoo.com.remail.lists.org, >aol.com.remail.lists.org, thenexto

[Mailman-Developers] Anyone tried the DMARC mail address translucent forwarder hack?

> and a really evil one where you append a name >that points to a server that rewrites the address and remails it, e.g. >mme...@yahoo.com.remail.lists.org -> mme...@yahoo.com. This is apparently what LISTSERV does, give or take details of the syntax of the forwarding address. Has anyone tried thi

Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge

>> From: Marissa > >I have some sympathy for this approach, as I mentioned over in mailman-users. >It violates RFCs so I'm not sure Mailman should adopt it, but it's worth >experimenting with, and I'm glad you (John) are doing so, and providing >feedback here. I know the guy who wrote the RFC, a

Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge

om: is the list. Something I have considered but not implemented is to add a fake Cc: line with the unmunged address so reply-to-all will work. It's not clear whether that would be more confusing than useful. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY

[Mailman-Developers] Fixing DMARC problems with .invalid munge

I realize I'm a bit late to this party, but this is a technique that I don't think has been addressed here. On my lists I've fixed the DMARC bounces by rewriting From: lines of DMARC'ed domains like this on the way out: From: Marissa to From: Marissa Before you tell me I'm nuts, hear me