----- Original Message -----
> From: "Stephen J. Turnbull" <step...@xemacs.org>
> To: "Murray S. Kucherawy" <superu...@gmail.com>
> Cc: dmarc@ietf.org, "John Bucy" <jb...@google.com>
> Sent: Tuesday, March 24, 2015 8:17:47 AM
> Subject: Re: [dmarc-ietf] interoperability issues around
> gateway-transformation
>
> Murray S. Kucherawy writes:
> > On Mon, Mar 23, 2015 at 5:25 PM, John Bucy <jb...@google.com> wrote:
>
> > > An mta could opt to send a message with unencoded utf8 headers (display
> > > name, subject, etc) to another peer advertising SMTPUTF8 even if none of
> > > the envelope were internationalized addresses. If the recipient then
> > > needed
> > > to relay the message on to a site that didn't support SMTPUTF8, it would
> > > have to encode the headers.
>
> > You're right, it doesn't.
>
> AFAICS use of the SMTPUTF8 extension is incompatible with DKIM
> signatures. See sec. 5.3 of RFC 6376.
>
Luckily in RFC6376 there is:
"More generally, the Signer MUST sign the message as it is expected to
be received by the Verifier rather than in some local or internal
form."
and RFC6531 says (3.2):
"If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the
SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized
email address and MUST NOT transmit a mail message containing
internationalized mail headers"
"If it is not an MSA or is an MSA and does not choose to transform
the message to one that does not require the SMTPUTF8 extension,
it SHOULD reject the message."
So in the case above, the MTA should not attempt to convert the message and
just bounce it.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
