no more subject prefix for xetex mailing list

Zdenek Wagner zdenek.wagner at
Tue Mar 5 03:13:11 CET 2019


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 at 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

út 5. 3. 2019 v 2:36 odesílatel <mskala at> 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 Now the mail is sent
> > from but is signed by a key from, 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 "" but not on "," then a message From: an
> address is required by DMARC to be handled under the
> policy of  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, which domain signs with DKIM and sets a
> restrictive policy, sends mail to the list and the list rewrites the From:
> header to an address, then the RFC5322.From domain will be
> "" and only the DMARC policy published by will be used to
> determine handling by an RFC 7489 compliant recipient.  DKIM does not pass
> if didn't sign, passes if did sign, but either way it is
>'s policy (or lack thereof) that determines handling.  The policy
> of is out of the picture entirely, and DKIM signatures from
> 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                 People before tribes.

More information about the XeTeX mailing list