[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 <mailman-users at python.org> 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 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.

The problem with DMARC is that it DOES attempt to protect end-to-end. That works if you limit DMARC to ‘valuable’ emails that you can say shouldn’t go through things like mailing lists. That job it does well. The issue is when it is MISUSED  by a domain like YAHOO and used for email addresses which might be used on a mailing list.

SPF and DKIM actually work ok to as their base standards, as they accept matches to the envelope, so a message from my mailing list passes SPF and DKIM. The issue with DMARC is that it changes SPF and DKIM so that recipients need to check against the From: header in the message, so mailing list need to claim authorship of messages that pass through them to pass DMARC.
> 
>> 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 of it.
> 
> I disagree with the idea of /needing/ to apply different levels of security to different domains based on their (primary) use.  I have no objection if people /want/ to apply different levels of security to different domains.  IMHO they should not be required to do so.
> 
> I also object to the thought that individuals (humans) sending email aren't eligible to the same level of protection as other services (non-humans) because we as email administrators can't figure out how to make things work in a way that supports both.
> 
> -- 
> Grant. . . .
> unix || die
> 

DMARC says that if you get a message from me, it MUST have come straight from me without ANY modifications. This is a reasonable thing for things like a bank statement or a bill, that shouldn’t pass through something that changes the message. As you said above, those modification are reasonable for a mailing list. That says that DMARC wasn’t the right solution for that part of the problem. 

In some ways it is a bit like saying I want to be safer on the highway, so I am going to drive a tank, and who cares what it does to everyone else (and the road). 

The issue with different types of email using different levels of security is that some types of email can reasonably use some techniques that are just not appropriate for others due to the type and use of that email.