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

[Grant Taylor]

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

> 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 to the subscriber, DMARC can and 
does work with MLMs.

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

> DMARC says that if you get a message from me, it MUST have come straight 
> from me without ANY modifications.

EXACTLY.

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.

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

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

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