no more subject prefix for xetex mailing list

[mskala at ansuz.sooke.bc.ca]

On Tue, 5 Mar 2019, Zdenek Wagner wrote:
> DMARC can be set as one of the following ways:
> * The mail is valid if at least one of SPF and DKIM passes
> * If the mail is signed, it is valid if both SPF and DKIM pass
>
> Let's assume that we have the latter case and we try to "solve" it by
> changing the From header to something at tug.org. Now the mail is sent
> from @tug.org but is signed by a key from @example.com, hence DKIM
> fails.

As described in RFC 7489 section 6.6.3, the RFC5322.From domain is queried
for the DMARC policy to apply.  If that returns nothing, there is a
fallback to the "Organizational Domain" of the RFC5322.From but it still
has to come from the RFC5322.From domain.  That means that if there's a
policy on "tug.org" but not on "foo.bar.tug.org," then a message From: an
@foo.bar.tug.org address is required by DMARC to be handled under the
policy of tug.org.  But that's the only way in which a policy other than
that of the exact domain in the From: header can ever be applied by a
compliant implementation.

[From RFC 7489:]
   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

   2.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.

   4.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   5.  If the remaining set contains multiple records or no records,
       policy discovery terminates and DMARC processing is not applied
       to this message.
[end]

If a user from example.com, which domain signs with DKIM and sets a
restrictive policy, sends mail to the list and the list rewrites the From:
header to an @tug.org address, then the RFC5322.From domain will be
"tug.org" and only the DMARC policy published by tug.org will be used to
determine handling by an RFC 7489 compliant recipient.  DKIM does not pass
if tug.org didn't sign, passes if tug.org did sign, but either way it is
tug.org's policy (or lack thereof) that determines handling.  The policy
of example.com is out of the picture entirely, and DKIM signatures from
example.com still attached to the message cannot be used to determine
handling by a compliant recipient.

Of course there can be non-compliant recipients out there, and there could
be other behaviour with recipients that implement SPF or DKIM without
DMARC, and for the benefit of such recipients it might be a good idea to
strip off incoming DKIM signatures.  But I don't think that's terribly
important.  Random extra DKIM signatures from unaligned domains are not
rare in the wild and they don't seem to be causing huge problems; at the
very least, just rewriting From: without stripping incoming signatures
would be a big improvement over the current situation of the XeTeX list.

-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/