no more subject prefix for xetex mailing list

[Zdenek Wagner]

Hi,

your description is exact but I do not agree that there is not a huge
problem. Gmail accepts majority of such mails. Only if I display the
original message, I can see DKIM FAIL and DMARC FAIL. However, I had
problems with forwarded messages and important invoices were not
delivered and I was penalized for not paying on time because the mail
with the invoice was rejected by gmail. I have a mailserver for
math-gnostics.eu at seznam.cz which has a very strict policy. If the
result for an incoming mail is DKIM FAIL + DMARC FAIL, the mail is
rejected and I am not informed that a mail was rejected

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

út 5. 3. 2019 v 2:36 odesílatel <mskala at ansuz.sooke.bc.ca> napsal:
>
> 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/