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
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@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/archive%40jab.org
