Scott,
You're [still!] confusing multiple conceptions of trust, including at least:
1) trust in the intention and ability of multiple upstream forwarders to
ARC-sign correctly,
2) trust in the lack of intention to abuse by the organisation at the other end
of the SMTP connection, and
3) trust in the intention and ability of the organisation at the other end of
the SMTP connection to make exactly the same decision about disposition of a
particular message (in fact: of all messages) as you would.
Implicit in (3) are two additional assumptions that may or may not be true:
a) that the organisation at the other end of the SMTP connection has exactly
one level of confidence in message disposition (this is patently not true;
larger senders/forwarders routinely maintain discernibly separate pools in
order to help receivers make better choices), and
b) that you have exactly one level of confidence in message disposition (this
may well be true of you personally as it is of me, but it certainly isn't for
larger forwarders).
For larger receivers, the ability to see upstream (only possible when they
trust at least one of the upstream intermediaries to ARC sign correctly) allows
better decision-making (e.g. about DMARC overrides) than does your apparent
"the organisation at the other end of the SMTP connection is good/bad"
dichotomy. Note in particular that the ability to test ARC signatures from
forwarders upstream of the organisation at the other end of the SMTP connection
allows for DMARC overrides to happen, specifically, in the situation where the
receiver doesn't trust the organisation at the other end of the SMTP
connection. Adding ARC makes this possible more frequently than DMARC+SPF+DKIM
does.
- Roland
Roland Turner
Labs Director
Mobile: +65 9670 0022
3 Phillip Street, #13-03 Royal Group Building, Singapore 048693
________________________________
www.trustsphere.com
________________________________________
From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of Scott
Kitterman via dmarc-discuss <dmarc-discuss@dmarc.org>
Sent: Monday, 8 February 2016 03:43
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] introduction to the list-virtual server & mailman
questions
To start with, you'll have to explain why receivers should trust a sender to
not lie about where they got the mail from in an ARC header field if they don't
already trust the sender.
Scott K
On Sunday, February 07, 2016 11:14:12 AM Franck Martin via dmarc-discuss
wrote:
> ARC will help, but there are many mailing lists that don't have DKIM or
> even SPF. So even if ARC is available tomorrow, it may take years before
> mailing lists adopt any solution. So someone will have to make a stand, to
> get operators to deploy something.
>
> On Sun, Feb 7, 2016 at 10:10 AM, Al Iverson via dmarc-discuss <
>
> dmarc-discuss@dmarc.org> wrote:
> > The mailing list question can be a bit tricky. Yeah, the DKIM
> > signature is supposed to transport just fine, unless your MLM rewrites
> > any header or content that breaks the signature. And when you deal
> > with that, eventually you're going to run into list subscribers whose
> > posts get rejected by some other subscribers, due to the poster's
> > domain having a P=reject DMARC policy.
> >
> > I would say there's not a clear consensus on how best to handle
> > mailing lists in a DKIM+DMARC world. A bunch of email folks are
> > working on a standard called Authenticated Received Chain (ARC) that
> > would in theory help to address issues with mailing lists. (See
> > http://arc-spec.org/ ). But, we're a ways from being able to call that
> > a solution.
> >
> > I'm a mailing list operator myself, at probably about the same level
> > you are. (Instead of Mailman, I run a custom MLM that I wrote myself,
> > mostly as a programming exercise.) What I have chosen to do is strip
> > an existing DKIM signature, rewrite the from address if it appears to
> > be a domain that has a restrictive DMARC policy, and then sign it with
> > DKIM as the list domain. This works well for me, but not everybody
> > agrees that it's the best path. I'm not the only one to have done
> > something similar; Yahoo Groups, Google Groups Mail-list.com and
> > OnlineGroups.net all send as the group instead of as the poster either
> > all the time or as needed; and mailman can be configured similarly.
> >
> > Here's a link to an overview of the various issues in play for mailing
> > lists, and info on what I and others have chosen to do to address it.
> > http://www.spamresource.com/2015/02/dmarc-mailing-lists-roundup.html
> >
> > Here's where to go to learn more about what you can do with Mailman:
> > http://wiki.list.org/DEV/DMARC
> >
> > Note: There will probably be at least one really angry reply to this
> > post telling me how horrible this is and that I broke mailing lists.
> > It'll be a rehash of an argument from more than a year ago. Truth be
> > told, somebody else broke mailing lists; this is just how I personally
> > decided to implement a fix that seems to work well for me. YMMV.
> >
> > Regards,
> > Al Iverson
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> > _______________________________________________
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> >
> > NOTE: Participating in this list means you agree to the DMARC Note Well
> > terms (http://www.dmarc.org/note_well.html)
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
