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 signe
On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull
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 need to ma
Murray S. Kucherawy writes:
> On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull
> 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.
>
> OK, bu
- Original Message -
> From: "Murray S. Kucherawy"
> 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 m
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 wrote:
> The scenario I had in mind was:
> - B advertises SMTPUTF8 but relays to C which does not
> - A sends a message to
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull
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
>
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Murray S. Kucherawy"
> Cc: dmarc@ietf.org, "John Bucy"
> Sent: Tuesday, March 24, 2015 8:17:47 AM
> Subject: Re: [dmarc-ietf] interoperability issues around
> gateway-transfo
Murray S. Kucherawy writes:
> On Mon, Mar 23, 2015 at 5:25 PM, John Bucy 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 re
On Mon, Mar 23, 2015 at 5:25 PM, John Bucy 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 peer advertisin
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 internationaliz
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 wrote:
> Hadn't seen that ID, cool! Is there any test data available?
>
>
>
> cheers
> j
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
wrote:
> 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 be
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 wrote:
> I was glad to see mention of content-transfer-encoding issues
> in draft-i
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
___
d
14 matches
Mail list logo
