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
- Original Message -
From: Murray S. Kucherawy superu...@gmail.com
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
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.
Murray S. Kucherawy writes:
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
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 /
On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
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. :-(
As I read 5.3, it says you
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
- 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
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
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
On Mon, Mar 23, 2015 at 5:25 PM, John Bucy jb...@google.com wrote:
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
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 Fri, Mar 20, 2015 at 10:25 AM, John Bucy jb...@google.com wrote:
Hadn't seen that ID, cool! Is there any test data available?
Hadn't seen that ID, cool! Is there any test data available?
cheers
john
On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
There was one proposed:
https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00
This working group will be discussing this and
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 jb...@google.com wrote:
I was glad to see mention of content-transfer-encoding
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
___
14 matches
Mail list logo
