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

Tue Jul 24 22:11:42 EDT 2018

> On Jul 24, 2018, at 9:43 PM, Grant Taylor via Mailman-Users <mailman-users at python.org> 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 subscriber at 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, 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.

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.
> 
>> 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 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.
> 
>> 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.
> 
> I think that any solution should work equally well when applied to all subsets (types of email) of the technology it applies to (email in general).
> 
>> 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.
> 
> I have no problem with what AOL and Yahoo did.
> 
> I think they used a tool in the way that it was meant to be used.
> 
> I do agree that there was undesired repercussions.  But I believe said repercussions were because MLMs didn't do what I think they should have done.
> 
>> 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.
> 
> Messages from an MLM will NOT pass SPF checks if -all is used -and- the MLM is not altering the SMTP envelope's from address.
> 

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.

> The original DKIM signature may or may not pass through an MLM, depending on how the MLM is configured.
> 
>> 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.
> 
> I have no problem with that.
> 
> Look at steps 1 through 4 above and you will see that I think MLMs (or their hosting MTAs) SHOULD do this

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  
> .
> 
>> DMARC says that if you get a message from me, it MUST have come straight from me without ANY modifications.
> 
> EXACTLY.

So you don’t think mailing list should do any modifications to the message, or they need to claim authorship.
> 
> That means that there's NO forwarding or passing through an MLM.
> 
> If the message doesn't come straight from you (or your delegates), the message is NOT from you.

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

>> This is a reasonable thing for things like a bank statement or a bill, that shouldn’t pass through something that changes the message.
> 
> I think it's also reasonable for things like AOL and Yahoo.

Only if the TELL ALL there users that they have effectively should not use virtually any of the existing mailing lists (except of course for yahoo users using yahoo groups, as yahoo knows enough to be able to make those pass)

> 
>> As you said above, those modification are reasonable for a mailing list.
> 
> Yep.  I do think those modifications are reasonable for mailing lists.
> 
>> That says that DMARC wasn’t the right solution for that part of the problem.
> 
> No.
> 
> There is nothing that precludes the mailing list from adding it's own security (SPF, DKIM, DMARC).
> 
> I also strongly suggest that the MLM remove any associated inbound security (after responding accordingly).
> 
> Thus the /content/ of the message can be copied from the incoming message to 10s / 100s / 1,000s of new completely independent outbound messages.  The key being the /content/ not the raw message itself.

Should they also be given new message-ids (as they are new messages) and thus threaded views not work anymore?
> 
>> 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).
> 
> If said tank meets all the following criteria, go for it:
> 
> 1)  It's licenses.  (I'm assuming that it is for the sake of this conversation.)
> 2)  It's within weight limits.
> 3)  It's within height, width, and length limits.
> 4)  It doesn't do any damage to the road.  (Read:  rubber road tracks.)
But DMARC is allowed to damage the Email system 
> 5)  You don't do anything threatening with it.
> 
> If you meet those requirements, then knock yourself out.
> 
>> 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.
> 
> I disagree.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/richard%40damon-family.org