So, maybe a header canonicalization that has as one of its steps conversion of all Subject fields to something RFC2047-compatible?
On Tue, Mar 24, 2015 at 1:39 PM, John Bucy <jb...@google.com> wrote: > The scenario I had in mind was: > - B advertises SMTPUTF8 but relays to C which does not > - A sends a message to B with an unencoded utf8 Subject: invoking the > SMTPUTF8 extension > - B could opt to encode the Subject: header using rfc2047 to produce a > message acceptable to C > > > On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy <superu...@gmail.com > > wrote: > >> On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull <step...@xemacs.org> >> 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. >>> >>> > Do you have a suggestion in mind? >>> >>> Conform to RFC 6376.<wink /> >>> >> >> OK, but is it folly to consider a header canonicalization that can handle >> this? DKIM is designed to accommodate incremental improvements, after all. >> >> -MSK >> >> >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
