I have seen a combination of references to 822 and 2822 in recent discussions
on the list. Is the requirement that DKIM support both 822/2822 content (822
being the current standard) or is the intent that DKIM is just required to
support 2822 content?
I believe there are two parts to the answ
On Jul 20, 2006, at 7:58 AM, Barry Leiba wrote:
I have seen a combination of references to 822 and 2822 in recent
discussions on the list. Is the requirement that DKIM support
both 822/2822 content (822 being the current standard) or is the
intent that DKIM is just required to support 282
Barry Leiba wrote:
>> Is the requirement that DKIM support both
>> 822/2822 content (822 being the current standard) or is the intent
>> that DKIM is just required to support 2822 content?
> I believe there are two parts to the answer to that:
> 1. We refer to RFC 282x, as the current standa
Dave Crocker wrote:
>
> I think your language describes things quite nicely.
>
> I am pretty sure that DKIM does not have anything that cares about 822 vs.
> 2822.
> That is, it works for both.
>
> So I have tended to view the dual-reference approach as a means of
> communicating
> to folks that
On Thursday 20 July 2006 11:51, Dave Crocker wrote:
> Barry Leiba wrote:
> >> Is the requirement that DKIM support both
> >> 822/2822 content (822 being the current standard) or is the intent
> >> that DKIM is just required to support 2822 content?
> >
> > I believe there are two parts to the
Scott Kitterman wrote:
>> So I have tended to view the dual-reference approach as a means of
>> communicating to folks that they do not have to worry about old-vs-new
>> specifications for message syntax/semantics.
>>
>> d/
>
> OK. I may have mis-remembered, but I thought that one aspect of the
> We should require that DKIM signers only sign messages that are
>RFC 2822 conformant. (We will need a small amount of text that
>explains why.)
I'd be inclined to say that messages to be signed SHOULD conform to
2822. There are some 822 MTAs that produce nice clean messages that
pass throu
John Levine wrote:
>> We should require that DKIM signers only sign messages that are
>> RFC 2822 conformant. (We will need a small amount of text that
>> explains why.)
>
> I'd be inclined to say that messages to be signed SHOULD conform to
> 2822. There are some 822 MTAs that produce nic
Dave Crocker wrote:
John Levine wrote:
We should require that DKIM signers only sign messages that are
RFC 2822 conformant. (We will need a small amount of text that
explains why.)
I'd be inclined to say that messages to be signed SHOULD conform to
2822. There are some 822 MTAs
sequences like:
line^M^M^J
which will get transformed into:
line^M^J
^M^J
Will that transformation cause things to break?
Maybe, but if they're going through the usual MTAs, they're breaking
already so I can't get too worried about it.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perp
John L wrote:
sequences like:
line^M^M^J
which will get transformed into:
line^M^J
^M^J
Will that transformation cause things to break?
Maybe, but if they're going through the usual MTAs, they're breaking
already so I can't get too worried about it.
That's not true. Sendmail does not
> >Maybe, but if they're going through the usual MTAs, they're breaking
> >already so I can't get too worried about it.
>
> That's not true. Sendmail does not change these strings.
Is that true on the SUBMIT front? or the MTA front?
> We really have
> absolutely
> no clue as to whether this i
Mark Delany wrote:
Maybe, but if they're going through the usual MTAs, they're breaking
already so I can't get too worried about it.
That's not true. Sendmail does not change these strings.
Is that true on the SUBMIT front? or the MTA front?
As far as I know, I run a submit
> Um, there's user experience, which last I heard sort of trumps everything.
> Can you say for absolute certain that the user experience of converting
> compliant 822 messages into compliant 2822 messages won't cause trouble?
> I sure can't. That at the very least ought to evoke some humility.
Sur
Mark Delany wrote:
>>> Maybe, but if they're going through the usual MTAs, they're breaking
>>> already so I can't get too worried about it.
>>>
>> That's not true. Sendmail does not change these strings.
>>
>
> Is that true on the SUBMIT front? or the MTA front?
>
>
Certainly NOT
Eliot Lear wrote:
> Mark Delany wrote:
Maybe, but if they're going through the usual MTAs, they're breaking
already so I can't get too worried about it.
>>> That's not true. Sendmail does not change these strings.
>>>
>> Is that true on the SUBMIT front? or the MTA fr
Dave,
>> Certainly NOT the MTA, and *even* if it does change on the SUBMIT front
>> who cares? That's before signing, right?
>>
>
> Not necessarily.
>
What about section 8 of RFC-4409 and all those fun little changes that
can be made? We're even covered in there in 8.5.
Eliot
_
Mark Delany wrote:
Um, there's user experience, which last I heard sort of trumps everything.
Can you say for absolute certain that the user experience of converting
compliant 822 messages into compliant 2822 messages won't cause trouble?
I sure can't. That at the very least ought to evoke some
Eliot Lear wrote:
> Dave,
>
>>> Certainly NOT the MTA, and *even* if it does change on the SUBMIT front
>>> who cares? That's before signing, right?
>>>
>> Not necessarily.
>>
>
> What about section 8 of RFC-4409 and all those fun little changes that
> can be made? We're even covered
> Eliot Lear wrote:
> > Dave,
> >
> >>> Certainly NOT the MTA, and *even* if it does change on the SUBMIT front
> >>> who cares? That's before signing, right?
> >>>
> >> Not necessarily.
> >>
> >
> > What about section 8 of RFC-4409 and all those fun little changes that
> > can be made? We're e
Ned, et al,
[EMAIL PROTECTED] wrote:
>> The "not necessarily" referred to the claim that SUBMIT is automatically
>> before
>> signing. Signing may be done by any component in the AdMD, including the
>> MUA.
>
> But if it is done by the MUA, the problem is that fully comformant SUBMIT
> agents
There's a certain point at which the answer to questions has to be
"don't do that".
>> But if it is done by the MUA, the problem is that fully comformant
>> SUBMIT agents or various sorts of other conforming intermediaries
>> can and often will wreck the signature.
Seems to me that if the MUA doe
Ned Freed wrote:
> But if it is done by the MUA, the problem is that fully comformant SUBMIT
> agents or various sorts of other conforming intermediaries can and often will
> wreck the signature. And this says nothing about non-conforming
> intermediaries,
> which aren't exactly unheard of.
>
> If
> > But if it is done by the MUA, the problem is that fully comformant SUBMIT
> > agents or various sorts of other conforming intermediaries can and often
> > will
> > wreck the signature.
> Yup.
> But, then, I view that as merely an exemplar of the question of surviving
> transit through interm
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker
Sent: Sunday, July 23, 2006 11:09 AM
To: [EMAIL PROTECTED]
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 822/2822 or just 2822
Ned, et al,
[EMAIL PROTECTED] wrote:
>> The "not necessarily" referred to the clai
On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote:
>
> My view is that DKIM is designed to provide a boundary service between
> administrative domains. (I suppose we could up with a different term
> than administative domain here, but since the two will align more
> often than not I prefer
Douglas Otis wrote:
> On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote:
>
> Striving to allow the message to be verified at the MUA increases the
> possible success of DKIM in offering the desired assurance. While there
> may be problems in some cases, many of these cases could be avo
Hi Hector,
Not that I follow this entire thread (anyone like to summarise?)
but just on this point:
Hector Santos wrote:
Question:
If it not possible to have a complete stripping of the CR/LF for hashing
purposes? That would address this particular mixed bag EOL issue for both
the signer an
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
> Striving to allow the message to be verified at the MUA increases the
> possible success of DKIM in offering the desired assurance. While there
> may be problems in some cases, many of these cases cou
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc:
Sent: Monday, July 24, 2006 9:07 AM
Subject: RE: [ietf-dkim] 822/2822 or just 2822
> On the face of this it looks like a third party is molesting the message
>
> On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote:
> >
> > My view is that DKIM is designed to provide a boundary service between
> > administrative domains. (I suppose we could up with a different term
> > than administative domain here, but since the two will align more
> > often than
>I also think that the putative "eat all CR/LF" c14n might be
>hard to get approved, given the obvious vulnerabilities it'd
>create.
It's come up before, and did not get any traction.
In the spirit of rough consensus and running code, it seems to me that
people who want a new c14n scheme should i
- Original Message -
From: "Stephen Farrell" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
> Hi Hector,
>
> Not that I follow this entire thread (anyone like to summarise?)
>From my perspective, I can summarized it as a debate on the
essential question:
Does the System
[EMAIL PROTECTED] wrote:
>> Signing at the MUA offers less value and will likely see a higher level of
>> failure. There are many reasons to caution about signing at the MUA.
>
> I agree that MUA signing is more problematic for a bunch of different
> reasons, but this is only a question of degr
om: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker
Sent: Tuesday, August 22, 2006 10:34 PM
To: [EMAIL PROTECTED]
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 822/2822 or just 2822
[EMAIL PROTECTED] wrote:
>> Signing at the MUA offers less value and will likely see a
35 matches
Mail list logo
