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

[Grant Taylor]

On 07/22/2018 11:02 PM, Stephen J. Turnbull wrote:
> You're misunderstanding.  The ARC community doesn't discourage 
> whitelisting other sites.  The work to do whitelisting does.

Thank you for clarifying Stephen.  I was afraid that you were somehow 
implying that there was some sort of guideline on what sits should and 
should not implement ARC.  I didn't think that was what you were meaning 
to imply, but the doubt was there, hence the questioning.

> Mailing lists are *known* to *frequently* (almost always) break DKIM 
> signatures in a way amenable to repair by ARC.[1]

ACK

> The other main pain points for DMARC are third-party services that 
> are authorized by the owner of a mailbox to send mail "on behalf of", 
> without participation of the adminstrator of the mailbox's domain. 
> An example is invoicing services.  These do not benefit from ARC *at all* 
> because they have a valid DKIM signature from the originating domain, 
> who can be trusted for that service, but don't get such a signature from 
> the mailbox's domain as required for DMARC From validation.

I hear and acknowledge what you're saying.

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.  I would also expect the from address to reflect the 
sub-contractor's (sub)domain with a Reply-To: directing replies to 
proper main (parent) domain.  (Or some mailbox associated there in.)  I 
would also expect to see some sort of verbiage stating that "This 
message was sent on the behalf of $Parent by $3rdPartyContractor."

I would also hope / expect to see some sort of linking text / 
acknowledgement from the parent that they have (sub)contracted some 
services to a 3rd party.

But, I learn more and more every day that I have different expectations 
than most people.

> 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) 
thus breaking DMARC alignment.

My understanding is that DMARC can be configured to require both SPF and 
DKIM alignment.  Maybe it's only for reporting and not for pass / fail 
tests.  I'd have to go back and re-read the specifics about DMARC again.

The point being that simple .forward(ing) may still break things.

I maintain that detecting such is one of the functional purposes of 
DMARC.  This is independent of is such benign or malicious.

> I guess large services like GMail can eventually add a feature where a 
> user can configure GMail to recognize and whitelist specific sites where 
> they have mailboxes set to forward to GMail.  But I doubt this will 
> ever be a standard feature of MDAs.  It will be complex and fragile to 
> implement, and almost never used.

Agreed to both aspects.

> Footnotes:
> [1]  Note that I disagree somewhat with John.  I suspect that humongous 
> providers like GMail, Yahoo!, and Microsoft will automatically accept 
> ARC in the presence of a RFC 2369 List-* header, and blacklist on bad 
> behavior, as they do now.  That's not perfect from a list admin's point 
> of view---it requires a lot of resources to do that well, so small sites 
> probably won't---but it's not too bad.

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



-- 
Grant. . . .
unix || die