On Wed, 01 Apr 2015 11:20:50 PDT,
"Murray S. Kucherawy" <superu...@gmail.com> wrote:
> On Wed, Apr 1, 2015 at 11:11 AM, John Levine <jo...@taugh.com> wrote:
>
> > Has anyone looked at my double signing draft? The idea is the the
> > original sender (which we'll call, oh, Yahoo) puts on a very weak
> > signature probably only on From, Date, and Message-ID, with l=0 and a
> > new tag that says the signature is only valid if the message is also
> > signed by a specific other domain, call it ietf.org. It probably also
> > puts on an ordinary strong signature, too, and sends the message to a
> > list forwarder such as dmarc@ietf.org. The list does what it does,
> > and signs the message normally with d=ietf.org. That breaks the
> > strong yahoo signature, but the weak one is now valid in combination
> > with the normal ietf.org signature, so there's a valid d=yahoo
> > signature and DMARC is happy.
> >
> > The forwarder could of course do naughty things, but only the specific
> > forwarder to whom the message was sent, which greatly limits the scope
> > of damage. It's even more limited in the common case that the original
> > sender has a reasonably good idea who are likely to be the well
> > behaved forwarders and only puts the weak signatures on mail sent to
> > them.
> >
>
> Didn't we stalemate on the question of whether this has to be a whole new
> header field, or a "v=" increase? I seem to recall someone (Dave?)
> thinking both were horrible.
>
> -MSK
To avoid a new header field or a "v=" increase, to make DMARC failure a really
reliable indication of genuine invalidity, at least where mailing lists
are concerned, why not focus on the fact that RFC5322.From headers clearly
allow multiple addresses, and invite Mediators such as mailing list to take
responsibility for their changes by adding an address in their own domain
to the RFC5322.From header and adding their own DKIM-Signature?
RFC7489 seems to hem and haw a bit about multiple From addresses (in a
single From header). E.g., in Section 6.6.1:
o Messages bearing a single RFC5322.From field containing multiple
addresses (and, thus, multiple domain names to be evaluated) are
typically rejected because the sorts of mail normally protected by
DMARC do not use this format;
and a little later in the same section:
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.
(The word "fail" leaves me confused. Shouldn't that be "pass"?)
At any rate, it seems to me that if DMARC would be satisfied by a Mediator
making substantial modifications to my message, changing the RFC5322.From
to
From: "Michael Jack Assels" <mjass...@porn-list.example.xxx>
and signing appropriately, it ought to be similarly happy with
From: "Michael Jack Assels" <mjass...@encs.concordia.ca>,
"dmarc" <no-re...@ietf.org>
Sender: "dmarc" <dmarc-boun...@ietf.org>
signed by IETF's sending MTA. Assuming that the usual change is made to
the Subject line and the usual trailer is appended to the message body,
only the "ietf.org" identity ought to align with "the" RFC5322.From domain,
and I can't see a reason why DMARC wouldn't be happy. Yes, someone could
have spoofed my address, but IETF's receiver will have had an opportunity
to check that, so it's either IETF's fault for accepting the original message
or my MTA's fault for not being DMARC compliant.
In this case, the mailing list would be doing what's asked of it by DMARC,
but keeping (most of) it's time honoured values intact.
MJA
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
