On Thu, 19 May 2011, Murray S. Kucherawy wrote:
The presented argument, which comes from an IETF outsider involved with
MTA development, is whether or not that SHOULD is worthy of a MUST because
failing to do it in the vast majority of cases will result in a downgrade
somewhere on the path
On 19/May/11 05:17, John Levine wrote:
The point I was making was that ever more complex ways to decide that
two mutated versions of a message are the same aren't likely to help
much, certainly not compared to the large cost of implementing code
even more complex than what relaxed does now.
Specify MUST, but clarify that this is just for now and may be revisited
at a later time -- for example, if the SMTP protcol design community ever
backs down and accepts DJB's approach to the 8-bit message problem
(http://cr.yp.to/smtp/8bitmime.html, essentially that it is OK to break
any
On 5/19/2011 10:50 AM, Murray S. Kucherawy wrote:
Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in RFC4871
Section 5.3, rather than a MUST?
To concur with one of the lines of explanation that has been offered:
It is generally a good idea to refrain from mandating
Interesting, but not less intricate. The semantics of authenticating
only the armored part of a message is not obvious. Resorting to
base64 encoding is subject to varying interpretations, including
spammers attempts to avoid naive content filtering.
S/MIME and PGP MIME have been doing just
On 5/22/11 10:38 PM, John R. Levine wrote:
Specify MUST, but clarify that this is just for now and may be revisited
at a later time -- for example, if the SMTP protcol design community ever
backs down and accepts DJB's approach to the 8-bit message problem
(http://cr.yp.to/smtp/8bitmime.html,
On 5/19/2011 3:17 PM, Murray S. Kucherawy wrote:
-Original Message- From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld
...
recently someone asked me whether it would have any added value if the DKIM
public key, which is stored
through a separate, value-added mechanism. My own preference would be for
using
a special header-field that contains the cert, with the specification of
using
such certs as saying that they are enabled when included in the set of h=
covered header fields.
I don't see how this is
On 5/22/2011 10:27 AM, John R. Levine wrote:
through a separate, value-added mechanism. My own preference would be for
using
a special header-field that contains the cert, with the specification of
using
such certs as saying that they are enabled when included in the set of h=
covered
Dave CROCKER wrote:
On 5/19/2011 2:53 PM, Pete Resnick wrote:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not
mean
vitally important and SHOULD does not mean really really important, but
less important than MUST. MUST means you have to do this or you're not
going
VBR queries are about an actor, not a message.
Certs can be coupled to a particular message -- this was an interesting
semantic distinction about Goodmail's certification scheme -- although I
believe that typically they, too, are only scoped to the actor, not the
specific content.
Now
On 05/22/2011 10:27 AM, John R. Levine wrote:
It occurs to me that since mail certification is likely to make assertions
about behavior as well as identity, the SSL model in which certs last for
a year won't work, since behavior can change rapidly. Either the
certifier has to issue a stream
But this is exactly what DKIM is. You prove yourself fsvo prove
to the registrar who certifies you by virtue of placing your NS
records in the root servers instead of issuing a cert.
Registrars, as we all know, rarely check any credential beyond the
confirmation code from the credit card
Michael Deutschmann wrote:
On Thu, 19 May 2011, Murray S. Kucherawy wrote:
The presented argument, which comes from an IETF outsider involved with
MTA development, is whether or not that SHOULD is worthy of a MUST because
failing to do it in the vast majority of cases will result in a
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Sunday, May 22, 2011 10:43 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 8bit downgrades
Please refrain from passing the buck to the WG. The
Murray S. Kucherawy wrote:
Hector Santos followed up Crocker'ss passing of the buck:
Please refrain from passing the buck to the WG. The document editors
are:
D. Crocker (editor)
Tony Hansen (editor)
M. Kucherawy (editor)
If the WG was technically incapable as you are
On May 22, 2011, at 12:27 PM, John R. Levine wrote:
It occurs to me that since mail certification is likely to make assertions
about behavior as well as identity, the SSL model in which certs last for
a year won't work, since behavior can change rapidly. Either the
certifier has to issue
Alessandro Vesely wrote:
On 19/May/11 05:17, John Levine wrote:
And anyway, if your goal is for your message to survive, you should
armor it better, not come up with more arcane ways to declare that
it may be bleeding heavily but it's not dead yet.
Interesting, but not less intricate. The
2. Should this be Informational or BCP?
a: BCP, making it clear when we're insufficiently certain about
something.
Last Call will sort out any objections.
Well, I couldn't afford to go, so I can't say you're wrong, and I don't
know why I didn't see that on the list.
I
John R. Levine wrote:
But this is exactly what DKIM is. You prove yourself fsvo prove
to the registrar who certifies you by virtue of placing your NS
records in the root servers instead of issuing a cert.
Registrars, as we all know, rarely check any credential beyond the
confirmation code
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top level encoding type
21 matches
Mail list logo
