On Saturday 09 December 2006 15:20, Dave Crocker wrote:
> offlist.
or not.
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
offlist.
Charles Lindsey wrote:
DKIM will have no effect on the present spam/phishing/malware scene
unless it is widely adopted. It will not be widely adopted unless it is
seen to be robust. In particular, it will not be adopted in countries
(esp those in Asia) where the character sets used ar
Please stop this thread with this subject line, and see my next message.
--
Barry Leiba, DKIM Working Group chair ([EMAIL PROTECTED])
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Charles Lindsey wrote:
On Wed, 06 Dec 2006 20:25:39 -, John Levine <[EMAIL PROTECTED]> wrote:
As I recall, we agreed that is specifically not a goal of DKIM. If
you want a signing scheme designed to survive all sorts of hostile
gateways, there's already S/MIME. The limited c18n in DKIM i
Charles Lindsey wrote:
On Wed, 06 Dec 2006 16:58:41 -, Stephen Farrell
<[EMAIL PROTECTED]> wrote:
My concern is that people will tend not to implement stuff that is not
in the base standard. And any c14n has to be implemented at both ends in
order to be of any use.
Speaking for myself,
Charles,
Charles Lindsey wrote:
> Yes, I might do that in due course, but we need to toss the idea
> around here a little bit more first (as we seem to be doing).
Good. I think that that's the right approach (and has the nice
side-effect of being a good check on whether we've done the
pluggabil
On Wed, 06 Dec 2006 16:36:32 -, Wietse Venema <[EMAIL PROTECTED]>
wrote:
Charles Lindsey:
That was quite some time ago, so to refresh your memories, I had been
claiming that DKIM-base would fail to verify if some message had its
Content-Transfer-Encoding changed en route,
It is les
On Wed, 06 Dec 2006 20:25:39 -, John Levine <[EMAIL PROTECTED]> wrote:
But of course I don't want them to be "likely to survive". I want a
system
that is robust enough that they "always survive".
As I recall, we agreed that is specifically not a goal of DKIM. If
you want a signing schem
On Wed, 06 Dec 2006 16:58:41 -, Stephen Farrell
<[EMAIL PROTECTED]> wrote:
So it looks to me like you're suggesting a new c14n algorithm for
the WG to consider.
If so, I think the proper course would be to write that up as a
draft-lindsey-dkim-foo and then we can see if we like it or not.
On Wed, 06 Dec 2006 14:58:55 -, <[EMAIL PROTECTED]> wrote:
Nice code, now during your testing how many messages (average message
size today 3k) per second were you able to process and on what machine.
I need something that can do about 1200 messages per second per second.
Thanks,
I hav
>But of course I don't want them to be "likely to survive". I want a system
>that is robust enough that they "always survive".
As I recall, we agreed that is specifically not a goal of DKIM. If
you want a signing scheme designed to survive all sorts of hostile
gateways, there's already S/MIME.
L PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker
> Sent: Wednesday, December 06, 2006 12:52 PM
> To: DKIM
> Subject: Re: Fwd: Re: [ietf-dkim] Introducing myself
>
>
>
> Wietse Venema wrote:
> > Charles Lindsey:
> >> That was quite some ti
Wietse Venema wrote:
Charles Lindsey:
That was quite some time ago, so to refresh your memories, I had been
claiming that DKIM-base would fail to verify if some message had its
Content-Transfer-Encoding changed en route, and that it proposed to get
...
When DKIM signers and verifiers ar
So it looks to me like you're suggesting a new c14n algorithm for
the WG to consider.
If so, I think the proper course would be to write that up as a
draft-lindsey-dkim-foo and then we can see if we like it or not.
(While having the perl code is great, its not necessarily the
easiest thing for e
Charles Lindsey:
> That was quite some time ago, so to refresh your memories, I had been
> claiming that DKIM-base would fail to verify if some message had its
> Content-Transfer-Encoding changed en route, and that it proposed to get
> around this by saying that all messages SHOULD be sent as
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Lindsey
Sent: Wednesday, December 06, 2006 8:13 AM
To: DKIM
Subject: Re: Fwd: Re: [ietf-dkim] Introducing myself
On Mon, 06 Nov 2006 10:47:45 -, Charles Lindsey <[EMAIL PROTECTED]>
wrote:
> On Sa
On Mon, 06 Nov 2006 10:47:45 -, Charles Lindsey <[EMAIL PROTECTED]>
wrote:
On Sat, 04 Nov 2006 02:03:38 -, John Levine <[EMAIL PROTECTED]> wrote:
That was quite some time ago, so to refresh your memories, I had been
claiming that DKIM-base would fail to verify if some message had i
On Sat, 04 Nov 2006 02:03:38 -, John Levine <[EMAIL PROTECTED]> wrote:
It's still an open question how Unicode is going to show up in mail
headers, with 8 bit UTF8 being only one of multiple possibilities.
More likely there will be some kludge to smoosh it into 7 bits so it
can transit throu
Paul Hoffman wrote:
At 1:38 PM + 11/4/06, Tony Finch wrote:
On Sat, 4 Nov 2006, John Levine wrote:
It's still an open question how Unicode is going to show up in mail
headers, with 8 bit UTF8 being only one of multiple possibilities.
More likely there will be some kludge to smoosh it
At 1:38 PM + 11/4/06, Tony Finch wrote:
On Sat, 4 Nov 2006, John Levine wrote:
It's still an open question how Unicode is going to show up in mail
headers, with 8 bit UTF8 being only one of multiple possibilities.
More likely there will be some kludge to smoosh it into 7 bits so it
can
I think that what the wording should say is that messages must be valid
RFC2822 (or maybe RFC822) messages. This came up in connection with
what to do with messages with bare CR or LF characters, with the answer
being "don't do that".
This implies DKIM cannot be used with 8bitmime or binarymime.
On Sat, 4 Nov 2006, John Levine wrote:
>
> It's still an open question how Unicode is going to show up in mail
> headers, with 8 bit UTF8 being only one of multiple possibilities.
> More likely there will be some kludge to smoosh it into 7 bits so it
> can transit through old MTAs.
It's much less
>>> writing headers in UTF-8. ...
>>
>> No, because we want DKIM to work with 7-bit-clean mail. We want broad,
>> fast deployment and that means working with old systems.
>
>Sure, but that is no reason for making it _not_ work with new systems.
It's still an open question how Unicode is going t
On Tue, 31 Oct 2006 09:26:57 -, Jon Callas <[EMAIL PROTECTED]> wrote:
On 30 Oct 2006, at 1:42 PM, Charles Lindsey wrote:
I'm going to cherry-pick a few things, particularly the ones I think I'm
best suited to answer.
3.2 Tag=Value Lists
INFORMATIVE IMPLEMENTATION NOTE: Alth
On Tue, 31 Oct 2006 06:27:14 -, Eliot Lear <[EMAIL PROTECTED]> wrote:
Hi Charles, and welcome. I can't answer many of your questions, but I
can certainly take a whack at a few.
3.5 The DKIM-Signature header field
Can the various tags appear in this header in any order? OTOH, why
On 30 Oct 2006, at 1:42 PM, Charles Lindsey wrote:
I'm going to cherry-pick a few things, particularly the ones I think
I'm best suited to answer.
3.2 Tag=Value Lists
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text"
defined below (as "tag-value") only includes 7-b
Hi Charles, and welcome. I can't answer many of your questions, but I
can certainly take a whack at a few.
3.3.3 Other algorithms
Presumably there is nothing to prevent allowing PGP as the signing
algorithm in the future, if someone makes out a good case for it.
PGP, to the best of my knowl
Firstly, let me apologise for not appearing on this list earlier, but I
only became aware of this project a little over a week ago, and I have
been studying the documents carefully since then, as time permitted.
I am familiar with the two existing schemes for signing headers of
messages, namely
28 matches
Mail list logo
