Subject: [dmarc-ietf] interoperability issues around gateway-transformation

From: John Bucy <[email-masked]>
Date: Thu, 19 Mar 2015 13:45:01 -0700

I was glad to see mention of content-transfer-encoding issues
in draft-ietf-dmarc-interoperability since gateway-transformation breaks
dkim signatures. Is there any interest in trying to develop a mime-aware
canonicalization for dkim?

cheers
john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Mar 2015 18:28:43 -0700

There was one proposed:

https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00

This working group will be discussing this and other options before long.

-MSK

On Thu, Mar 19, 2015 at 1:45 PM, John Bucy <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: John Bucy <[email-masked]>
Date: Fri, 20 Mar 2015 10:25:59 -0700

Hadn't seen that ID, cool! Is there any test data available?

cheers
john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Mar 2015 11:33:22 -0700

Not yet. I don't think there are any implementations.  We were just banging
the idea around.  I'm looking at doing one soon for OpenDKIM as an
experimental add-on.

---

From: John Bucy <[email-masked]>
Date: Mon, 23 Mar 2015 17:25:15 -0700

Based on a quick glance, it doesn't look like
draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047.
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.

On Fri, Mar 20, 2015 at 11:33 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> Not yet. I don't think there are any implementations.  We were just
> banging the idea around.  I'm looking at doing one soon for OpenDKIM as an
> experimental add-on.
>
>> On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy <[email-masked]
>> > wrote:
>>
>>> There was one proposed:
>>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Mar 2015 20:44:10 -0700

> have to encode the headers.

You're right, it doesn't.  It's only meant to address body modifications
that lists might do.  In fact it is specifically a body canonicalization.
I hadn't done any work on list-sensitive header canonicalization yet.

Do you have a suggestion in mind?

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 00:17:47 +0900

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

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Mar 2015 10:40:15 -0500 (CDT)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> To: "Murray S. Kucherawy" <[email-masked]>
> Cc: [email-masked], "John Bucy" <[email-masked]>
> Sent: Tuesday, March 24, 2015 8:17:47 AM
> Subject: Re: [dmarc-ietf] interoperability issues around	gateway-transformation
> 
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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 12:22:31 -0700

> 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

---

From: John Bucy <[email-masked]>
Date: Tue, 24 Mar 2015 13:39:29 -0700

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 14:02:13 -0700

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 <[email-masked]> wrote:

> On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy <[email-masked]
> > wrote:
>

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Mar 2015 16:57:37 -0500 (CDT)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>

> On Tue, Mar 24, 2015 at 1:39 PM, John Bucy < [email-masked] > wrote:

> > - B could opt to encode the Subject: header using rfc2047 to produce a

No, the EAI RFC is clear, if the MTA (B) cannot send it as is, you MUST bounce it. 

remember EAI does not offer any downgrade capability at the MTA level (by design).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 10:46:50 +0900

> OK, but is it folly to consider a header canonicalization that can
 > handle this?  DKIM is designed to accommodate incremental
 > improvements, after all.

Sec. 5.3 isn't, though. :-(

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 21:11:54 -0700

> Sec. 5.3 isn't, though. :-(

As I read 5.3, it says you need to make sure what you sign is what the
verifier will receive.  It seems to me a signer that gets 8-bit header
fields can RFC2047-ize them before signing, presuming the MTA will make the
same conversion before putting the signed message out on the wire.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 15:42:26 +0900

Murray S. Kucherawy writes:

 > As I read 5.3, it says you need to make sure what you sign is what
 > the verifier will receive.  It seems to me a signer that gets 8-bit
 > header fields can RFC2047-ize them before signing, presuming the
 > MTA will make the same conversion before putting the signed message
 > out on the wire.

I'm not sure what you're trying to say here.  If the outgoing MTA has
SMTPUTF8 enabled, then it has the option of not encoding them and
leaving them as "raw" UTF-8.  But if is encounters an MTA that doesn't
support SMTPUTF8, it must encode or bounce.  In an SMTPUTF8-enabled
environment, whether the header is encoded or not is nondeterminis-
tic.

So that presumption is invalid.  The signer really has to force RFC
2047 encoding, and so may as well do it itself.